Your coding agent says it has a million tokens of context. It does not.
This is not a bug report, and nobody is lying to you exactly. But there are three different numbers hiding behind that "1M" badge in your IDE status bar, and the gap between the largest and the smallest is where a lot of confusing agent behaviour comes from. If you have ever watched an agent forget a decision it made twenty minutes earlier, or seen your bill spike on a session that felt short, this is usually why.
Let's put actual numbers on it.
Three numbers, not one
Every AI coding tool has a context window that exists at three levels:
- The advertised window — what the model supports via API. This is the marketing number.
- The harness cap — what the CLI or IDE will actually let you fill before it intervenes.
- The effective window — how much context the model can still reason over reliably.
These are not close to each other.
Codex
GPT-5.5 advertises a 1,050,000-token window. Codex caps its own sessions at 400,000. Of that, 272,000 is allocated to input and 128,000 is reserved for output. The CLI then keeps roughly 5% headroom, which leaves you about 258,400 usable input tokens.
That is roughly a quarter of the advertised figure before you have typed anything.
Claude Code
Claude Opus supports a 1M-token window through the API. Claude Code's auto-compact fires at around 420,000 tokens — about 42% of the window — and that threshold is not user-configurable by default, which has been a running complaint on the issue tracker. Sonnet 5 behaves differently and compacts closer to 967,000.
Both tools also pay fixed overhead before your task starts. The system prompt, a CLAUDE.md or AGENTS.md file, and a single connected MCP server can together consume around 42,000 tokens. Every MCP tool re-sends its schema each turn. AGENTS.md files are read root-to-leaf at session start and capped at 32 KiB. On a 200K window, the reserved buffer alone runs about 33,000 tokens.
Antigravity
Google's Antigravity displays 1M in the UI, but developers report compaction kicking in around 256K in practice. The model genuinely supports 1M — the harness is the constraint.
The pattern is consistent: the harness number is a fraction of the model number, and neither is the number that determines whether your agent gives good answers.
Context rot: the number that actually matters
Here is the uncomfortable part. Even the harness cap is optimistic, because model accuracy degrades long before the window fills.
The NoLiMa benchmark makes this precise. Standard needle-in-a-haystack tests let models cheat by matching literal keywords between the question and the buried fact. NoLiMa removes that shortcut — the needle and the question share minimal lexical overlap, so the model has to infer the association rather than pattern-match it.
The results are brutal. At just 32K tokens, ten of the tested models dropped below 50% of their own short-context baseline. GPT-4o, one of the better performers, fell from 99.3% to 69.7%.
Thirty-two thousand tokens. Not one million.
Chroma's research across 18 frontier models found the same shape from a different angle: focused prompts of around 300 tokens beat full prompts of ~113,000 tokens on LongMemEval. More context made the answers worse, not better.
Independent testing of Llama 4 Scout — advertised at 10M tokens — shows recall degrading meaningfully past 1M.
The engineering-safe assumption that falls out of all this: treat anything above roughly 50% of the advertised limit as unreliable, and design for far less than that where accuracy matters.
What this costs you
Context is not just an accuracy problem, it is a billing problem, and the two compound.
On Codex, prompts that exceed 272,000 input tokens move to premium pricing: 2x on input and 1.5x on output, against a base of $5 per million input and $30 per million output tokens. So the tokens most likely to be degrading your answer quality are also the most expensive tokens you will buy.
An agent that fills its window with speculative file reads is paying double for context that measurably reduces its accuracy. That is the worst quadrant to be in, and it is the default behaviour of an unsupervised agent turned loose on a large repository.
Practical budgeting
Stop treating the context window as storage. Treat it as a working set with a hard accuracy budget.
Measure your fixed overhead first. Before optimizing anything, find out what you are spending before the task begins. System prompt, project instruction files, MCP schemas, tool definitions. If a single MCP server costs you 42K tokens per turn, that server needs to justify itself.
Prune MCP servers aggressively. Tool schemas are re-sent every turn. Three connected servers you rarely use are a permanent tax on every request in the session. Disconnect what you are not using for this specific task.
Keep instruction files tight. An AGENTS.md or CLAUDE.md that has grown to several thousand lines is loaded in full at session start. Split rarely-needed guidance into skills or docs the agent loads on demand instead of carrying it in every session.
Scope the task, not the repository. "Read src/auth and summarize how sessions work, do not edit" is a better opening move than pointing the agent at the whole tree. Targeted reads keep the working set small and the answers sharp.
Restart instead of compacting. Compaction is lossy summarization. If you are approaching the threshold and the current task is finished, a fresh session with a short handoff note usually outperforms a compacted one carrying degraded summaries of work you no longer need.
Externalize memory. Long-running work belongs in files, not in the window. Have the agent write decisions and state to disk and read them back on demand. This is the core insight behind context engineering as a discipline — and it is why RAG architectures still matter even in the era of million-token models.
Verify at checkpoints. Because degradation is gradual and silent, the agent will not tell you it has started to lose the thread. Run the test suite. Re-read the diff. Ask the agent to restate the plan. Catching drift early is cheaper than untangling a forty-file diff built on a half-forgotten spec.
The takeaway
The million-token context window is real in the sense that the API accepts a million tokens. It is not real in the sense that most developers assume — that the model will reason over all of it with the same fidelity it shows on a short prompt.
Between the advertised window and the effective one, you lose the harness cap, the fixed overhead, and then a steep accuracy curve that starts biting well before 32K on hard retrieval tasks. Build against measured effective limits rather than the number on the box, and most of the mysterious agent behaviour stops being mysterious.
The teams shipping reliable agent workflows in 2026 are not the ones with the biggest context windows. They are the ones keeping the working set small on purpose.
Related reading: