Claude Context Window: Opus 5 and Every Model's Limit

Claude Opus 5, launched 2026-07-24, has a 1M-token context window — no beta header, no long-context price premium — and up to 128K output tokens, per Anthropic. Opus 4.8, Sonnet 5 and Fable 5 are also 1M / 128k on the synchronous Messages API; Haiku 4.5 is 200k / 64k, and the older Claude line (including Sonnet 4.5, Opus 4.5, and Opus 4.1) sits at 200k. But the number people actually trip over is not the window — it is the difference between the context window (all input plus the generated output, combined) and max_tokens (a per-request cap on output alone). This guide is the per-model reference table, the context-vs-max_tokens distinction spelled out, what a 1M window actually holds, how to use it without burning cost — and the one Opus 5 run we measured ourselves, which tells you nothing about long context and says so.

Every Claude model's context window and max output

Claude Opus 5 is 1M context / 128K output. So are Opus 4.8, Sonnet 5 and Fable 5 — and, further back, Opus 4.7, Opus 4.6 and Sonnet 4.6. Haiku 4.5 is 200k / 64k, and everything before the 4.6 generation is 200k. The single reference table, from Anthropic's model overview and the Opus 5 launch documentation (synchronous Messages API limits):

The 300k Batches figure covers Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, and Sonnet 4.6 via the output-300k-2026-03-24 beta header. Opus 5 Fast is the exception, and not for a subtle reason: Anthropic documents “fast mode” as a research-preview speed setting on Opus 5 and Opus 4.8 — billed at $10 / $50 per MTok across the full context window, not a separate model — and it is not available with the Batch API. Our catalogue exposes it as its own model id, which is why it gets its own row here. Its output cap reads not verified because Anthropic states the 128K figure for Opus 5 itself and gives no separate figure for fast mode. Sources: Anthropic model overview and anthropic.com/claude/opus (checked July 2026). Choosing between the two tiers of Sonnet and Opus? See Claude Sonnet vs Opus.

Claude Opus 5: 1M context, and no long-context premium

Claude Opus 5 launched 2026-07-24 with a 1M-token context window, no beta header, no long-context price premium, and up to 128K output tokens. Those are Anthropic's figures, not ours. The third of them is the one worth reading twice.

A big window can cost more than the sticker rate implies when a provider tiers its input price above some token threshold, or gates the large window behind a flag that bills differently. That is the usual billing surprise on long-context work: the rate card you budgeted against is not the rate you paid, because your prompt crossed a line you did not know was there. Anthropic states that neither applies to Opus 5. The 1M window is on by default, and the input and output rates do not change as the prompt gets longer. You can multiply prompt tokens by one number and be done.

Anthropic also positions Opus 5 as approaching Claude Fable 5's intelligence at half the price. That is their claim and we are repeating it as theirs: we have never run Fable 5 through our benchmark, so we have no measured basis to agree or disagree. Sources: anthropic.com/claude/opus plus the 2026-07-24 launch coverage. The per-token rates are from our own catalogue on the date shown; see the Claude API pricing guide for the full rate card.

Practically, the “no premium” detail is what makes the 1M window a planning number rather than a risk. Your cost ceiling for a full-window request is prompt tokens times the standard input rate, plus output tokens times the standard output rate. Nothing steps. What still bites is that a 1M prompt is 5× the input tokens of a 200k prompt — the window is free of surcharges, not free. The caching arithmetic that makes long input affordable is in our cost guide.

What we measured on Opus 5, and what it cannot tell you

Everything above is Anthropic's. Here is the part we ran ourselves, so you can see exactly how narrow it is.

On 2026-07-30, Claude Opus 5 scored 9/9 on our executed nine-task Python benchmark at a measured $5.64 per 1,000 tasks, averaging 5.3 s per task. Claude Opus 5 Fast also scored 9/9, at $10.20 per 1,000 tasks and 3.4 s. Both emitted 6 reasoning tokens on average. Opus 5 Fast is the second-fastest of the 23 models we have run on this harness, behind Mistral Medium 3.5 at 2.9 s.

