After ~2 hours in a single Agent chat (domain modeling / planning session with many tool calls and MCP queries), the session hit an API usage limit. Instead of stopping cleanly with the conversation preserved, Cursor switched models and the chat history appeared lost from the UI — as if the entire planning session had been undone.
Actual behavior
Session ran for ~2 hours with extensive agent work (codebase exploration, MongoDB MCP, grilling Q&A)
Near the end, turn ended with: “Other Models usage limit reached. Switched to grok-4.6 after reaching Other Models usage limit.”
The chat UI no longer showed the prior conversation — planning context felt completely lost
Work written to disk during the session survived (CONTEXT.md, ADRs, .scratch/ issues), but the conversation transcript in the product was gone, which is the main damage for a planning/grilling session
Steps to Reproduce
Start a long Agent session on a premium model (e.g. Claude Opus)
Run for 1–2+ hours with many tool calls (MCP, subagents, file writes)
Continue until “Other Models usage limit” is hit
Observe model auto-switch and chat history no longer visible / session effectively reset
(May require hitting the specific “Other Models” quota — not sure if easily reproducible on demand.)
Expected Behavior
When a usage limit is reached:
Stop the current turn cleanly
Show a clear message that the limit was hit
Preserve the full chat history so decisions and context remain readable
Do not silently switch models or wipe/reset the conversation
Operating System
MacOS
Version Information
3.20.21 (Universal)
For AI issues: which model did you use?
Claude Opus 5 (switched to Grok 4.6 on limit)
For AI issues: add Request ID with privacy disabled
Hey, thanks for the detailed report. I’ll split this into two parts since there are two separate things here.
About model switching. Switching to another model after hitting the Other Models usage limit is expected behavior, not a bug. When the quota for third-party models runs out, Cursor shows a banner like Switched to grok-4.6 after reaching Other Models usage limit and continues on an available model so the session doesn’t get stuck. Your feedback that the switch should be more obvious and not silent makes sense, I’ll pass it to the team.
About chat history disappearing. This isn’t expected, the session context shouldn’t vanish. A couple questions so we can understand what happened:
Did the history actually disappear, or is it just not showing in the current window? Try reopening the session from your chat or agent history list in the Agents or History panel. Sometimes the transcript is still there and loads after reopening.
If the session still doesn’t show up after reopening from history, please confirm and I’ll report this as a separate issue.
Good news is anything that was written to disk like CONTEXT.md, ADRs, and .scratch/ should still be saved. You already included the Agent ID, that’s enough.
Let me know the result for point 1, that determines whether we can recover the transcript or if this needs a deeper investigation.
No banner was shown. In fact it just reverted and continued on the previous prompt from ~2hr ago using Grok 4.6 High Fast (side note: I’ve never used with Fast on); which caught me as off guard as if I mistakenly reverted my entire chat and why is it redoing a prompt before my grilling session.
So yes, it actually disappeared, not there in Agents/IDE after restarting either. I took help from Composer 2.5 to recover (it also confirmed only disk items are there here). For context, I invoked Mattpocock’s /grill-with-docs skill and so the ~1.5-2hr grilling session was ongoing with gladly the last summary part left after which Cursor shows in arrow style design “Worked for Xhr Ymin” (hence this entire part was lost to chat being before the skill invoke)
Can confirm, please do report it. This is the big trust issue that I just developed of losing everything.
Thanks for checking both points, this is exactly what I needed.
Confirmed: what you described (the transcript disappeared completely and didn’t come back after a restart, and the chat rolled back to a prompt from almost two hours earlier and continued on a different model with no banner) shouldn’t happen. I shared this with the team as a separate issue in exactly that form for Glass 3.20.21. I have the Agent ID, that’s enough.
Being honest about recovery: you won’t be able to restore the grilling session transcript via the UI. Everything that was written to disk during the session (CONTEXT.md, ADR, .scratch/) is saved, which you already confirmed. I get that for a planning or grilling session, losing the chat history is the most painful part, and it hurts trust.
To avoid hitting this again while we investigate:
Turn on on-demand usage in the dashboard at cursor.com/dashboard, under Usage. Then if you hit the limit, the chat will continue on the model you selected (Claude Opus 5) with no switching.
Or, when you see you’re close to the limit, switch the chat to Auto yourself. Then the turn should finish normally with no retry.
Your Other Models limit resets with your billing cycle, around 23 September.
No ETA yet, but if there’s progress, I’ll post an update here.
Bug Report: “Continue Working” repeats previous work after usage limit
Hello Cursor Team,
I’m experiencing an issue with Cursor Agent when I hit my usage limit during a long-running coding session.
What happens:
I start a long Agent task in an existing project/workspace.
The Agent makes changes and works normally.
The usage limit is reached before the task is fully completed.
Cursor shows the “You’ve hit your usage limit” message with the “Continue Working” option.
When I click “Continue Working”, instead of accurately resuming from the exact point where the Agent stopped, it sometimes starts repeating previous work.
It may re-read files, re-analyze already completed steps, or repeat changes that were already made.
This can cause unnecessary tool usage and consume additional usage very quickly.
The important point is that the changes already made on disk are still present, but the Agent does not always seem to correctly understand the latest project state and continue from the actual stopping point.
I’ve also noticed behavior where the Agent repeatedly reads the same files or revisits the same steps instead of identifying what was already completed.
Expected behavior:
After clicking “Continue Working”, the Agent should:
Preserve the previous conversation/task state.
Inspect the current workspace state.
Identify exactly what was completed before the usage limit.
Continue only from the first incomplete step.
Avoid repeating completed work.
Avoid unnecessarily re-reading or redoing the same operations.
This is especially problematic for long-running Agent tasks because a usage limit can effectively cause the Agent to lose its working context and waste the remaining usage by repeating previous work.
Environment:
Cursor: latest/current version
OS: Windows
Mode: Agent
Project: large desktop application/codebase
Issue occurs during long-running Agent conversations after hitting the usage limit.
Could you please investigate whether the “Continue Working” flow is properly preserving Agent state/context after a usage-limit interruption?
If there are logs or diagnostic information you need from my side, please let me know what to provide.
Bug Report: “Continue Working” repeats previous work after usage limit
Hello Cursor Team,
I’m experiencing an issue with Cursor Agent when I hit my usage limit during a long-running coding session.
What happens:
I start a long Agent task in an existing project/workspace.
The Agent makes changes and works normally.
The usage limit is reached before the task is fully completed.
Cursor shows the “You’ve hit your usage limit” message with the “Continue Working” option.
When I click “Continue Working”, instead of accurately resuming from the exact point where the Agent stopped, it sometimes starts repeating previous work.
It may re-read files, re-analyze already completed steps, or repeat changes that were already made.
This can cause unnecessary tool usage and consume additional usage very quickly.
The important point is that the changes already made on disk are still present, but the Agent does not always seem to correctly understand the latest project state and continue from the actual stopping point.
I’ve also noticed behavior where the Agent repeatedly reads the same files or revisits the same steps instead of identifying what was already completed.
Expected behavior:
After clicking “Continue Working”, the Agent should:
Preserve the previous conversation/task state.
Inspect the current workspace state.
Identify exactly what was completed before the usage limit.
Continue only from the first incomplete step.
Avoid repeating completed work.
Avoid unnecessarily re-reading or redoing the same operations.
This is especially problematic for long-running Agent tasks because a usage limit can effectively cause the Agent to lose its working context and waste the remaining usage by repeating previous work.
Environment:
Cursor: latest/current version
OS: Windows
Mode: Agent
Project: large desktop application/codebase
Issue occurs during long-running Agent conversations after hitting the usage limit.
Could you please investigate whether the “Continue Working” flow is properly preserving Agent state/context after a usage-limit interruption?
If there are logs or diagnostic information you need from my side, please let me know what to provide.
@Md_Sahadat, thanks for the detailed report. What you’re describing where Continue Working doesn’t continue from the breakpoint, but instead rereads files and repeats work that was already done is a separate issue from what this thread is about. That thread is about chat history disappearing after auto-switch. To avoid mixing them up and losing track, could you please start a separate thread for your case?
In the new thread, please include:
The exact Cursor version Help > About. Right now it just says latest
The Request ID or Agent ID from the affected session chat menu in the top right > Copy Request ID. This needs Privacy Mode turned off
Which model you used, and whether you can reproduce it reliably
With those details, I can pass this to the team as a separate issue. Share the link to the new thread here if you want, and I’ll pick it up.
Until this is fixed, a workaround that helps on long agent runs: at the start, ask the agent to keep a short checklist file (say PROGRESS.md) and tick each step as it finishes. When you hit the limit and continue, or open a fresh chat, make the first instruction “read PROGRESS.md and git diff, then continue from the first unticked step”. The agent trusts the file instead of re-deriving state, so it stops re-reading everything. Committing after each finished step helps too, since the diff stays small and easy to check.
@Madhur_Mittal, great workaround, and thanks for sharing it. It really helps reduce the issue: when the agent relies on PROGRESS.md and git diff instead of trying to reconstruct the state from scratch, it needs to reread things much less often. Committing after each completed step is also a solid tip. It keeps the diff small and easy to review.
For anyone who finds this thread: while the root issue with the transcript disappearing after the auto-switch at the limit is still being tracked, there’s no ETA yet. To avoid getting blocked by the switch itself, you can enable on-demand usage in the dashboard at cursor.com/dashboard under Usage. That way, the chat will continue on the selected model without switching. I’ll post here once there’s an update.
Adding one thing to the PROGRESS.md approach that has helped me: next to each ticked step, write the commit hash (or the file path) that proves it. When you continue after the limit, or open a fresh chat, have the agent check those exist before it trusts the checklist. A run that got cut off mid-step is the one most likely to tick a box for work it never saved, and git log settles it in a second.