Context Window Wars: GPT-5 vs Claude vs Kimi — 1M vs 400K vs 256K

Explain it like I’m five

Imagine you are doing homework at a desk. You can only work with the books that are actually on the desk — anything still on the shelf might as well not exist.

A context window is the size of that desk. A bigger desk holds more books open at once: the textbook, your notes, last week’s worksheet. But a bigger desk has a catch: the more books you pile on it, the harder it is to find the one line you actually need. That is the whole war in one sentence — bigger windows hold more, but they do not automatically remember better.

Intuition

A context window is everything a model can look at while producing one response: the system prompt, every message so far, any documents or tool results you attached, and the output it is generating. Everything counts, including the output itself.

Windows are measured in tokens. A token is a chunk of text — roughly three quarters of an English word, so a thousand tokens is about 750 words. When a model “reads a million tokens,” it is holding roughly 750,000 words, or about 1,500 book pages, in working memory at once.

Two things follow that interviewers love to probe. First, the window is shared: input and output draw from the same budget, so a model that reserves a big output allowance has less room left for your input. Second, the window is not a hard drive: content inside it is not remembered equally. What sits at the start and the end gets used best; what sits in the middle gets lost.

The scoreboard

Three models, three very different answers to “how much can you see at once?” All figures below were checked against each provider’s own documentation at the time of writing.

Model	Context window	Max output	The one-line story
Claude Opus 4.6 / Sonnet 4.6 (Anthropic)	1,000,000 tokens	128,000 tokens	The size crown — 2.5× GPT-5, ~4× Kimi.
GPT-5 (OpenAI)	400,000 tokens	128,000 tokens	The balance pick — with a gotcha (below).
Kimi K2.7-Code (Moonshot AI)	256,000 tokens (262,144)	32,768 tokens (default)	The underdog — smallest window, open weights.

The GPT-5 gotcha. GPT-5’s 400,000-token window includes its up-to-128,000-token output allowance. So the room left for your actual input is closer to 272,000 tokens (400,000 − 128,000). If you walk into an interview quoting “400K” without that subtraction, you have told the interviewer you have never actually filled the window.

The Claude footnote. On Claude’s current lineup, the 1M window is the default for Opus 4.6, Sonnet 4.6, and later models — no beta header, no long-context surcharge. Older models such as Sonnet 4.5 sit at 200K.

The Kimi footnote. Kimi’s K2 family has held a 256K window since the K2-Instruct-0905 update doubled it from 128K. Its edge is not size: the weights are open, so you can self-host, fine-tune, and run it without paying frontier prices.

Lost in the Middle

Here is the finding that makes this an interview topic instead of a spec-sheet comparison. In “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023), researchers moved the answer-bearing passage around inside long prompts and measured recall. Performance was best when the key fact sat at the very beginning or the very end of the prompt, and worst when it sat in the middle — a U-shaped curve that held across models and tasks.

Anthropic’s own documentation names the wider version of the same decay “context rot”: as token count grows, accuracy and recall degrade. A million-token window you cannot trust is just a bigger haystack.

Interview move

When an interviewer asks “would a bigger window fix it?”, the senior answer is: only if you also fix placement. Put critical instructions first, key evidence last, and never bury the one fact the answer depends on in the middle.

Prefill cost

Every token you stuff into the prompt has to be processed before the model writes a single word — that first pass is called prefill. It builds the key-value cache the model reuses while generating, and you pay for it in both latency and money, whether or not the model ends up using those tokens.

Do the arithmetic on GPT-5’s published pricing: at $1.25 per million input tokens, a single request that fills the ~272,000-token input room costs about $0.34 in prefill alone (272,000 ÷ 1,000,000 × $1.25). Send a million such requests and you have spent $340,000 before the model has answered anything. Long context is a budget line, not a free feature.

That is why production systems cache shared prefixes (a system prompt or a codebase snapshot processed once, reused across requests) and why “just put everything in the prompt” is a design smell at scale.

Retrieval vs stuffing

