1M Token Context: Feed Your Agent Like an Architect
Sonnet 5 reads a million tokens. Most people still feed their agent one file at a time — and give away the actual leap. What big context changes in practice, where it hurts, and a rule of thumb for daily work.
by
Sonnet 5 in Claude Code has a native one-million-token context window — enough for whole subsystems, tests, and docs in a single call. Big context enables architecture reviews and migrations that small windows never could, but dilution, cost, and false confidence argue against filling it by default. The working rule: give the agent as much context as the change can do damage.
Since late June, Sonnet 5 has been the default in Claude Code — with a native context window of one million tokens. That's, roughly, tens of thousands of lines of code plus docs plus tickets, in a single call.
And yet I see the same working style in almost every team as two years ago: open a file, paste, ask. The agent gets keyholes where it could see the whole building. If you work with a million tokens the way you worked with 8,000, you're not leaving a little performance on the table — you're giving away the entire category of the leap.
What big context actually changes
The difference isn't "more of the same." It's tasks that simply didn't work before:
- Hand over subsystems, not files. The whole module, its tests, its migrations, the adjacent interfaces — the agent sees the relationships instead of guessing them. The classic "it compiles but doesn't fit the architecture" failures happen exactly where the model lacked the edges.
- Architecture review over the real codebase. "Here are our layers — where do we violate them?" used to be a sampling game with small windows. Now it's an honest question about the actual code.
- Migration work with memory. An upgrade across dozens of files where the agent knows the conventions and edge cases from the entire diff so far, instead of reinventing them per file.
- Documents and code together. The spec, the ADRs, the ticket, and the affected code in one context — the translation losses between "what was meant" and "what gets built" shrink measurably.
Where big context hurts
Honestly: a million tokens is a tool, not a default. Three counterforces you need to know:
- Dilution. Relevance is not a function of volume. Dump the repo in indiscriminately and the twenty lines that matter become a needle in a haystack — models weight what's prominent and repeated, not automatically what's important.
- Cost and latency. Large contexts cost money and time linearly, on every call. An 800k context for a one-line change is waste by design. (Sonnet 5 promo pricing runs until the end of August — after that, discipline pays twice.)
- False confidence. "It saw everything" doesn't replace review. An agent with full context makes more plausible mistakes — which are harder to spot. The review discipline becomes more important, not less.
And: retrieval isn't dead. For question-answering over large knowledge bases, targeted search stays cheaper and often more precise. Big context wins where relationships are the task — not lookup.
The rule of thumb: context follows blast radius
My working rule, and it has held up:
Give the agent as much context as the change can do damage.
- Typo, single-file fix: the file. Done.
- Feature within one module: the module + its tests + the interfaces it touches.
- Cross-cutting change (auth, logging, data model): the affected subsystems + architecture docs + one or two reference implementations of the convention.
- Architecture decision or review: as much real codebase as fits, plus ADRs — this is where the million pays off.
The side effect of this rule: it forces you to determine the blast radius before the prompt — and that consideration is half the specification.
What you can do this week
Take a real cross-cutting task and run it twice: once in your usual file-by-file style, once with the whole affected subsystem in context. Compare not just the result but the number of corrective prompts. The difference is the argument — in one direction or the other.
More of this — agent workflows, MCP, engineering discipline in the AI era — lands regularly on the blog and in the newsletter: sign up where the next deepdive arrives first.
Frequently asked questions
How much context should I give a coding agent?
Match context to blast radius: for a typo or single-file fix, just the file; for a feature within one module, the module plus its tests and touched interfaces; for cross-cutting changes, the affected subsystems plus architecture docs and a reference implementation; for architecture reviews, as much real codebase as fits, plus ADRs. Determining the blast radius before prompting is half the specification.
What are the downsides of a 1M token context window?
Three counterforces: dilution — dump a repo in indiscriminately and the twenty lines that matter become a needle in a haystack, since models weight what is prominent, not what is important; cost and latency, which scale linearly with context on every call; and false confidence — an agent with full context makes more plausible mistakes, which are harder to spot in review.
Is retrieval (RAG) obsolete now that context windows reach 1M tokens?
No. For question-answering over large knowledge bases, targeted retrieval stays cheaper and often more precise than loading everything into context. Big context wins where relationships are the task — subsystem handovers, architecture reviews, migrations across many files — not where the job is a lookup.
What can you do with a large context window that you could not before?
Hand over whole subsystems instead of single files, so the agent sees relationships instead of guessing them; run architecture reviews over the actual codebase instead of samples; do migrations across dozens of files where the agent remembers conventions from the entire diff so far; and combine specs, ADRs, tickets, and code in one context to shrink translation losses.