Context Window
APIDefinition
The maximum amount of text (measured in tokens) that Claude can process in a single request. Includes both input tokens (prompt, history, tool results) and output tokens. Exceeding the context window causes an error or requires context management strategies.
Example Usage
Monitor your context window usage to avoid hitting limits, especially with long conversations or large documents.
Why It Matters for the CCA-F Exam
The exam tests whether you can distinguish `model_context_window_exceeded` from `max_tokens`, identify which prompt components consume context, and choose appropriate mitigation strategies (caching, compression, rolling-window eviction) for different system designs.
In Depth
What the Context Window Actually Is
The context window is the total token budget available to a single API request. Every byte Claude can see or produce in one round-trip — your system prompt, the full conversation history, tool definitions, tool results, thinking blocks, and the generated reply — must fit within it. Think of it less like computer RAM and more like a finite whiteboard: everything written on it costs space, and nothing can spill off the edge.
Context is measured in tokens, not words or characters, which makes exact sizing hard to eyeball. A 1 M-token window (available on Claude Fable 5, Opus 4.8, Opus 4.7, and Sonnet 4.6) can hold roughly 750,000 words of English — a novel — but that number drops sharply for dense code, JSON, or tool schemas that tokenize less efficiently.
What Consumes the Window
| Slot | Typical size | Notes |
|---|---|---|
| System prompt | 1 K – 50 K tokens | Cached when stable |
| Conversation history | Grows per turn | Biggest runaway risk |
| Tool definitions | 500 – 5 K tokens | Multiplied by number of tools |
| Tool results | Variable | Large file reads can spike this |
| Thinking blocks | 0 – hundreds of K | Controlled by effort level |
| Output tokens | Up to model max | Counts against the same budget |
Hard Limits by Model
- Claude Fable 5 / Opus 4.8 / Opus 4.7 / Sonnet 4.6 — 1 M token context; output caps vary by model.
- Claude Haiku 4.5 — 200 K token context.
When the context fills completely, the API returns stop_reason: model_context_window_exceeded — distinct from max_tokens, which signals only that the *output* cap was hit. Treating these two identically is a common architectural mistake.
Managing the Window Strategically
Prompt caching lets you freeze stable prefixes (tools + system prompt) so they don't burn fresh input tokens on every call. For long agentic runs, combine that with context compression — summarising or evicting old turns — to keep each request well under the limit. The Lost in the Middle Effect is a related hazard: content buried in the middle of a very long context is retrieved less reliably than content at the start or end, so window size alone doesn't guarantee quality.
The practitioner rule of thumb: design your prompt architecture so that the expected steady-state request uses ≤ 50–60% of the window, leaving headroom for long model replies and tool-result spikes.
How It's Tested & Common Confusions
Expect scenario questions where a long-running agentic loop eventually fails — you must identify model_context_window_exceeded as the cause and propose a fix (e.g., context compression or a rolling window strategy). You may also see questions asking which model tier supports 1 M tokens versus 200 K, and questions that ask you to rank components by their token cost.
Frequently Asked Questions
Is the context window shared between input and output tokens?
Yes. The context window is a single combined budget. Input tokens (everything you send) plus output tokens (everything Claude generates) must both fit within it. On a 1 M-token model, if your request uses 900 K input tokens, only 100 K remain for the reply — regardless of the model's stated maximum output size.
What happens when the context window fills up during a long agentic run?
The API returns `stop_reason: model_context_window_exceeded`. This is different from `max_tokens`, which only signals that the output cap was reached. You must handle both cases explicitly in your loop control logic — and for `model_context_window_exceeded`, the right response is to compact or summarise the conversation history before retrying, not simply to retry the same request.