Capacity Is a Measurement, Not a Million-Token Claim

The "1M tokens" line on a model card is an upper bound on what the API will accept, not a guarantee of what the model will use well. In August 2026, ofox.ai sent one identical 420-word English document to nine flagship models and measured a 1.56x spread in token count — 614 tokens on Grok 4.20, 957 on Claude Opus 5 — for the exact same text. The advertised window is a spec-sheet assertion; the real capacity is a measurement, and per Theorem 3, a property is guaranteed exactly when its mechanism is implemented and measuring. The mechanism here is the tokenizer plus the retrieval-accuracy curve, and neither appears in the headline number.

What a context window actually is

A context window is the token budget for a single API request. Everything the model reads and everything it writes has to fit inside one number, and the API is stateless — it does not remember the last call. On every turn your application resends the entire conversation, and the window is the ceiling on how big that resend plus the coming reply may be.

That is why the window is not memory in any useful sense. A chat product that appears to remember your name across sessions is storing that text somewhere and pasting it back into the window on each request. The persistence lives in your application, not in the model.

What counts toward the window

Everything in the request, plus everything in the response. The parts people forget are usually the expensive ones:

• System prompt. Counted on every turn, not once per session.
• Full message history. Every prior user and assistant turn you resend.
• Tool definitions. Names, descriptions, and JSON schemas for every tool you declare. On Claude these also add a per-model tool-use system prompt, from 286 tokens on Opus 5 to 675 on Opus 4.7.
• Tool results. Often the biggest single item in an agent loop; a directory listing or an API response can run to thousands of tokens.
• Reasoning tokens. On models with thinking enabled, the reasoning counts and is billed even when the text is not returned to you.
• The reply itself. This is why max_tokens and the context window interact: a request that leaves no room for output truncates.

"1M tokens" is nine different numbers

[UNIQUE INSIGHT] The advertised window is an upper bound on what the API will accept, not on what the model will use well — and the gap between those two is a benchmark question, not a spec-sheet one. The mechanism that determines real capacity is the tokenizer plus the retrieval-accuracy curve, and neither appears in the headline number.

Across the nine flagship models ofox.ai cataloged on 2026-08-12, "1M" resolves to nine distinct integers: from an even 1,000,000 (Claude Opus 5, Grok 4.20, DeepSeek V4 Flash) up to 1,131,072 (Qwen 3.8 Max). That is a 13% spread before you have measured anything. Across the full 119-text-model catalog, the most common window is 256K (25 models), with 22 at 1M.

One caution about where these figures come from. Gateway catalogs and vendor documentation do not always agree: on 2026-08-12 the ofox catalog listed Grok 4.20 at 2,000,000 while xAI's own model docs state 1,000,000. The honest comparison uses the vendor number, and you check the vendor page when the figure matters. A spec sheet is a claim; the vendor doc is a stronger claim; the measured prompt_tokens on your content is the only one that answers your question.

The 1.56x spread on identical input

The deeper surprise is that the tokenizer — not the window number — is the load-bearing mechanism. ofox sent one identical 2,638-character English document (a 420-word service postmortem) to nine models through one endpoint and read prompt_tokens off each response:

• Grok 4.20: 614 tokens (4.30 chars/token)
• GPT-5.6 Sol: 626 (4.21)
• GLM-5.2: 632 (4.17)
• DeepSeek V4 Flash: 634 (4.16)
• Gemini 3.1 Pro: 684 (3.86)
• Claude Opus 4.6: 698 (3.78)
• Qwen 3.8 Max: 706 (3.74)
• Kimi K3: 716 (3.68)
• Claude Opus 5: 957 (2.76)

A 1.56x spread on identical input. Claude Opus 5 is the outlier because Anthropic documents that Claude 4.7 and later use a newer tokenizer producing roughly 30% more tokens for the same text.

Combine the two tables and the advertised window stops being the useful number. Copies of that same 420-word document that actually fit range from 1,045 on Claude Opus 5 to 1,677 on GPT-5.6 Sol — a 1.60x gap on models that all advertise "roughly 1M."

The ratio is not constant across content types. On a TypeScript file the spread was 1.53x and GLM-5.2 was leanest rather than Grok. On Chinese prose the spread widened to 1.88x, and both Claude models landed close to one token per Chinese character against 1.87 for Grok. Treat those as samples, not rules: on a second, punctuation-heavier Chinese passage the same two models came in at 0.98 and 0.96 chars/token, meaning some characters cost more than one token. If your input is code or non-English, measure it rather than assuming.

Why per-token prices are not comparable across vendors

