Cursor "Context limit reached" Fix

Every model has a fixed context window. Long chats, many attached files and large file contents fill it up. Once full, Cursor cannot add more without dropping earlier context. That is why the warning appears and results degrade.

What fills that window is rarely the size of your repo. The window holds what is actually in play: the files you attached, the ones the agent opened while working, and every tool result it collected on the way. A single test run or a pasted log can be worth more tokens than the code under discussion, and 200,000 tokens is only about 150,000 words of English.

Which is why the same task can hit the limit on Monday and pass on Tuesday with nothing in the codebase having changed. The difference is usually how many dead ends the agent explored before it reached the real work.

The move is the same one experienced users make before the warning ever shows: keep the window small and current. Start fresh, attach only what the task touches and let rules carry the conventions you would otherwise retype.

1. 1Start a fresh chat for the task. Do not reuse one long thread.
2. 2Run `/summarize` to condense the window in place. It strips the unnecessary tool calls (the explore-and-understand steps) and reclaims space without starting over.
3. 3Attach fewer files. @-mention only what is relevant.
4. 4Raise the ceiling for genuinely big tasks: Max Mode extends the window to the model's maximum (up to 1M tokens on supported models) at token-based cost.
5. 5Move repeated conventions into `.cursor/rules` so they aren't re-sent every prompt.

The first two steps are alternatives rather than a sequence, and picking the wrong one is, I'd say, where most of this goes wrong. Start fresh when the task has changed and you want none of the history. Run /summarize when you are mid-task and the history is the point, since it condenses in place and keeps the storyline the agent has been building. Getting that backwards means either re-explaining a task you were half-way through, or hauling a finished one into the next.

Step three is where the rate changes.

The first two buy room in a window that will fill again on the same schedule as long as you keep attaching the same eight files, which is probably why people end up running /summarize three times in an afternoon and calling it a Cursor problem. Step five does the same job for anything you would otherwise retype every prompt.

Raising the ceiling comes fourth because it is the expensive answer. A larger window reads far more tokens per turn and bills accordingly, so it raises the cost of the habit rather than changing it. Reach for the bigger window when one task genuinely needs the whole call chain in view at once. Where you reach for it depends on your plan: usage-based plans pick a context window size in the model picker, and legacy request-based plans still have the Max Mode toggle.

Watch the context meter (the small square at the bottom shows what fraction of the window is used). Past ~70-80% you'll feel a slower agent and weaker responses, so /summarize or a fresh chat well before the hard limit keeps quality up.

It drops the tool calls it treats as finished, which on a working thread means the explore-and-understand steps: file reads, searches, command output the agent has already acted on. What survives is the narrative of what you asked for and what got decided.

That trade is right more often than it is wrong, and it has one edge to it. Anything whose only record was a tool result goes with it. A version you read out of a lockfile, or the one test that failed differently from the rest: when a decision rests on detail like that, restate the detail in the prompt before you compress.

The same compression is what @past chats runs on an old conversation when it carries it into a new one, so the same caution applies there.