Context Window

Everything in the request shares one budget

The context window is everything the model can see while it answers, including the answer it is writing. Anthropic's documentation calls it "working memory" and is explicit about the scope: the system prompt, every message including tool results, images and documents, your tool definitions, and the output the model generates for the turn.

That last item is the one people miss. The window is not an input limit with output on top. Input and output come out of the same budget, which is why a request that fits can still fail partway through writing.

The numbers, and where they stop

On Anthropic's current line, checked 2026-09-25, Claude Opus 5, Opus 5.5, Sonnet 5, Fable 5.1 and several others have a 1M-token context window, and a single request to any of them can generate up to 128k output tokens. Claude Sonnet 4.5 and other earlier models have 200k.

A million tokens is roughly a long novel. It is enough that most applications never approach it, and the interesting limits become the ones below.

A single request can also include up to 600 images or PDF pages on the 1M models, 100 on the 200k ones. The documentation notes you might hit request size limits before the token limit if you send many images.

More context is not better context

The temptation with a large window is to stop deciding what goes in it. The documentation names the reason not to:

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.

So the window is a ceiling, not a target. A prompt that fills 800k tokens because nobody filtered the retrieval results is worse than one that fills 8k with the right ones, and it costs a hundred times as much. Long context processing covers what degrades and where.

Caching changes the bill, not the budget

Prompt caching is easy to mistake for a way to fit more in. It is not:

Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count.

The usage figures make the same point. Input arrives split across input_tokens, cache_read_input_tokens and cache_creation_input_tokens, and all three count toward the window. Prompt caching covers what the split does to the bill.

Two different failures at the edge

The window does not have one overflow behavior, and the difference decides what your code has to handle.

The input alone is too long. The API returns a 400 invalid_request_error with "prompt is too long", on every model. Nothing was generated and nothing was charged for generation. This is a request you can fix before sending, which is what the token counting API is for.

The input fits but generation runs into the ceiling. On Claude 4.5 models and newer, the API accepts a request whose input_tokens plus max_tokens exceeds the window, and if generation reaches the limit it stops with stop_reason: "model_context_window_exceeded". You get a partial answer and a success status.

The second is the dangerous one, because it looks like an ordinary response. Code that reads content[0].text without checking stop_reason will happily parse a truncated answer and act on it. Check the stop reason on every generation you act on, not only when you suspect a problem.

Thinking counts, and sometimes twice

With extended thinking, thinking tokens come out of max_tokens, are billed as output, and count toward the window.

Whether they keep counting depends on the model. On Claude Opus 4.5 and later, Sonnet 4.6 and later, and the Fable and Mythos models, the API keeps previous thinking blocks by default and they count as input on every later turn. On earlier Opus and Sonnet models and all Haiku models, the API strips them from the history automatically when you pass them back.

For a long agent conversation that is a large difference in where the window goes, and it is set by the model rather than by anything in your request.

Running out of room on purpose

When conversations regularly approach the limit, the answer is to decide what survives rather than to wait for the error.

Anthropic offers server-side compaction, in beta for Claude 4.6 and later, which summarizes earlier parts of the conversation so it can continue past the limit. Context editing is the more surgical option: clearing old tool results, or clearing thinking blocks.

Doing it yourself is the subject of state and historical context, which also covers the trap where trimming a turn per request costs more than sending everything, because it breaks the cache.

Further reading

• Anthropic, Context windows: the sizes, the overflow behaviors, and how thinking is counted.
• Stop estimating tokens: counting the unit this budget is denominated in.
• Prompt caching: what the cache does to the price of a prefix that still occupies the window.
• Long context processing: what degrades as the window fills.