The Context Window as a Shared Token Budget

What the Context Window Is

The **Context Window** is the maximum number of tokens -- input plus output combined -- that a model can consider in a single request. It is a hard ceiling: exceed it and the request either fails outright or the content has to be truncated or summarized before it fits.

It Is Shared, Not Partitioned

Critically, the Context Window is not a set of separate allowances for different kinds of content -- it is one shared budget that every component of a request draws from together:

• The system prompt
• The conversation history
• Tool definitions
• Tool results
• The model's own response

A Token spent on a verbose tool result is a Token unavailable to the response, and vice versa. There is no dedicated "tool results budget" separate from the "conversation budget" -- they all compete for the same pool.

Sizing Requests Against the Window

Because the window is shared, a request that looks fine in isolation (a reasonable system prompt, a reasonable conversation) can still fail once tool definitions and tool results are added on top. Estimating whether a request fits means summing across *all* of these categories, not just the most obvious one (e.g., the user's message).

Common exam traps

• Assuming a bigger Context Window is automatically cheaper or that size alone solves budgeting -- a larger window permits more tokens to be included, but you still pay per token used, and it still doesn't fix the need to manage what's included.
• Treating the Context Window as reserved per-category (e.g., assuming tool results have their own separate limit from conversation history) rather than as one pooled budget.