Last updated: July 2026
Context rot is the decline in an LLM's output quality as its context window fills up. As history, tool outputs, and irrelevant files pile in, the model attends less to any single fact — so it forgets earlier instructions, re-introduces fixed bugs, and writes sloppier code late in a long session.
You have felt it even if you never named it: a coding agent that was sharp for the first twenty minutes starts ignoring your conventions, undoing its own fixes, and producing mushier answers as the session drags on. That is context rot. Here is what causes it, why bigger context windows do not save you, and the handful of habits that keep an agent sharp from the first turn to the last.
Context rot is the gradual decline in an LLM's output quality as its context window fills up. It is not a bug in any specific model — it is a property of how transformers process long inputs. A model has a fixed budget of attention to spread across everything you give it. When the context is small and clean, each token gets plenty of that attention. As the window fills with history, tool results, and files, that same attention is stretched thinner and thinner across a larger pile of tokens.
The result is that the model gets measurably worse at using any single piece of information, even information that is technically still sitting in the window. The instruction you gave on turn two is "in context" in the literal sense, but the model's ability to actually act on it has degraded. If you want the mechanics of the window itself, our explainer on what a context window is covers how that token budget works.
Context rot is closely tied to a well-documented phenomenon researchers call "lost in the middle." When you hand a model a long context, it attends most reliably to the very beginning and the very end — and least reliably to everything in between. Information buried in the middle of a long input is the first thing the model starts to overlook.
In a coding session this is exactly where your important stuff ends up. The convention you established early, the bug you already fixed, the constraint you mentioned once — all of it sinks into the middle as new turns pile on top. The model is not ignoring you out of stubbornness. The relevant tokens have simply drifted into the low-attention zone, and its recall of them falls off. That is the engine underneath context rot.
Context rot is easiest to recognize by its symptoms. In a long agent session, watch for:
If those failures feel familiar, they are not a sign the model got dumber. They are a sign the context got too big for the model to use well.
Everything that inflates the context contributes to rot. The three biggest culprits in a coding workflow:
The common thread is accumulation. Nothing gets removed from the window on its own, so a session that runs long enough will always trend toward rot unless you actively trim it. Our guide to reducing your Claude Code context window walks through where that accumulation hides and how to claw it back.
The intuitive fix is a bigger context window — if the model can hold a million tokens, surely rot goes away? It does not. A larger window changes how much you can fit, not how well the model attends across it. The lost-in-the-middle effect still applies: information buried in a 400,000-token context is arguably harder to surface than the same fact in a 40,000-token one.
In practice, a bigger window often makes rot worse, because it removes the natural pressure to keep things tight. It becomes easy to dump the whole repo in and let the agent sort it out — and now every turn is competing against a mountain of low-relevance tokens. The window size is a ceiling, not a strategy. What keeps a model sharp is discipline about what goes into the window in the first place.
The good news is that context rot is almost entirely preventable with a few habits. None of them require a different model — they require managing the window on purpose:
/compact to collapse a long session into a tight summary that keeps the decisions and drops the raw transcript. This is the single highest-leverage move against rot./clear when you switch to something unrelated. Carrying a debugging session's history into a new feature is pure noise for the new task.The theme across all of these is the same: bigger context windows do not solve context rot — discipline does. You want the fewest, most relevant tokens in the window at any moment, not the most.
Terse flags redundant reads and duplicate tool calls that quietly balloon your context — a light-touch nudge, on-device, so you can trim the noise before rot sets in. It also compresses the prompts you type before they ever hit the window.
See Where Tokens GoContext rot is the decline in an LLM's output quality as its context window fills up. As a session accumulates history, tool outputs, and irrelevant files, the model attends less effectively to any single piece of information — so it forgets earlier instructions, re-introduces fixed bugs, and writes sloppier code late in a long run.
A huge, cluttered context: accumulated tool outputs and chat history re-sent every turn, irrelevant files pulled into scope, and long sessions that never reset. The more tokens compete for the model's attention, the more the "lost in the middle" effect degrades its recall and adherence.
Compact or summarize the history with /compact, clear the session with /clear between unrelated tasks, and start a fresh session for each new feature. Keep only the relevant files in context, use selective context, and keep your CLAUDE.md lean. Discipline beats a bigger context window.
No. A larger window lets you fit more tokens, but the lost-in-the-middle effect means the model still attends less to information buried in a long context. More room to fill often makes rot worse. Curating what goes in the window matters more than how big it is.