The counterintuitive part: Opus 5 and Opus 4.8 list at the same $5 / $25 per 1M, yet Opus 5 measured 39% more per 1,000 tasks. $5.64 against $4.05, for an identical 9/9 on identical tasks. Nothing on the rate card explains that, because the rate card is the same. The difference is token count — Opus 5 returned more tokens on the same nine problems. The two rows were priced on different dates, 2026-07-30 for Opus 5 and 2026-07-17 for Opus 4.8, but at the same $5 / $25 rate on both, so the gap is tokens and not a price change.

How the numbers were produced: nine executed Python tasks (two_sum, valid_parentheses, merge_intervals, roman_to_int, lcs_len, flatten, top_k_words, token_bucket, parse_csv_line). The model gets a signature and a prose spec and never sees the assertions; returned code runs in an isolated python3 -I subprocess with a 12-second timeout. Temperature 0, max_tokens 4000, one scored attempt per task, retried only on an API error. Calls go through OpenRouter's OpenAI-compatible endpoint, deliberately not the DataLLM Lab gateway. Cost is derived — measured token counts multiplied by list price on the stated date, never a vendor invoice; 49 of roughly 396 catalogue models changed price in the twelve days to 2026-07-29, so an undated cost figure is not a fact. Our original sweep was 13 models run in one sitting; Opus 5 and Opus 5 Fast are among the later runs on the same harness under the same settings, bringing the total to 23, of which 20 scored 9/9. The core sweep was and remains 13.

For the same 9/9-for-less pattern one tier down, see our Claude Haiku 4.5 review: $0.94 per 1,000 tasks priced 2026-07-29, the same score Opus 4.8 and Opus 5 got. And for why a large window is not the same thing as usable attention across it — the question our harness explicitly cannot answer — see context rot.

The current 1M-window models

Opus 5, Opus 4.8, Sonnet 5, and Fable 5 each carry a 1M-token context window — and it is the default, not an opt-in. The same 1M window also covers the still-available Opus 4.7, Opus 4.6, and Sonnet 4.6: per Anthropic's docs, 1M starts with the Claude 4.6 generation, not with Opus 5. It is available on the Claude API, Amazon Bedrock, Google Cloud, and Microsoft Foundry, and no beta header is required to use it — long-context requests bill at standard rates, so a 900k-token request costs the same per token as a 9k-token one. That matters because earlier 1M-context rollouts were gated behind a beta flag; on the current generation you get the full window on a plain request. Each of these caps a single synchronous request's output at 128k tokens. If you are picking a default model for long-context work, our best LLM API roundup covers where each fits.

Context window vs max_tokens — the distinction that trips people

The context window is the whole working memory; max_tokens caps only the output of one request. These are constantly confused, so pin them down:

• Context window is all the text the model can reference when generating a response — including the response itself. It holds the full conversation history plus the new output the model generates. Everything in the request counts: system prompt, all messages (tool results, images, documents), and tool definitions — plus all generated output, including extended thinking.
• max_tokens is the output-generation limit for a single request. It is a subset of, and distinct from, the total context window. A 1M-window model like Opus 5 still caps one request's generated output at 128K via max_tokens, while the full 1M covers input plus output combined.

So the mental model is: context window ≥ input + output, and separately output ≤ max_tokens ≤ 128k. You can have a 1M window and still only ever emit 128k tokens in one shot.

Claude 3.7 and the older 200k line

The older Claude 3.x-generation and other legacy models have a 200k-token context window. If you are searching for the “Claude 3.7 context window,” the answer is 200k — the figure that has held across the older Claude line. Anthropic's current docs no longer list named Claude 3.x models in a legacy table, so we corroborate the 200k figure via the still-listed 200k legacy entries: Claude Sonnet 4.5, Claude Opus 4.5, and Claude Opus 4.1 (Opus 4.1 is deprecated and scheduled for retirement on 2026-08-05). The dividing line is not “current versus legacy” but generation: 1M starts at Claude 4.6 and applies to everything after it, while Sonnet 4.5, Opus 4.5, Opus 4.1, Haiku 4.5 and the whole older line stay at 200k. If you are on an older model for cost reasons, compare against the current line in our cheapest LLM API guide.

