Claude Haiku’s Context Window and Output Cap

Haiku is the small, fast tier of the Claude line, and its output cap has moved by more than an order of magnitude across generations while its context window has not moved at all. Those two facts are the whole of what most people are looking for when they search this.

The documented figures

Anthropic publishes a model comparison table listing context window and maximum output tokens for every model it serves. As of this page’s date, that table gives the Haiku line as follows — each figure is from Anthropic’s model overview, which is the primary source and the one to check rather than this page:

• Claude 3 Haiku — 200,000-token context window, 4,096 maximum output tokens.
• Claude 3.5 Haiku — 200,000-token context window, 8,192 maximum output tokens.
• Claude Haiku 4.5 — 200,000-token context window, with a maximum output token count in the tens of thousands rather than the thousands, in line with the other Claude 4 models.

The shape of that list is the useful part. The context window has been 200,000 tokens across every Haiku released so far, while the output cap has moved by more than an order of magnitude in the same period. So if you are carrying an assumption from an older integration, it is almost certainly the output cap that is wrong, and code that hard-codes 4,096 because that is what Claude 3 Haiku allowed is leaving most of the available response length unused.

Context window and output cap are separate

These are two different numbers doing two different jobs, and conflating them is the source of most of the confusion around this search.

The context window is the total size of the sequence the model can hold: system prompt, every message in the conversation, tool definitions, tool results, images, and the tokens it generates in this turn, all counted together. Exceed it and the request fails before generation starts. The output cap is a ceiling on the generated portion alone, and it is far smaller. A 200,000-token context with an 8,192-token output cap means you may send Claude 3.5 Haiku a 190,000-token document and it will still refuse to write you more than 8,192 tokens back in a single turn.

There is a third number in the middle, which is max_tokens in your request. It is required on every Messages API call — there is no default — and it must be less than or equal to the model’s output cap. Its job is to bound the generation, not to request a length: the model stops when it is finished or when it hits max_tokens, whichever comes first, and hitting the ceiling shows up as stop_reason: "max_tokens" with the text cut off mid-sentence. Every value that field can take is listed on Claude’s stop_reason field.

Why the output cap is the smaller number

The asymmetry is not arbitrary, and understanding it is what stops you treating the cap as a bug to be worked around. Reading a prompt and writing an answer are different operations on the hardware. The prompt is processed in one pass over the whole sequence, because every token in it is already known — that work is parallel and bounded by arithmetic throughput. Generation is the opposite: one forward pass per token, each depending on the last, with the model’s weights streamed from memory every time. A 190,000-token prompt is a single large parallel operation; a 190,000-token answer would be 190,000 sequential ones.

A serving system therefore has to bound the generated portion for reasons that have nothing to do with what the model is capable of. An uncapped request occupies a decode slot indefinitely, and slots are the scarce resource under load. The output cap is what keeps one pathological request from starving a batch, and it is why the number rises generation by generation as serving efficiency improves while the 200,000-token window has stayed put across the whole Haiku line.

Two things follow that are useful in practice. Long output is slow in proportion to its length, so a request near the cap is not just at risk of truncation — it is also the request most likely to hit a client timeout, and streaming is close to mandatory above a few thousand tokens. And output tokens are priced well above input tokens for the same underlying reason, so “summarise this in 200 words” is a cost control as much as a style instruction.

What happens when max_tokens is too large

Asking for more output than the model can produce is not clamped silently. The API returns HTTP 400 with an invalid_request_error whose message names both your value and the model’s cap, in this shape:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "max_tokens: 16000 > 8192, which is the maximum allowed number of output tokens for claude-3-5-haiku-20241022"
  }
}

This is a useful error to hit on purpose. Because the message contains the model’s own cap, a single deliberately oversized request is the fastest way to discover the current limit for a model ID without reading a table — send max_tokens at some absurd value, read the number back out of the error, and set it correctly. It costs nothing, because the request is rejected before any tokens are generated.

Omitting max_tokens altogether produces a different error, about a missing required field rather than an out-of-range one; that case is covered in the max_tokens required error.

Budgeting a request against both limits

The arithmetic that actually matters when you are sizing a Haiku request:

1. Count the input. Use the token-counting endpoint rather than estimating — it accepts the same model, system, messages and tools as a real request and returns input_tokens without generating anything or charging for generation. See the count_tokens endpoint.
2. Check that input_tokens + max_tokens is under the context window. This sum, not the input alone, is what has to fit.
3. Check that max_tokens alone is at or under the model’s output cap.
4. If you are using extended thinking, add budget_tokens into the output side of that budget — thinking tokens are output tokens and count against both max_tokens and the cap.

For work that genuinely needs a long single response — a full document translation, a large generated file — the output cap, not the context window, is the constraint that decides whether Haiku is the right tier at all. Chunking the job into several turns is the usual answer, and it also keeps each response inside a size where a max_tokens truncation is recoverable rather than a whole wasted call.

One habit is worth adopting regardless of tier: set max_tokens to what the task actually needs rather than to the model’s maximum. It costs nothing to set it high — you are billed on tokens generated, not on tokens allowed — but a tight value is a circuit breaker. A prompt that has gone wrong and put the model into a repetition loop stops at your ceiling rather than at the model’s, and the difference between those two numbers is the difference between a cheap failed request and an expensive one. Pair that with checking stop_reason on every response, and a truncation becomes something your code notices rather than something a user reports.