The context window is everything a model can reference in one request, including its own reply. That covers the system prompt, every earlier message, tool results, images, documents, tool definitions and reasoning output. Because history is resent each turn, long conversations get more expensive per turn even when your new message is short.
The list of what counts
Anthropic's context window documentation says everything in the request counts: the system prompt, every message including tool results, images and documents, and your tool definitions. The output the model generates for the turn counts too, including extended thinking. Cached prefixes still occupy the window. The same page puts it plainly: caching changes what you pay for those tokens, not whether they count.
| Item | Counts toward the window | Typical surprise |
|---|---|---|
| System prompt | Yes | Grows quietly as rules are added |
| Past turns | Yes | Resent every turn |
| Tool results | Yes | One large file read stays in history |
| Tool definitions | Yes | Many tools add a fixed overhead |
| Images and PDFs | Yes | Pages convert to many tokens |
| Reasoning output | Yes | Varies from request to request |
Why a conversation costs more each turn
Each turn consists of an input phase with the full history plus the new message, then an output phase whose text becomes part of the next turn's input. The documentation calls this progressive token accumulation. If a thirty turn session never trims anything, turn thirty pays for twenty nine turns of history again. Provider-side caching can soften the cost of the repeated part, as explained in how prompt caching works.
More context is not automatically better
The same page says that as token count grows, accuracy and recall degrade, a phenomenon it calls context rot, so curating context matters as much as having room. A bigger window is a ceiling, not a target.
Reasoning tokens
With thinking enabled, thinking tokens count toward the window and are billed as output tokens, per the documentation. Whether earlier turns' thinking stays in context depends on the model: some keep it by default and it then counts like any input, others strip it. For metering, read thinking tokens in LLM bills.
How to manage it
- Count before you send. Providers offer token counting endpoints, which the Anthropic page describes as a way to manage limits and costs.
- Clear old tool results in agent loops. The documentation names tool result clearing and thinking block clearing as context editing strategies.
- Summarize long histories. Server-side compaction summarizes earlier parts so a conversation can continue.
- Trim tool lists. The page points to ways to reduce tool definition overhead, including deferring definitions.
- Start new sessions per task.
See also long context pricing, and trimming agent context.
What happens at the limit
If input alone exceeds the window, the API returns a 400 error saying the prompt is too long. On newer models, if input plus the max output setting would exceed the window, the request is accepted and generation stops with a specific stop reason when it hits the limit. Handle that stop reason in your code so truncated answers are not treated as complete.
Worked example: a ten turn coding session
The numbers are illustrative. A session starts with a 3,000 token system prompt and 2,000 tokens of tool definitions, so 5,000 tokens of fixed overhead. Each turn the user adds 300 tokens, the assistant answers with 700, and one tool result of 4,000 tokens is added every other turn.
| Turn | New content added | Approximate input on that turn |
|---|---|---|
| 1 | 300 user | 5,300 |
| 2 | 700 reply, 4,000 tool result, 300 user | 5,300 + 1,000 + 4,000 + 300 = 10,600 |
| 3 | 1,000 | about 11,600 |
| 5 | with another tool result | about 17,600 |
| 10 | five more tool results | about 40,000 |
By turn ten, each call carries roughly eight times the fixed overhead, though the user only typed a few sentences. The cost per turn rises while the content added per turn stays flat. Clearing the old tool results at turn six would bring the input back down sharply.
Four levers, in order of effort
- Start a fresh session for each task. No tooling needed.
- Clear old tool results once they have been used. Documentation names this as context editing.
- Summarize earlier history. Server-side compaction does this for you on supported models.
- Cache the stable prefix so repeated tokens are read cheaply. See how prompt caching works.
Mistakes to avoid
- Assuming caching removes tokens from the window. It changes pricing only.
- Letting an agent read whole files when a search would do.
- Forgetting that images and PDF pages convert to many tokens.
- Setting a high output ceiling and not handling truncation. See the max output setting.
Reading your own usage data
Every response reports what the request consumed. Export those usage fields for a week and plot input tokens per turn for a few real sessions. Look for staircases, where each turn jumps because a large tool result was added, and for long flat tails, where old history is carried but no longer useful. These two shapes tell you where to clear or summarize. Teams that do this once usually find that a handful of tools account for most of the input volume, and they can fix those first.
A review checklist for an existing app
If you inherit an AI feature, audit its context in an hour. Print the full request for a typical call. Count each part: system prompt, history, retrieved documents, tool definitions, and tool results. Mark each part as needed, nice to have or dead weight. Remove dead weight first, since it costs on every call. Then look at whether history is trimmed, whether retrieved documents are limited to the most relevant, and whether tool results are summarized or cleared after use.
Re-run your evaluation set after each change, so you know the trimmed version is not worse. Context cuts that look free sometimes remove a fact the model needed. Keep the before and after token counts in your notes, so the saving is documented.
What this means for you
If you build with AI, the context window is the budget for everything the model sees, and you are billed and limited by what you put in it. The prompt you type is usually a small part. History, tool results and definitions are often the bulk, and you can shrink them.
Common mistakes
Typical errors are letting history grow without bound, keeping every tool result in context after it has been used, attaching many tools by default, pasting whole files when a snippet would do and assuming caching removes tokens from the window. Another is to treat a large window as permission to fill it, when accuracy can fall as context grows. Measure a real session, find what dominates and clear or summarize it.
Try it yourself
Click through it at your own pace, or open it full screen. It shows an assistant working across a task with tool results coming back. Each tool call and result in a real session lands in the context window, so think about which ones you would clear.
Quick check
Does my cached prompt count toward the context window?
Yes. Caching changes pricing for those tokens, not whether they occupy the window.
Do tool definitions count?
Yes. They are part of the request and count toward the window.
Is a bigger window always better?
No. The documentation says accuracy and recall can degrade as token count grows, so curate what goes in.
Sources
Last reviewed: 19 October 2026.