How big is 1M tokens, really

Roughly 555,000 English words, or about 2.5M characters — not the 750,000 words the old “a token is three-quarters of a word” rule of thumb predicts. That is Anthropic's own figure for the current 1M-window models, and the gap is a tokenizer change: Claude 4.7 and later (Opus 5, Opus 4.8, Sonnet 5, Fable 5) use a newer tokenizer that produces roughly 30% more tokens for the same text, so the same 1M budget holds proportionally less English. On Opus 4.6 and Sonnet 4.6, which use the previous tokenizer, 1M tokens is the familiar ~750,000 words. Call it a 1,800-page book on the current line rather than 3,000, or several large codebases held in memory at once. But the practical number is smaller than the headline, because the window is shared: input and output live in the same 1M budget, and everything counts toward it — system prompt, every message, tool definitions, images, documents, and all generated output including extended thinking. A concrete budget for a 1M-window model:

Illustrative budget, not an Anthropic figure — the ~555k-words-per-1M figure comes from Anthropic's model comparison table and the ~30% tokenizer note from its pricing docs; the “everything counts” rule is from the Context windows docs; the token counts here are rounded estimates to show how the shared budget divides. The lesson: reserve output room, or generation can stop early (next section).

What happens when you exceed the context window

On Claude 4.5 models and newer, the behaviour depends on whether it is your input or your input-plus-output that overflows. The three cases:

The practical takeaway: setting a large max_tokens on a near-full window will not error up front — but generation can halt mid-answer once the total reaches the window. Reserve output room, or catch the model_context_window_exceeded stop reason and continue. The full 400-error catalogue and its fixes are in our LLM API error codes reference.

How to actually use a 1M window (cost and caching)

A 1M window is a cost lever before it is a capability — long input is billed input, and caching is how you keep it affordable. Practical moves when you fill a large window:

• Cache the stable prefix. System prompts, tool definitions, and large context documents rarely change between turns — cache them so repeated turns re-read instead of re-paying. Cached reads are billed at a fraction of the input price; the arithmetic is in our cost guide.
• Reserve output headroom. Because input and output share the window, set max_tokens deliberately and leave room, or you risk the model_context_window_exceeded stop above.
• Do not fill it just because you can. A 1M prompt costs 5× a 200k prompt in input tokens. Retrieve the relevant slice rather than dumping everything; the window is a ceiling, not a target.
• Batch large output jobs. If you need more than 128k of output, the Message Batches API raises the cap to 300k via the output-300k-2026-03-24 beta header — Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5 and Sonnet 4.6 are on that list, and batch requests also run at half price. Fast mode is the exception: it does not work with the Batch API.

If you are building agents that stream long tool loops into the window, our agent-model guide covers how context budget interacts with tool-call depth.

Query a model's limits from the API

Do not hard-code token limits — read them at runtime. Model capabilities and token limits can be queried via the Models API, whose response includes max_input_tokens, max_tokens, and a capabilities object for each model. That is the durable way to handle limits when you route across models or migrate to a newer version. Through the gateway it is one OpenAI-compatible call:

from openai import OpenAI

client = OpenAI(
    base_url="https://www.datallmlab.com/v1",
    api_key="YOUR_DATALLMLAB_KEY",
)

# List models and their metadata, then pick by context budget
for m in client.models.list().data:
    if m.id.startswith("anthropic/claude-"):
        print(m.id)   # route long-context jobs to the 1M-window models

resp = client.chat.completions.create(
    model="anthropic/claude-opus-5",     # 1M context, 128K max output, no beta header
    max_tokens=128000,                       # output cap — a subset of the window
    messages=[{"role": "user", "content": "..."}],
)

The Models API on Anthropic returns max_input_tokens and max_tokens per model (docs); the gateway exposes the equivalent list through the standard OpenAI-compatible /models endpoint.

FAQ