Claude's 1M Context Window Is a Trap: What the Benchmarks Show

More context does not mean better results. On the MRCR v2 multi-needle retrieval benchmark, accuracy sits at 93% through 256K tokens and lands around 76% at the full million. A quarter of the accuracy gone is not a model I want to rely on for complex work. The million-token window sounds incredible, up to 750,000 words in one conversation, and what it actually delivers is worse performance, a budget that drains faster, and a false sense of security.

Why doesn't a bigger window help?

Because context rot does not care how big the window is. As a session fills, early context gets buried, instructions get ignored, hallucinations and contradictions appear, and the work drifts from the original plan. The degradation kicks in after roughly 20% of the window is full, whether that window is 200K or a million. The failure point moved in absolute tokens; the failure did not change.

Reports from people actually using it match: past the first 10 to 15% it starts hallucinating and being confidently wrong, inventing bug numbers, querying badly. The same issues the 200K model showed after 50 or 60K tokens, at a larger scale and a higher price.

Anthropic's launch line was that you never need to clear your context window again. That is marketing. It is also a useful case study: do not just take the Claude Code team's word for how their own product performs.

The budget burn nobody prices in

The performance loss is only half the trap. The other half is what it does to your limits.

Everything you send builds on top of an already fuller window, so each turn costs more. Agents lean heavily on the token cache, which is cheap; but come back to a saved million-token session two days later and your first request hits a cold cache against 500K of previous tokens. That single message can eat a meaningful chunk of your session limit. The recent wave of people suddenly hitting their limits had several causes, and defaulting sessions into the big window is one of them.

Practical hygiene: keep an eye on how full the window is, and clear or reset around a quarter full. That threshold is where degradation starts, not where it ends.

When does the 1M window actually make sense?

Four cases, all with the same caveat: none of them should be your default.

1. Non-reasoning work over large documents: summarizing, extracting, classifying things that simply do not fit in the smaller window.
2. You are deep in a session, about to hit the 256K limit, and one or two more prompts finish the job. Better than compaction turning the session brain-dead. If this happens constantly, fix your process: plan better, use files as interim storage.
3. Large codebases where a decision genuinely needs a lot of upfront context, followed by one or two extraction prompts. Do not build on top of that window afterwards. Targeted retrieval still beats bulk loading when it is possible.
4. History preservation for multi-session agents where you do not want to rely on compaction.

What to do instead

Context engineering did not stop mattering because the window got bigger. Curate what goes in. Compact early. Start new sessions freely. Push research into subagents so it never lands in the main window, with the honest caveat that a subagent hands back a lossy summary; fork agents address part of that. RAG is an option too, though my own experiences with it have not been good.

And if you do not trust yourself to do any of that, the simplest fix works: disable the million-token window and stay on the smaller one. A bigger window is not a better model, and it does not excuse you from context hygiene.