The alternative to a bigger window is retrieval: instead of handing the model ten documents, a retriever picks the three that matter and the model reads only those. Retrieval usually wins on all three axes that matter — cost (fewer tokens prefilled), accuracy (less haystack, less middle to get lost in), and freshness (the retriever can fetch today’s data; the window cannot).

Stuffing wins in exactly one shape: when the whole corpus genuinely fits with room to spare — a single contract, a short codebase, one long conversation — and even then, placement discipline from the Lost-in-the-Middle section still applies. The interview-ready line: retrieval beats raw size, and the window is where retrieved context goes, not a replacement for retrieval.

Real-world use

Codebase agent

A coding agent working across a 500-page repository. A 1M-token window can hold the whole repo at once; a 256K window cannot — so the Kimi setup pairs the model with a retriever that fetches the relevant files per task, and usually ships fewer wasted tokens doing it.

Contract review

A lawyer asks a model to find the termination clause in a 400-page contract. The clause’s position matters more than the window: buried in the middle, it is the worst case for recall. The fix is structural — split the contract, query per section, and cite the section, not the haystack.

Support agent

A customer-support bot carries a months-long conversation history. Nobody re-reads the whole history per reply: the system compacts old turns into a summary and retrieves only the recent turns that matter. The window holds the summary, not the archive.

Research synthesis

An analyst synthesizes fifty papers into one briefing. Stuffing all fifty into one prompt invites context rot; the working pattern is per-paper extraction (small, trusted contexts) followed by a synthesis pass over the extractions.

The pattern across all four: the window is the last step of the pipeline, not the first. Retrieve, rank, then read.

Worked example

Convert each window to words and pages, using the rough rule of one token ≈ 0.75 words and one page ≈ 500 words:

Claude (1M tokens): ~750,000 words ≈ 1,500 pages. A small library shelf.
GPT-5 (400K tokens): ~300,000 words ≈ 600 pages. A fat textbook.
GPT-5 usable input (~272K): ~204,000 words ≈ 408 pages, once the output allowance is subtracted.
Kimi K2.7-Code (256K tokens): ~192,000 words ≈ 384 pages. A thick novel.

Now the interview twist: ask which one you would pick for a 500-page codebase. The naive answer is “the biggest window.” The senior answer is “the 1M window holds it, but I would still retrieve — because a 500-page haystack is exactly where recall goes U-shaped, and I would rather pay prefill on the 30 pages that matter.”

Interview prompts

“What is a context window?”

Everything the model can look at while producing one response — system prompt, conversation, documents, tool results, plus the output itself. Measured in tokens, shared between input and output.

“Why doesn’t a bigger window always help?”

Two reasons: recall is U-shaped (Lost in the Middle, 2023) — facts buried mid-prompt get used worst — and quality decays as the window fills (Anthropic calls it context rot). Plus prefill cost: every token is processed and billed.

“GPT-5 advertises 400K. How much can you actually send?”

About 272K tokens of input, because the 400K window includes up to 128K tokens of output. This is the single most quotable number in the guide.

“When would you choose retrieval over a bigger window?”

Whenever the corpus exceeds the few documents that actually matter, whenever the data changes, and whenever you are paying prefill per request. Retrieval wins on cost, accuracy, and freshness.

“What do you do when input exceeds the window?”

Rank and truncate by relevance, compact older conversation into a summary, cache the shared prefix, and split the work (map over chunks, then reduce). Never silently drop the middle — that is where the answer lives.

Takeaways

Quote the three numbers. Claude Opus/Sonnet 4.6: 1M. GPT-5: 400K (272K usable input). Kimi K2.7-Code: 256K.
Subtract the output. A window includes what the model generates. The input budget is the window minus the output allowance.
Placement beats size. Recall is U-shaped — critical facts go first or last, never buried in the middle.
Prefill is a budget line. Every token costs latency and money, used or not. Cache shared prefixes.
Retrieval beats raw size. The window is where retrieved context goes, not a replacement for retrieval.
Curate, don’t stuff. The winner is whoever puts the right tokens in the window, not whoever has the biggest one.

Sources

All explanations above are original; figures are attributed to the linked provider documentation and paper.