Context Window Budget and Tool Output Pruning

1.What actually fills the context window

The context window is the model's working memory for one request. It holds all the text Claude can refer to while it writes a response, and the response itself takes up room too. In a standard API conversation nothing falls out by itself. Each turn's user message and assistant reply are added and kept in full, so every request carries the whole history plus the new message. The 1M-token models (including Claude Opus 5.5, Claude Sonnet 5.5 and Claude Fable 5.1) offer a lot of room. Other models, such as Claude Sonnet 4.5, have 200k. But the docs are clear that more context isn't automatically better. Accuracy and recall drop as the token count grows. The exam guide calls this "context drift", and the documentation calls it context rot. It is why the rest of this lesson is about removing things.

Before you can prune anything, you need an accurate count of what is in the window. Everything in the request counts: the system prompt, every message (including tool results, images and documents), and your tool definitions. Claude's output for the turn counts too, extended thinking included. Each response's usage field reports what the request used, and the token counting API estimates a request before you send it. Previous thinking blocks are handled differently by model generation. Claude Opus 4.5 and later Opus models, Claude Sonnet 4.6 and later Sonnet models, and the Fable and Mythos models keep them by default, and they count as ordinary input. Earlier Opus and Sonnet models and all Haiku models strip them automatically when you pass them back.

Some models can see their own budget. Claude Sonnet 5, Sonnet 4.6, Sonnet 4.5 and Haiku 4.5 have context awareness. The API puts a <budget:token_budget> tag in the system prompt and sends a usage system_warning after each tool call, so the model can pace a long task against the space it has left. You never send these tags yourself. Claude Opus 4.7 and later Opus models, Claude Sonnet 5.5, and the Fable and Mythos models don't get them. For those, the beta task budgets feature lets you give an explicit budget.

Sources1

2.Pruning stale tool output with context editing

In agentic workflows, tool results usually grow fastest. A file Claude read twenty turns ago, or a search result it has already used, keeps taking space and attention on every later request. Context editing deals with this by clearing specific content from the history according to rules you set. The docs frame this as curation, not only a way to cut cost: context is finite, it gives diminishing returns, and irrelevant content hurts focus. You turn it on with the context-management-2025-06-27 beta and a context_management object that lists edits.

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Search for recent developments in AI"}],
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    betas=["context-management-2025-06-27"],
    context_management={"edits": [{"type": " ? "}]},
)

Once the trigger is crossed, the API clears the oldest tool results in chronological order. Each one becomes a placeholder. By default only the results are cleared and Claude's tool calls remain. Set clear_tool_inputs to true to clear the call parameters as well. The edit happens on the server before the prompt reaches Claude, so your client keeps the full, unmodified history. You don't have to sync your local state with the edited version.

    context_management={
        "edits": [
            {
                "type": "clear_tool_uses_20250919",
                # Trigger clearing when threshold is exceeded
                "trigger": {"type": "input_tokens", "value": 30000},
                # Number of tool uses to keep after clearing
                "keep": {"type": "tool_uses", "value": 3},
                # Optional: Clear at least this many tokens
                "clear_at_least": {"type": "input_tokens", "value": 5000},
                # Exclude these tools from being cleared
                "exclude_tools": ["web_search"],
            }
        ]
    },

clear_at_least exists because of prompt caching. Clearing tool results invalidates the cached prefix at the point where content is removed, so a small clear means paying a cache write for very little space. If the API can't clear at least the amount you set, it skips the edit. The companion strategy, clear_thinking_20251015, uses keep (for example {type: "thinking_turns", value: 2}, or "all") to decide how many recent thinking turns survive. Keeping them preserves the cache. Clearing them frees space but invalidates the cache from that point. You can list both strategies in one edits array.

Sources2

3.Matching the fix to the source of bloat

Context editing removes results after they have served their purpose. That is only one of four approaches, and each one works at a different point in the pipeline. Tool definitions and the tool_result blocks that pile up both use the window, so start by finding where your tokens are actually going. Tool search keeps definitions out of the window until Claude asks for them: one tool_search tool replaces dozens of upfront schemas, at the cost of an extra turn. Programmatic tool calling turns a chain of calls into one script that runs in Anthropic's code execution sandbox, so the intermediate results never enter the history. Prompt caching doesn't reduce the token count. It only cuts what you pay for a stable prefix.

You can combine these approaches. The suggested order for a high-volume agent is: cache tool definitions from day one, add tool search once the toolset passes roughly 20 tools, add context editing when conversations run long enough for early results to stop mattering, and consider programmatic tool calling when you see repeated chains of small calls.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Prompt caching shrinks how much of the context window a large, stable prefix uses.Why is that wrong?

   Cached tokens still count toward the window in full. Caching only changes their price, so it does nothing against context rot or the window limit.

   Covered in What actually fills the context window

2. 2.After turning on context editing, your client has to delete the cleared tool results from its own message history to stay in sync.Why is that wrong?

   Context editing runs on the server before the prompt reaches Claude. The client keeps and resends the full, unmodified history.

   Covered in Pruning stale tool output with context editing

3. 3.Tool result clearing is free from a caching point of view, because it only removes tokens.Why is that wrong?

   Clearing invalidates the cached prefix where content is removed, so each clear costs a cache write. clear_at_least exists to make sure that cost is worth paying.

   Covered in Pruning stale tool output with context editing