The Claude 1M-token context window: what it is good for

Which Claude ids actually have it

Nine of the twelve Claude ids in this catalog carry a 1,000,000-token context with a 128,000-token output ceiling: claude-opus-5, claude-opus-4-8, claude-opus-4-6, claude-sonnet-5, their stable-* twins, and both Fable ids — stable-claude-fable-5 and stable-claude-fable-5-1.

Three do not. claude-sonnet-4-6 and stable-claude-sonnet-4-6 are served at 200,000 tokens with a 64,000-token output ceiling, and stable-claude-haiku-4-5 is 200,000 and 64,000 as well.

Context size does not track price. claude-sonnet-5 gives you the full million at $3/$15 official on a 0.1× multiplier, the same official rate as the 200,000-token claude-sonnet-4-6. The window is not what you are paying more or less for.

What a full window costs

Do the arithmetic before designing around the window. Input on claude-sonnet-5 is $3 per million official at 0.1×, so $0.30 as billed. Filling the context once is therefore $0.30 of input on Sonnet 5 and $0.50 on claude-opus-5, which is $5 per million official at the same multiplier.

The number that matters is not that one call, though — it is that a conversation re-sends its context on every turn. A twenty-turn session that keeps a near-full window resends close to a million tokens twenty times, and the input line on your bill grows linearly with turns while the answer quality does not.

This is why "paste the whole repository in" is a spending decision and not a technique. The model charges the same per token whether those tokens were load-bearing or not.

# max_tokens 1 keeps the answer short so usage.input_tokens is what you are reading.
curl -sS https://token-share.app/v1/messages \
  -H "x-api-key: $TOKEN_SHARE_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1,
    "messages": [{"role": "user", "content": "Paste the working set you were about to send here."}]
  }' | jq '.usage'

# claude-sonnet-5 bills $0.30 per 1M input tokens.
# input cost = input_tokens / 1e6 * 0.30, charged again on every turn that resends it.

Where the room genuinely earns its keep

The window pays off when the alternative is worse than paying for tokens. A working set that cannot be split without losing the cross-references — a schema plus the migrations that touch it, a bug that only makes sense with three services in view — is the clearest case: chunking it means the model answers each piece correctly and the whole thing wrong.

Long agent runs are the second case. A tool-calling loop accumulates transcript, and a session that would otherwise need truncation or summarisation mid-run can just continue. What you are buying is the absence of a compaction step, not better reasoning.

The 128,000-token output ceiling on the 1M ids is a separate lever and often the one people actually needed. Generating a long file or a full migration in a single response is bounded by max output, not by context.

Room is not recall, and caching is the lever

A large window does not make the model attentive to everything inside it. Filling the context with material that has no bearing on the question adds cost and gives the model more to sift; a shorter, better-selected prompt frequently produces a better answer than a longer one, and it is cheaper.

When a long prefix genuinely repeats across turns — a system prompt, a spec the conversation keeps returning to — prompt caching is what makes the window affordable. Cached reads are billed as their own class, separately from fresh input, so a stable prefix stops being charged at the full input rate every turn.

The practical test is simple: measure the input tokens you are actually sending per request, and check what fraction of them changed since the last turn. If most of the prompt is identical turn to turn, the fix is caching. If most of it is different, the window is doing real work and you are paying for real work.

Common questions