Claude Context Window: Size, What Counts Toward It, and How to Manage It

Most current Claude models have a 1 million token context window, and a single request can generate up to 128,000 output tokens. Anthropic’s documentation lists Claude Fable 5.1, Fable 5, Mythos 5.1, Mythos 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5 and Sonnet 4.6 as having the 1M window, with other models including Sonnet 4.5 at 200,000 tokens. For every model with the larger window, 1M is the default and requires no beta header.

The size is the easy part. What actually causes problems is what counts toward that total, and the fact that filling it is not free in accuracy terms.

Key points

• 1 million tokens on current models, with 128,000 maximum output tokens per request.
• Everything in the request counts. System prompt, every message, tool results, images, documents and your tool definitions.
• The model’s own output counts too, including extended thinking tokens.
• Cached input still counts. Caching changes the price, not the window occupancy.
• More context is not automatically better. Anthropic documents accuracy and recall degrading as token count grows.

What counts toward the window

This is where most people’s mental model is wrong, and it produces surprises at exactly the wrong moment.

The context window covers all the text the model can reference when generating a response, including the response itself. Anthropic describes it as working memory, distinct from the training data the model learned from.

Everything you send occupies it: the system prompt, every message in the conversation including tool results, images and documents, and your tool definitions. That last item catches people out regularly, because tool schemas are easy to forget about and a large set of them consumes real space before any conversation has happened.

The output side counts as well. The response the model generates becomes part of the input for the next turn, and extended thinking tokens count toward the total in the turn that produces them.

If you use prompt caching, the input count splits across three fields: input_tokens, cache_read_input_tokens and cache_creation_input_tokens. All three count toward the window. Caching reduces what you pay, not what you occupy, and conflating those two is a common and expensive mistake.

Every response reports consumption in its usage field, and a token counting API lets you estimate a request before sending it. Using the second of these during development saves a great deal of guesswork.

How a conversation accumulates

The pattern is straightforward once stated. Each turn adds the user message and the assistant response to what already exists, and previous turns are preserved completely. Nothing is summarised or dropped automatically on the API.

That means a long agentic run does not consume context linearly with the useful work done. It consumes context with every tool result, every retrieved document and every intermediate step, most of which stop being relevant within a few turns. A session that reads forty files while searching for something carries all forty for the remainder of the run.

Chat interfaces behave differently. Anthropic notes that claude.ai can manage the window on a rolling first in, first out basis, which means the oldest material drops out as new material arrives. That is convenient in a conversation and unsuitable for work that depends on something said an hour ago.

Where the space actually goes

It helps to look at a realistic breakdown, because the intuitive answer is usually wrong.

Take a coding agent working through a task. The system prompt and tool definitions might be a few thousand tokens, present on every request. The user’s actual instruction is perhaps two hundred tokens. Everything else is accumulated tool output: files read, search results, command output, error messages, and the model’s own reasoning about all of it.

After twenty minutes of work, the ratio is frequently something like ninety-five percent accumulated material to five percent the thing anyone cares about. Most of that ninety-five percent stopped being relevant several turns ago. The file that turned out not to contain the bug is still there. So is the search that returned nothing useful.

This is why context pressure arrives suddenly rather than gradually from the user’s point of view. Nothing about the task got bigger. The exploration did, and it accumulated silently.

It also explains why delegating exploration works so well as a fix. The forty files read during a search cost the main conversation one summary instead of forty files, and the difference compounds over a long session.

Why filling the window is a bad default

Anthropic states this directly in the documentation rather than leaving it implied, and it is the single most useful thing in the page.

As token count grows, accuracy and recall degrade. The documentation calls this context rot. A model with a million tokens available does not attend equally well to all of them, and material buried in the middle of a very large context is retrieved less reliably than the same material in a smaller one.

The practical conclusion follows directly: curating what is in context matters as much as how much space is available. A carefully assembled 50,000 token context frequently outperforms a lazily assembled 500,000 token one on the same task, and it costs an order of magnitude less.

There is a failure mode worth recognising here, because it is easy to misdiagnose. When a model misses something that is genuinely present in a very long context, the instinct is to conclude the model is not capable enough and reach for a stronger one. Often the better fix is a shorter context. Moving from a weaker model with a clean prompt to a stronger model with the same cluttered prompt tends to disappoint, and it costs considerably more.

This reframes what the large window is for. It is headroom that prevents a task failing outright, not an invitation to stop thinking about relevance. The teams getting the most from long context treat it as a safety margin rather than a working target.

Managing context as conversations grow

For long-running conversations and agentic workflows, Anthropic identifies server-side compaction as the primary strategy. Rather than accumulating indefinitely until the window fills, the conversation is condensed so the useful state survives and the raw history does not.

Alongside that, several practices reduce pressure before it becomes a problem.

• Push exploration into subagents. Work that generates a lot of output you do not need afterwards, such as searching many files, belongs in a separate context that returns only its conclusion.
• Trim tool definitions. A large tool schema occupies the window on every single request, whether or not the tools are used.
• Cache the stable prefix. Caching does not reduce occupancy, but it makes a large stable system prompt substantially cheaper to send repeatedly.
• Count before you send. The token counting API removes the guesswork from whether a request will fit.
• Watch the usage field. It tells you what each request actually consumed rather than what you assumed.
• Summarise deliberately. Deciding what to carry forward yourself produces better results than letting a window fill and hoping something useful survives.
• Put the important material at the edges. Recall is strongest at the beginning and end of a long context, so instructions that must be followed belong somewhere other than the middle of a large block.

What to know before deciding

Two things follow from that table for planning purposes.

The output ceiling is separate from the window. A model can hold a million tokens of context and still only produce 128,000 in one response. Work that needs a longer output has to be structured across multiple requests regardless of how much room the input has.

The 200,000 token models are not obsolete. For most tasks a 200K window is ample, and the cost per token matters more than the ceiling you will never approach. Checking the models overview for the price and window together is a better basis for choosing than window size alone.

Decision framework

Five questions when context is becoming a constraint.

1. Is the window actually full, or is retrieval failing? These look similar and have opposite fixes. Check the usage field before assuming.
2. What proportion of your context is still relevant? In long agentic runs it is frequently under a fifth, and the rest is exploration output.
3. Can the noisy work move to a subagent? Delegating exploration keeps the main context clean and is usually the largest single improvement available.
4. Are your tool definitions large? They cost you on every request, and trimming unused ones is quick.
5. Would a smaller, better-curated context work? Given documented context rot, the answer is more often yes than people expect.

Knowing how these systems consume context, and where their recall degrades, is a general skill rather than a vendor-specific one. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.

Your next step

Before assuming you need more context, look at the usage field on a few representative requests and work out what is actually consuming it. Most people find tool definitions and accumulated tool results account for far more than the material they were thinking about.

One more thing worth checking is the shape of the cost, not just the fit. A request that fits comfortably inside a million tokens can still be expensive to send repeatedly, and the difference between a well-cached stable prefix and an unstructured prompt rebuilt each time is substantial over a working day. Fitting and affording are separate questions, and it is easy to solve the first while quietly failing the second.

Then move your noisiest work into a separate context that returns only a summary. Exploration is almost always the largest contributor, it is the easiest to isolate, and doing so improves both the cost and the quality of what remains.

FAQ