Claude's 1M Context Window: When to Actually Use It

Reading one big thing once — a contract set, a repo snapshot, a year of tickets?Use the full window. This is what it's for, and chunking it would cost you more in lost cross-references than the tokens are worth.

An agent that loops with tools until a task is done?Cap it. Every turn re-sends the entire conversation, so a fat context isn't a one-time charge, it's a subscription you pay per step.

A chatbot that runs for weeks? Cap it and compact it. Nobody needs turn 4 from last Tuesday verbatim, and keeping it makes turn 400 worse, not better.

Batch classification over thousands of documents?Small context, cheap model, Batch API. If you find yourself reaching for a million tokens here, you've built a retrieval problem into a context problem.

Not sure which one you have? Count the turns. One turn means use the window. Many turns means engineer the window. That single question settles about 90% of the argument.

For a while the million-token window was a thing you opted into with a beta header and paid a premium for past 200k. That's gone. On Claude Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5 and Sonnet 4.6, the 1M window is simply the default — no header, and standard pricing across the whole thing. Anthropic's own wording is blunt about it: a 900k-token request is billed at the same per-token rate as a 9k-token request.

Two details people miss. First, output is still capped at 128k tokensper request, so the big window buys you reading room, not writing room. Second, Sonnet 4.5 and Haiku 4.5 stayed at 200k — if your fallback model in a failover chain is Haiku, a prompt that fits your primary model can hard-fail on the backup. I've seen that exact failure in a production chain and it looks like a random 400 until you read the error text.

So the pricing objection is dead. Good. That means the decision is now purely about cost volume and accuracy, which is a much more interesting conversation than “is there a surcharge.”

“No surcharge” and “cheap” are different claims. Here's the arithmetic at published rates — $5/MTok input on Opus 5, $2/MTok on Sonnet 5 — for the input side of a single turn:

One turn at $4.50 is fine. Forty turns is $180.That's the number that should change your architecture. An agent loop doesn't send the prompt once — it sends the entire accumulated conversation on every single step, so a bloated context multiplies by the length of the task. A research agent that takes 40 tool calls to finish, sitting at 900k tokens of context, spends $180 just reading before it produces a single line of output you care about.

Caching helps a lot here, and you should be using it: a cache hit costs 10% of base input price, which is the difference between the second and fourth columns above. I wrote up the mechanics in the prompt caching breakdown. But note what caching does and doesn't do — cached tokens still occupy the context window. You changed the invoice. The model is still reading 900k tokens.

This is the part that changed how I build agents, and it's not a hot take from a benchmark blog — it's in Anthropic's own context window guide: “more context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what's in context just as important as how much space is available.”

Read that again, because it's the vendor telling you the big number on the spec sheet is a capacity, not a promise. The window is how much the model canhold. It says nothing about how well the model reasons once it's holding that much.

In agent loops the effect compounds in a specific, recognizable way. Symptoms I look for: the agent re-reads a file it already read, retries a tool call that already failed the same way, or produces a summary of a summary. When I see any of those in a long run, I stop debugging the prompt and start looking at how much junk is in the context. It's almost always the second thing.

There's a nice tell built into some models, too. Sonnet 5, Sonnet 4.6, Sonnet 4.5 and Haiku 4.5 have context awareness— the API injects a token budget into the system prompt and a remaining-capacity warning after each tool call, so the model can pace itself against what's left. Opus 4.7 and later Opus models don't get those injected tags; you give them an explicit budget instead. Worth knowing before you assume every model can see its own gas gauge.

Here's the one that quietly wrecks spreadsheets. Claude 4.7 and later models use a newer tokenizer that produces roughly 30% more tokens for the same text than Sonnet 4.6 and earlier. Same document, same prompt, ~30% more tokens on the meter.

So a prompt you measured at 200k tokens on an older model lands closer to 260k on a newer one. If you hardcoded a chunk size, a truncation threshold, or a cost estimate against the old tokenizer, all three are now wrong in the same direction — and the failure shows up as a slow budget overrun rather than a crash, which is the worst kind.

The fix is boring and takes ten minutes: stop estimating and call the token counting endpoint against the exact model you're shipping. Anything else is a guess that ages badly. Same discipline I argued for in autopilot cost controls — measure the thing, don't model the thing.

Single-pass reads over a fixed corpus. That's the whole list, honestly, and it's a good list.

The best case I keep coming back to is whole-codebase questions. “Every place this env var is read, and which ones would break if I renamed it” is a question retrieval answers badly and full context answers well, because the answer depends on relationships the chunker just severed. One turn, one bill, done.

Second: document sets where the cross-references are the point — a contract plus its amendments, an RFP plus the four addenda that contradict it. Chunk those and you get a confident answer built on the superseded clause.

Third: fixed prefixes that cache beautifully. If the same 300k-token corpus leads every request, you write it to cache once and every subsequent hit is 10% of input price. That's the shape where a large window is genuinely economical rather than merely permitted.

The through-line: the content is fixed. The moment context is growing turn over turn — accumulating tool results, chat history — the cache tail invalidates constantly and you're paying full freight on a context that's getting worse as it gets bigger.

Every agent that runs on a loop gets a ceiling well under the model's maximum. Not because the tokens are unaffordable, but because a loop that's allowed to grow to a million tokens will, and the version of it that grew is worse at its job than the version that didn't. The daily agent that researches and writes this blog runs on a 1M-token model and has never come close to needing it — the entire run, research included, sits comfortably inside a fraction of the window, because everything it doesn't need gets thrown away before the next turn.

Three mechanisms, in the order I reach for them:

1. Compaction. Server-side summarization of earlier turns so the conversation continues past the limit without you writing a summarizer. It's the default answer for anything conversational and long-lived — how compaction behaves in practice covers where it's clean and where it drops detail you wanted.

2. Context editing. Clear stale tool results and old thinking blocks instead of summarizing everything. This is the surgical option, and in tool-heavy agents it's often the bigger win, because tool output is where the bloat actually lives. More on that in the memory tool and context editing writeup.

3. Subagents. Hand the big read to a separate agent with its own window and let it return three paragraphs. The parent never sees the 400k tokens of source material — which is the point, and also where the real token cost of subagents stops looking like overhead and starts looking like the cheapest thing in the stack.

And handle the ceiling explicitly. If input alone exceeds the window you get a 400 with “prompt is too long.” On 4.5 and newer, if input plus max_tokens overflows, the request is accepted and generation stops with stop_reason: "model_context_window_exceeded". That's a successful HTTP response containing a truncated answer. If your code only branches on exceptions, it will happily save that truncation as a finished result.