Context window in practice: what actually fits in 200k vs. 1M tokens

By LW Forge — maintainer of LLM Scout · Updated August 3, 2026

A context window of 128,000 tokens felt generous a couple of years ago; today it's the small end of the range. Claude's flagship lineup tops out at 200k, while GPT-5.6, Gemini 2.5, GLM-5.2, Kimi K3 and Nemotron 3 Ultra all ship with roughly a million tokens of context. The headline numbers are easy to find — what they actually mean for your documents, your bill and your answer quality is less obvious.

What 200k and 1M tokens actually hold

Using the same conversion this site's context window calculator runs on, a million tokens is roughly 770,000 words at typical English density — somewhere around 8-9 average novels, or about 2,000 dense text pages. A 200k window holds about a fifth of that: roughly 150,000 words, 1-2 novels, or around 400 pages. For most business documents — contracts, reports, codebases of moderate size — 200k is already generous; a million tokens is built for whole-repository or multi-document workloads, not a single report.

Check how many pages fit in GPT for the page-count version of this same math broken out by model.

Bigger windows cost real money to fill

A context window is capacity, not free storage — every token inside it, whether it's your prompt or ten reused documents, is billed as input on every single request that includes it. Maxing out a million-token request at a flagship rate runs a few dollars in input cost alone, on that one request; do that ten thousand times a month and the number stops being trivial. One provider-specific wrinkle worth knowing: Gemini 2.5 Pro's per-token rate roughly doubles for the portion of a prompt past 200k tokens, so a request that's "almost small" and one that's "genuinely huge" aren't priced on the same curve even on the same model.

The practical rule: treat the window as a ceiling you're allowed to approach, not a target to fill by default. An application that lets conversation history or retrieved context grow unchecked will hit the token budget — or the bill — long before it hits the model's actual limit.

Lost in the middle: why stuffing the window backfires

Long-context evaluations keep finding the same shape: models recall information near the start and end of a prompt more reliably than material buried in the middle, even well inside their stated limit. Dumping an entire knowledge base into context because the window technically allows it doesn't just cost more — the answer can get worse, because the fact that matters is competing with thousands of tokens of noise for the model's attention.

Two habits follow from this. Put instructions and the most decision-critical facts near the start or the very end of the prompt, not buried in page 40 of 60. And when your source material is large, retrieval — indexing the material and sending only the passages relevant to the current question — tends to beat window-stuffing on both cost and quality, because the model is reasoning over dozens of relevant tokens instead of thousands of irrelevant ones.

When a bigger window is genuinely worth it

The million-token tier earns its cost in a few specific cases: reasoning across an entire codebase in one pass instead of file-by-file, holding a full document collection (not just one report) in context for cross-referencing, or long multi-turn agent sessions where trimming history isn't an option. Short-turn chat, classification, and single-document Q&A rarely need more than a fraction of even a 200k window — check your actual usage with the token calculator before assuming you need the biggest window on the menu.

Where the breakeven with retrieval sits

There's no fixed page count where retrieval definitively wins over stuffing the full document into context — it depends on how often you query the same material. A document you'll ask one or two questions about is usually cheaper to just paste in fully, even at a few hundred thousand tokens; a knowledge base you'll query hundreds of times a day is almost always cheaper to index once and retrieve from repeatedly, since context-stuffing rebills the entire source on every single question. If you're re-sending the same large block of text across many requests, prompt caching is the other lever worth checking before you invest in a retrieval pipeline.

Measure before you architect around it

Context window specs are easy to compare on a spec sheet and easy to get wrong in practice, because the number that matters is your actual document's token count, not its page count or file size. Run a real sample through the token calculator, check exactly how many pages a given model's window holds in how many pages fit in GPT, and price out the request in the OpenAI or Claude calculator before committing to an architecture built around a specific window size.