Because a token is not a fixed amount of text, per-token prices are not directly comparable. A vendor charging less per token can cost more per word if its tokenizer is denser. Anthropic bills the full 1M window at standard rates with no long-context premium, so a 900K-token request costs the same per token as a 9K one. Gemini 3.1 Pro goes from $2 to $4 per million input tokens past 200K, and Grok 4.20 from $1.25 to $2.50 at the same threshold. The model with the cheaper headline rate can be the more expensive one for long-document work, and the tokenizer difference sits on top of whichever tier you land in.

A budget comparison that reads the sticker price and the advertised window is reading two claims. A budget comparison that measures prompt_tokens on the real document and multiplies by the applicable tier rate is reading one measurement. The first is a guess; the second is a number you can invoice against.

The window is not the usable context

The most important caveat is that a model accepting 1M tokens is not the same as a model reliably finding the fact you buried at token 800,000. Retrieval accuracy degrades with distance for every public model, and the size of that gap is a benchmark question rather than a spec-sheet one. ofox points to RULER, MRCR v2, and NoLiMa as the benchmarks that actually measure it: RULER probes retrieval at controlled depths in synthetic contexts, MRCR v2 tracks multi-hop retrieval in long documents, and NoLiMa tests whether a model still finds an answer when the lexical overlap between question and evidence is removed. None of those scores appears on a model card next to "1M context."

Treat the advertised window as an upper bound on what the API will accept, and the benchmark numbers as the guide to what the model will use well. The first number is a contract; the second is a measurement. A model that accepts a million tokens but retrieves at 60% accuracy at depth 500K has a usable context far below its advertised one, and no amount of window will fix the gap — only a different mechanism (routing, retrieval, or restructuring) will.

The mechanism is the measurement, not the spec

[ORIGINAL DATA] At Everythink we treat the context window the way we treat any claimed property: per Theorem 3, a property is guaranteed exactly when its mechanism is implemented and measuring. The "1M tokens" line has no mechanism behind it; prompt_tokens on your own content is the mechanism. We measure before we commit to a provider, and we re-measure when a vendor ships a new tokenizer, because the headline number has been off by up to 1.6x in either direction.

This is the discipline of re-measurement. A tokenizer is not a stable property of physics; it is a software artifact a vendor can replace with a newer one that produces 30% more tokens for the same text, as Anthropic did with Claude 4.7. When that happens, every capacity estimate you cached from the old tokenizer is wrong by the same 30%, and so is every cost estimate built on it. The teams that get bitten are the ones who measured once, wrote the number into a config file, and never came back. The teams that stay honest re-measure on a schedule, the way you would re-calibrate any instrument.

This is not a new discipline for us. The HAI Engine has been in production since 2016, and every forecast fans out to multiple Sisters — each one a typed AI agent with its own personality and its own context-budget decision — before the Oracle merges their drafts into a calibrated ensemble. A forecast is not one giant prompt; it is a routed set of bounded prompts, and the bound is a measurement, not a model-card line.

[PERSONAL EXPERIENCE] We have been measuring agent context budgets for a decade, and the single most reliable mistake we see is teams choosing a model on advertised window size and then discovering, in production, that their real workload fits 35% fewer documents than the spec implied. The fix is never a bigger window. The fix is measuring your own content on the models you are choosing between — one request with max_tokens: 1 returns prompt_tokens and costs a fraction of a cent — and routing accordingly.

Routing precedes retrieval

This is the same principle as "the space is the router": in Everythink, the network→community→room topology routes a query before anything responds. You do not pour the whole world into one window and hope the model finds the right fact at token 800,000; you route to the room that holds the relevant context, so the window the model actually sees is small, fresh, and measured. Capacity is a routing problem before it is a retrieval problem, and retrieval is a measurement problem before it is a spec problem.

The 21 papers codify this. Theorem 3 does not say "bigger is better"; it says a property holds exactly when the mechanism that guarantees it is in place and measuring. For capacity, that mechanism is a tokenizer reading your content and a benchmark reading the model's retrieval at depth. The advertised number is neither.

Customer sovereignty runs on measurement

Customer sovereignty — your network, your brand, your data — has a quiet dependency on capacity measurement. When you own the network→community→room topology, you decide what context reaches which agent, and that decision is only as good as your estimate of what fits. A sovereign operator who trusts the spec sheet hands the real decision to the vendor's marketing copy. A sovereign operator who measures their own corpus keeps the routing decision in-house, where it belongs. The same applies to inclusion by design: a low-connectivity user on a metered data plan is best served by a small, well-routed window, not a million-token firehose, and "small and well-routed" is a measurement you can only make if you have measured.

Fitting more into the window you have

None of these makes the window bigger; they all reduce what you spend inside it. In rough order of payoff:

