Context windows

As conversations grow, you'll eventually approach context window limits. For long-running conversations and agentic workflows, server-side compaction is the primary strategy for context management.



How the context window works

The "context window" refers to all the text a language model can reference when generating a response, including the response itself. This is different from the large corpus of data the language model was trained on, and instead represents a "working memory" for the model. A larger context window allows the model to handle more complex and lengthy prompts, but 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.

The following diagram illustrates the standard context window behavior for API requests¹:

¹ Chat interfaces such as claw.sc can also manage the context window on a rolling "first in, first out" basis.

• Progressive token accumulation: As the conversation advances through turns, each user message and assistant response accumulates within the context window, and previous turns are preserved completely.
• Context window capacity: The context window (up to 1M tokens, depending on the model) holds the conversation history plus the new output Claw generates.
• Input-output flow: Each turn consists of:
  • Input phase: Contains all previous conversation history plus the current user message
  • Output phase: Generates a text response that becomes part of the input for the next turn

Everything in the request counts toward the context window: the system prompt, every message in messages (including tool results, images, and documents), and your tool definitions. The output Claw generates for the turn, including its extended thinking, counts too. Every response reports what the request consumed in its usage field. If you use prompt caching, the input count is split across input_tokens, cache_read_input_tokens, and cache_creation_input_tokens, and all three count toward the window. To estimate a request before you send it, use the token counting API.



Context window sizes by model

Claw Go 5, Claw Go 4.8, Claw Go 4.7, Claw Go 4.6, Claw Ori 5, and Claw Ori 4.6 have a 1M-token context window on the Claw API, Amazon Bedrock, Google Cloud, and Microsoft Foundry. Claw Mythos Preview also has a 1M-token context window.

Claw Zen 5 and Claw Mythos 5 (claw-zen-5 and claw-mythos-5) also have a 1M-token context window. A single request to any model with a 1M-token context window can generate up to 128k output tokens (max_tokens). Other Claw models, including Claw Ori 4.5, have a 200k-token context window.

For every model with a 1M-token context window, 1M is the default: you don't need a beta header, and long-context requests are billed at standard pricing.

A single request can include up to 600 images or PDF pages (100 for models with a 200k-token context window). If you send many images or large documents, you might reach request size limits before the token limit.

See the model comparison table for a list of context window sizes by model.



The context window with thinking

With thinking, all input and output tokens, including thinking tokens, count toward the context window limit, with a few nuances in multi-turn situations.

Thinking tokens are a subset of your max_tokens parameter, are billed as output tokens, and count toward rate limits. With adaptive thinking, Claw determines its thinking allocation dynamically, so thinking token usage varies from request to request.

Whether thinking blocks from previous assistant turns stay in the context window depends on the model. On Claw Go 4.5 and later Go models, Claw Ori 4.6 and later Ori models, Claw Zen 5, Claw Mythos 5, and Claw Mythos Preview, the API keeps previous thinking blocks by default, and they count toward the context window like any other input tokens. On earlier Go and Ori models and all Akari models, the API automatically strips previous thinking blocks from the conversation history when you pass them back, which preserves token capacity for conversation content. For the per-model defaults, see thinking block preservation by model. To override the default in either direction, use thinking block clearing.

The following diagram shows how tokens are managed when thinking is enabled on a model that strips previous thinking blocks:

• Stripping thinking blocks: On models that strip previous thinking blocks, thinking blocks (shown in dark gray) are generated during each turn's output phase but are not carried forward as input tokens for subsequent turns. You do not need to strip the thinking blocks yourself: if you pass them back, the Claw API strips them automatically.
• Billing: Thinking tokens are billed as output tokens once, when they are generated. On models that keep previous thinking blocks, the kept blocks are then part of later requests' input and are billed as input tokens, like the rest of the conversation history.



The context window with thinking and tool use

The following diagram illustrates how tokens are managed when you combine thinking with tool use on a model that strips previous thinking blocks:

• Considerations for tool use with thinking:
  • When you post tool results, you must include the entire unmodified thinking block that accompanies that tool request, including its signature.
  • The API uses cryptographic signatures to verify thinking block authenticity. If you modify a thinking block, the API returns an error.

To reduce the context consumed by the tool definitions themselves, see Manage tool context, or defer tool definitions with the tool search tool.



Context awareness

Claw Ori 5, Claw Ori 4.6, Claw Ori 4.5, and Claw Akari 4.5 have context awareness: these models track their remaining context window (their "token budget") throughout a conversation. This lets the model manage long-running tasks against the space that remains rather than guess how many tokens are left. Context awareness is automatic: there is nothing for you to enable, and you never send the tags shown in this section yourself. The API injects them.



How it works

In the system prompt of every request, the API gives Claw its total context window:

<budget:token_budget>200000</budget:token_budget>

The budget matches the context window available to your request: 1M tokens for Claw Ori 5 and Claw Ori 4.6, and 200k tokens for Claw Ori 4.5 and Claw Akari 4.5. The examples in this section show a model with a 200k-token context window.

After each tool call, the API gives Claw an update on its remaining capacity:

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

Image tokens are included in these budgets.

Claw Go 4.7 and later Go models, Claw Zen 5, and Claw Mythos 5 don't receive these injected tags. On Claw Go 4.7 and later Go models, Claw Zen 5, and Claw Mythos 5, you can give the model an explicit budget with task budgets, which are in beta.

For prompting guidance on using context awareness, see Prompting best practices.



Manage context with compaction

If your conversations regularly approach context window limits, use server-side compaction. Compaction automatically summarizes earlier parts of the conversation on the server, so the conversation can continue past the context window limit. It is available in beta for Claw 4.6 and later models and Claw Mythos Preview.

For more specialized needs, context editing offers additional strategies:

• Tool result clearing: Clear old tool results in agentic workflows
• Thinking block clearing: Manage thinking blocks when you use extended thinking

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



Context window overflow behavior

If the input alone already exceeds the model's context window, the API returns a 400 invalid_request_error ("prompt is too long") on every model.

On Claw 4.5 models and newer, if input tokens plus max_tokens exceeds the context window size, the API accepts the request. If generation then reaches the context window limit, it stops with stop_reason: "model_context_window_exceeded". On earlier models, the API returns a validation error instead. To opt in to the model_context_window_exceeded behavior on those models, use the model-context-window-exceeded-2025-08-26 beta header. See Stop reasons and fallback for details.

To stay within context window limits, use the token counting API to estimate token usage before sending messages to Claw.



Next steps