You start a session with an agent. The first half hour is great. It reads your code, follows your instructions, fixes what you asked.
Then somewhere around the middle of the afternoon it starts doing this:
- It breaks a rule you gave it at the very start of the session.
- It reintroduces a bug it fixed forty minutes ago.
- It "helpfully" rewrites a file you told it not to touch.
- It gives you a confident answer that contradicts something it said earlier in the same conversation.
- It gives up on a task it would have finished an hour ago.
The usual reaction is to blame the model — it got lazy, they nerfed it, this one is worse than last week's.
It's almost never that. What you're looking at has a name, it's been measured, and once you can see it you can design around it.
It's called context rot.
The one-sentence version
An LLM does not use its context window evenly. The more you put in, the less reliably it uses any of it.
That's the whole idea. Everything below is why it happens and what to do.
The important word is reliably. Nothing is deleted. Nothing falls out. The rule you set at turn 3 is still sitting right there in the context at turn 60, perfectly intact — the model has simply become worse at acting on it.
This is why the bug feels supernatural. You can scroll up and see the instruction with your own eyes. It's there. The model can "see" it too. And it still isn't following it.
It isn't your model, and it isn't your prompt
In July 2025, a team at Chroma — Kelly Hong, Anton Troynikov and Jeff Huber — ran a study called Context Rot. They tested 18 models: Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5 and Haiku 3.5; o3, the GPT-4.1 family, GPT-4o, GPT-4 Turbo and GPT-3.5 Turbo; Gemini 2.5 Pro, 2.5 Flash and 2.0 Flash; and three Qwen3 models.
The headline result is short:
Every single one got worse as input length grew.
Not the cheap ones. Not the old ones. All eighteen, including the frontier models of that moment. So if you have been switching models to fix this, that's the wrong lever — you're changing a variable that isn't the cause.
And the reason this matters more now than it did in 2025, not less: context windows got enormous. A million tokens is normal now. Bigger windows didn't fix context rot. They removed the guardrail that used to stop you from hitting it — when the window was small, you got a hard error. Now you get a silent slide in quality with nothing to tell you it started.
Why "30 turns"? It isn't the turns.
Let's kill the number in the title, because it's a symptom, not a cause.
Nothing happens at turn 30. What happens is that by turn 30, a coding agent has typically accumulated something like this:
| What's in the window | Roughly |
|---|---|
| Your system prompt / rules file | 1–3k tokens |
| Tool definitions (often 20–50 of them) | 5–15k tokens |
| Files it read — including versions it has since edited | 20–100k tokens |
Tool outputs: test runs, stack traces, grep results, build logs |
20–80k tokens |
| The actual conversation between you and it | 5–15k tokens |
Notice the proportions. The part that is actually a conversation is the smallest part of the conversation. Almost everything in the window is machine output that scrolled past you.
So "30 turns" is really just shorthand for "the point where your context is mostly noise". Ten turns of running a failing test suite will get you there faster than a hundred turns of chatting.
The right unit isn't turns. It's how much of the window is still relevant.
The four things that actually make it worse
The Chroma study didn't only measure length. It varied the shape of what was in the window, and this is the useful part, because shape is something you control.
1. Length alone
Even on a task with no reasoning in it at all — copy this list of words back to me, with one odd word inserted — accuracy fell as the list got longer. They tested from 25 words up to 10,000.
At the long end, models stopped copying and started inventing. Gemini models began emitting words that were never in the input at around 500–750 words. Qwen3-8B started producing nonsense from about 5,000.
Let that sit for a second. This is a task with zero difficulty. The instruction is "repeat this." Length alone was enough to break it.
There's a mechanical reason underneath. Attention is quadratic: every token is weighed against every other token. At 100,000 tokens that's 10 billion pairwise relationships to spread a fixed amount of attention across. Nothing is deleted — it's diluted.
2. When what you need isn't worded like your question
They scored how similar each hidden fact was to the question being asked, and found: the less the answer resembles the question, the faster performance falls off with length.
This one has a direct consequence for how you work. When you ask "why is the login flow slow?", the answer might be a line about connection pooling in a config file that never uses the word "login" or "slow". That's a low-similarity target — exactly the kind that degrades fastest in a big context.
Translation: the harder your question is to keyword-match, the more the length is hurting you.
3. Distractors — the big one for coding agents
They added plausible-but-wrong content near the real answer. One distractor measurably hurt. Four compounded it.
They also found the damage isn't uniform — some distractors were far worse than others, in ways that weren't predictable in advance.
Now think about what a coding agent's context looks like after an hour:
- Version 1 of the file, which it read
- Version 2, after it edited it
- Version 3, after it edited it again
- A stack trace from a bug that no longer exists
- A test failure it already fixed
- A plan it wrote, then abandoned
Every stale version is a distractor. They are plausible. They are relevant-looking. They're in the same language, about the same code, sitting right next to the truth. This is the single biggest source of context rot in agentic coding, and almost nobody thinks of it as pollution — it looks like history.
One more detail from the study, worth knowing when you pick a model for long sessions: hallucination behaviour under distractors differed by family. Claude models had the lowest hallucination rates; GPT models the highest. Claude's failure mode was more often to abstain — to say it wasn't sure — where others confidently made something up.
4. Structure — and this one is genuinely strange
They compared a context where the text flowed logically against one where the same sentences were randomly shuffled.
Models did better on the shuffled version.
Nobody has a clean explanation for it yet. But it's a useful warning shot for a habit a lot of us have: carefully assembling a beautiful, well-ordered, coherent block of context on the assumption that tidiness helps the model. On this benchmark, coherent structure did not help. It hurt.
Don't over-read it — this is one benchmark, not a law. But it should stop you from assuming that neatly organising a huge context is doing anything for you. The thing that reliably helps is having less in there.
The 2026 finding almost nobody is talking about
Most articles about context rot stop at the 2025 study. There's a newer one that reframes the whole problem, and I think it's the more useful mental model.
In June 2026, Shijie Xia, Yikun Wang, Zhen Huang and Pengfei Liu published Diagnosing and Mitigating Context Rot in Long-horizon Search. They studied four flagship models across three benchmarks, and named something they call premature termination:
Under extensive context, models give up — or hand back an uncertain wrong answer — long before the context window is anywhere near full.
And the rate of premature termination rises with context length, even after controlling for how hard the question is.
This is a different failure from "it couldn't find the answer". The model stops looking. It ends the search early, on a task it has plenty of room and plenty of capability to keep working on.
If you use coding agents, you have watched this happen and probably filed it under laziness:
- It searches two files, doesn't find it, and asks you where it is.
- It stops after fixing one of the three things you listed.
- It says "this would require a larger refactor" for something it happily did this morning.
- It hands back something hedged and half-done rather than finishing.
That's not attitude. That's a measurable effect of a full context window.
The paper also evaluated seven context-management methods across three categories, and their conclusion about why those methods work is the part worth internalising: the methods help because they reduce the premature-termination rate, which lets the model keep exploring. You're not cleaning the context to help it remember. You're cleaning it to stop it from quitting.
The fixes: four moves, and that's the whole toolbox
Everything people call "context engineering" collapses into four moves. The clearest formulation of this is LangChain's — write, select, compress, isolate. Here's each one in plain terms, with what it looks like when you're using an agent rather than building one.
Write — put it somewhere other than the window
Get durable information out of the conversation and into a file the agent can read back when it needs it.
In practice: a rules file (CLAUDE.md, .cursorrules, AGENTS.md), and a plan file the agent keeps updating as it works.
Why this works is subtle and worth spelling out: a decision written in chat at turn 4 is a distractor by turn 40, because five later messages have partially contradicted it. The same decision in a file is a single current version. Files don't accumulate stale copies of themselves the way a conversation does.
Select — bring in only what this step needs
Don't front-load. Pull in the file when it's time to touch the file.
The counter-intuitive habit to break: dumping your whole schema, all your types and six related files "so it has context." Every one of those is a distractor for the 95% of the task they aren't relevant to.
Even tool definitions count. One result LangChain cites: applying retrieval to tool descriptions — showing the model only the relevant tools instead of all of them — improved tool selection accuracy threefold. If you've wired up thirty MCP tools and your agent keeps picking the wrong one, that's not the model being dim; that's forty tool descriptions competing for attention on every single turn.
Compress — keep the meaning, drop the tokens
Summarise and move on. Claude Code does this automatically with auto-compact once you cross about 95% of the window.
The mistake is treating compaction as an emergency measure that fires on its own at the end. By 95% you have already been degrading for a long while. Compact at the seams — when you finish a subtask, when you switch files, when a test finally goes green. You know where the boundaries are. The auto-trigger doesn't.
And trim the biggest offenders by hand. A 400-line stack trace from a bug you already fixed is pure distractor. So is the full output of a test run from three fixes ago.
Isolate — give separate work separate windows
Sub-agents. Anthropic's multi-agent research system had subagents running in parallel, each with its own context window, and only the final result came back to the main agent — not the dozens of tool calls that produced it.
That last clause is the entire benefit. "Search the codebase for every place we handle refunds" might burn 40,000 tokens of grep output to produce one paragraph of answer. Done in the main window, you keep all 40,000. Done in a sub-agent, you keep the paragraph.
The honest tradeoff, from the same source: that system used up to 15× more tokens than ordinary chat. Isolation buys reliability with money. Sometimes that's a great trade and sometimes it isn't.
What to actually do tomorrow
Ordered by effort, cheapest first:
- Start a new session at task boundaries. Free, instant, and it's the single most effective thing on this list. Finished the feature? New session. A fresh window with a good rules file beats a long window with perfect history, essentially always.
- Move durable decisions into a file, not the chat. Anything you'd be annoyed to repeat is a rules-file line, not a message.
- Compact deliberately, at seams. Don't wait for the automatic trigger.
- Stop pasting things "just in case." Every extra file is a distractor with a cost and no benefit until it's needed.
- Prune your tool list. If your agent has thirty tools loaded and uses four, the other twenty-six are tax on every turn.
- Push searching and exploring into sub-agents, so the exploration doesn't live in your main window.
- When quality drops, restart — don't argue. Correcting a rotting context adds tokens to a window whose problem is that it has too many. You are treating the disease with more of the disease.
Six signs you have it right now
- The agent breaks a rule it followed correctly earlier in the same session.
- It reintroduces something it already fixed.
- It starts hedging and abstaining on tasks it was completing an hour ago.
- It gives up early — "you may want to check X yourself" for something it was doing itself before.
- It edits a stale version of a file, one that matches what it read but not what's on disk.
- Your fix for all of the above is to explain more, and explaining more makes it worse.
That last one is the tell. If adding context makes it worse, context is the problem.
The reframe
Most of us learned to treat the context window as memory: put the important stuff in, and the model will remember it.
The research points somewhere else. It behaves less like memory and more like a shared workspace with finite attention. Everything you set on the table competes with everything else on the table — including the six things you put there an hour ago and stopped needing.
So the skill isn't getting more into the window. It's knowing what to take out, and when.
A million-token context window is not an invitation to use a million tokens. It's an invitation to be much more careful about which ten thousand you use.
Which of the six signs do you hit most? I'm most curious whether anyone has found a good rule for **when* to restart a session — I still do it on instinct, and instinct is usually about twenty turns too late.*
Top comments (0)