Context windows, and what fits in one
The context window is the total number of tokens a model can hold in one request — your system prompt, the conversation so far, anything you retrieved and injected, and the answer it is about to write. It is not an input budget. Output comes out of the same allowance, which is the detail that catches people out.
Exceed it and the request does not degrade gracefully. It is rejected, or the earliest part of the conversation is silently dropped, depending on whose API you are calling.
What each model holds#
| Model | Context window |
|---|---|
| GPT-3.5 Turbo | 16,385 |
| GPT-4o | 128,000 |
| GPT-4o mini | 128,000 |
| GPT-4 Turbo | 128,000 |
| Claude Haiku 4.5 | 200,000 |
| Claude Sonnet 5 | 1,000,000 |
| Claude Opus 5 | 1,000,000 |
| GPT-4.1 | 1,047,576 |
That is a factor of about 64 between the smallest and largest.
In something other than tokens#
Tokens are hard to picture, so as a rough conversion for ordinary English prose — around 750 words per thousand tokens:
- 16,385 tokens ≈ 12,000 words. A long article, or a short chapter. Comfortable for single-turn questions, tight for a document.
- 128,000 tokens ≈ 96,000 words. A full-length novel, or a mid-sized codebase's worth of relevant files.
- 200,000 tokens ≈ 150,000 words. Several books.
- 1,000,000 tokens ≈ 750,000 words. An entire technical library.
Treat these as order-of-magnitude guides, not measurements. Code, JSON, and non-English text all tokenize substantially worse than prose, so a 128,000-token window holds far less source code than the word count suggests. If the number matters, measure it — paste the real text into the calculator rather than converting from a word count.
Why the ceiling is not the target#
A large window makes things possible; it does not make them advisable.
You pay for every token you send, every time. A 500,000-token context on Claude Sonnet 5 at $3 per million costs $1.50 in input alone — per request. Fill a million-token window on every call and the arithmetic stops working quickly.
Long contexts are slower. Time to first token grows with input length. A request carrying half a million tokens of context feels different to a user than one carrying five thousand.
Retrieval usually beats stuffing. Finding the twenty relevant paragraphs and sending those tends to produce better answers than sending two thousand paragraphs and hoping. It is also cheaper by two orders of magnitude. The large window is most valuable as headroom for the cases retrieval handles badly — a single document that genuinely must be read whole — rather than as a default strategy.
Where the window actually binds#
Three situations where the ceiling stops being theoretical:
- Long conversations. Each turn resends everything before it. A chat that runs for fifty exchanges accumulates its entire history as input, and a 16,385-token window is reached faster than most people expect.
- Whole-document work. Contract review, log analysis, or summarising a research paper means the input is large by definition and cannot be trimmed without changing the task.
- Reserving room for the answer. If you send 15,000 tokens to a 16,385-token model, there is no space left to reply. Always subtract your expected output length from the window before deciding what fits.
That last one is the most common mistake. The window is shared, and the response needs its share.
Choosing on window size#
Window is a filter, not a ranking. Establish the largest context your workload realistically produces — including the answer — then eliminate models that cannot hold it. Choose among the survivors on capability and price.
Working the other way round is how projects end up paying frontier rates for headroom they never use. If your longest realistic request is 12,000 tokens, every model in the table above clears it, and the window has told you nothing useful about which to pick.