1. Prompt caching. A stable prefix — system prompt, tool definitions, a document you keep asking about — is billed at roughly 10% of the input rate on a cache hit on Anthropic and several other vendors, though the exact discount varies and runs deeper at some. This is the single largest lever for repeated calls, and it changes cost, not capacity.
2. Compaction. Server-side summarization of earlier turns once the conversation approaches the limit, so a long agent session keeps running instead of erroring.
3. Context editing. Clearing stale tool results and old reasoning blocks out of the transcript. Agent loops fill up on tool output more than on conversation.
4. Pick the right tokenizer for your content. As the measurements above show, that decision alone is worth up to 1.6x of effective capacity before you optimize anything else.

The first three manage the budget. The fourth picks which budget you are measuring against. All four are mechanisms; none is a bigger number on a card.

What happens when you exceed the window

You get an HTTP 400 and no output. Nothing is silently truncated. ofox sent an over-sized request to a 32,000-token model and received:

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

Read that limit carefully: the model advertises 32,000, and the enforced input ceiling is 30,720, with the remainder reserved for output. The advertised window is the total, not your input allowance, and the enforced number can be lower than the marketing one.

Error shapes differ by vendor, so do not pattern-match on the message string. OpenAI-compatible endpoints generally return a 400 with a context_length_exceeded-style code. Claude can instead finish the turn with stop_reason: "model_context_window_exceeded", which is distinct from max_tokens and needs its own branch in your code. Handle both. A response that stopped early because the window filled is not the same failure as one that stopped because your max_tokens was small, and the fixes differ.

Key takeaways

• The advertised window is an upper bound on what the API accepts, not on what the model uses well. Real capacity is a measurement, and the measurement is the tokenizer plus the retrieval-accuracy curve.
• "1M tokens" is nine different numbers, and the same 420-word document fits 1.6x more copies on one flagship model than another. Per-token prices are not comparable across vendors without adjusting for tokenizer density.
• Measure your own content. One request with max_tokens: 1 returns prompt_tokens and costs a fraction of a cent. Run it on your real workload before choosing a model on window size, and re-run it when a vendor ships a new tokenizer.
• The mechanism is the measurement, not the spec. Per Theorem 3, a property is guaranteed exactly when its mechanism is implemented and measuring. The "1M" line has no mechanism; prompt_tokens is the mechanism.
• Routing precedes retrieval. Do not pour the world into one window. Route to the relevant context first — the network→community→room topology in Everythink is the same principle at the product level — so the window the model sees is small, fresh, and measured.

Frequently asked questions

Is a context window the same as memory? No. A context window is per request, not persistent. The API is stateless: every turn you resend the whole conversation, and the window is the ceiling on what one request may contain. Anything outside it is gone unless your application stores it and sends it again. Products that appear to remember you across sessions are re-injecting saved text into the window, not drawing on model memory.

How many words is 1 million tokens? For English prose, roughly 440,000 to 685,000 words — a wider range than the usual rule of thumb admits. Working from ofox's measurement on one identical document, eight of nine models land between 587,000 and 684,000 words per million tokens; Claude Opus 5 is the low outlier at about 439,000 because of its newer tokenizer. Code runs denser (about 2.4 to 3.6 chars/token) and Chinese denser still (0.9 to 1.9), so the same 1M window holds far less of those.

What is the largest context window available in 2026? 1M tokens is the top of the mainstream tier. Several vendors sit slightly above the round number: Qwen 3.8 Max at 1,131,072, GPT-5.6 at 1,050,000, and Gemini, GLM, and Kimi K3 at 1,048,576. Across the 119 text models in the ofox catalog on 2026-08-12, the most common window is 256K (25 models), with 22 at 1M.

Why does the same file use more tokens on Claude than on GPT? Different tokenizers. Anthropic notes that Claude 4.7 and later use a newer tokenizer that produces roughly 30% more tokens for the same text than earlier Claude models. On ofox's English test document Claude Opus 5 used 957 tokens where GPT-5.6 Sol used 626, a 1.53x difference on identical input. Nothing is wrong; the models count differently, and per-token prices are not comparable across vendors without adjusting for it.

Can I increase a model's context window? No. It is fixed by the model and there is no parameter to raise it. What you can change is how much of it you spend: prompt caching cuts the cost of resending a stable prefix, context editing clears stale tool results, and compaction summarizes older turns. Those manage the budget rather than expanding it.

If you want to stop guessing at capacity and start measuring it, create your network — the topology that routes before anything responds, so the window your agents actually see is the one you have measured.

Sources

• 2026 — ofox.ai, "What Is a Context Window? Token Limits by Model (2026)" — https://ofox.ai/blog/what-is-a-context-window-token-limits-by-model-2026/
• 2026 — Anthropic, "Context windows" — https://platform.claude.com/docs/en/build-with-claude/context-windows
• 2026 — Anthropic, "Pricing, including the tokenizer note" — https://platform.claude.com/docs/en/about-claude/pricing