GPT-4.1's Context Window and Why It Differs From GPT-4o's

GPT-4.1 takes roughly eight times the context GPT-4o does. Both figures come from the same place — OpenAI’s model reference pages — and both are stated in tokens, which is the only unit that matters and the one every rule of thumb about pages and words gets wrong.

The documented figures

On OpenAI’s model page for GPT-4.1, the model — released in April 2025 — is documented with a context window of 1,047,576 tokens and a maximum output of 32,768 tokens. On the model page for GPT-4o, from the same reference and in the same table format, the context window is 128,000 tokens and the maximum output is 16,384 tokens.

                    context window     max output tokens
GPT-4.1               1,047,576              32,768
GPT-4o                  128,000              16,384

ratio                      8.2×                  2×

The odd-looking first figure is worth a sentence, because it is frequently rounded in a way that hides what it is. 2²⁰ is 1,048,576, and 1,047,576 is exactly one thousand less than that. The advertised “one million tokens” is a description of the scale, not the number — you have 1,047,576 tokens, and if you are sizing a chunking strategy to the last token, size it to the documented figure rather than to 1,000,000 or to 2²⁰.

The output cap is a separate, much smaller number

The context window is the budget for input and output together: prompt tokens plus completion tokens must fit inside it. But the completion side has its own, far lower ceiling — 32,768 for GPT-4.1 — and that ceiling is what actually limits how long an answer can be.

So the arithmetic for any single request is:

max answer length  =  min( model output cap,
                          context window − prompt tokens )

GPT-4.1, 900,000-token prompt:
  min( 32,768, 1,047,576 − 900,000 )  =  min(32,768, 147,576)  =  32,768

GPT-4.1, 1,030,000-token prompt:
  min( 32,768, 1,047,576 − 1,030,000 ) =  min(32,768, 17,576)  =  17,576

The second line is the case that catches people. Fill the window nearly to the top and the space left for the answer shrinks below the output cap, so a request that succeeded yesterday with a slightly smaller document returns finish_reason: length today. A million-token window does not buy a million-token answer, and nothing in the request tells you which of the two ceilings you hit — you have to compute it.

The second figure is also the one that decides whether a job is possible in one call at all. Translating a document, rewriting a codebase file, or producing a long structured export are all bounded by the output cap and not by the context window, and no request parameter raises it. A task that needs 80,000 tokens of output is a chunked job on GPT-4.1 regardless of the fact that the input would fit twelve times over. The asymmetry between the two figures — 32 to 1 on GPT-4.1, 8 to 1 on GPT-4o — is a statement about what these models are for: reading a great deal and writing a moderate amount.

Why the two models differ

The honest answer is that GPT-4.1 is a later model trained and served for long context, and GPT-4o is not — they are different models rather than the same model with a configuration flag. But the reasons long context is a model-level property, rather than something a provider can raise at will, are worth understanding because they predict the shape of the next such difference.

• Attention cost is quadratic in sequence length. Every token attends to every earlier token, so eight times the context is roughly sixty-four times the attention work at full length. Serving that at an acceptable price requires architectural and systems work — attention variants, careful key-value cache management, memory-efficient kernels — not a raised limit.
• Positional generalisation has to be trained in. A model must be trained or adapted on long sequences to use distant positions competently. A model whose training rarely exceeded a certain length does not simply keep working past it; it degrades. The published window is the length the vendor is prepared to stand behind, not the length at which the code stops running.
• Memory for the key-value cache scales with the window. Every token in context contributes keys and values that must be held for the duration of the request. That is a serving cost per concurrent long-context request, and it is why long-context capacity is a deployment decision as much as a model one.

A related caution, and OpenAI’s own long-context documentation is candid about it: performance is not flat across the window. Retrieval accuracy from the middle of a very long prompt tends to be worse than from its ends. Treating the full 1,047,576 tokens as uniformly usable is the mistake this figure most often invites — the number is a hard limit, not a quality guarantee.

Three limits that bite before the window does

Most requests that fail near the top of a large context window fail for a reason other than the window.

• Tokens per minute. Rate limits are expressed in requests and tokens per minute per model and tier, and a single 900,000-token prompt is charged against your TPM allowance in one go. On many tiers one such request exceeds the whole minute’s budget, which returns a 429 rather than a context error. This is the limit that stops people first and it looks nothing like a context problem.
• Time to first token. Prefill is proportional to prompt length, so a very large prompt has a first-token latency measured in tens of seconds. Client timeouts, proxy timeouts and serverless function limits all sit in that range. Streaming does not help here — there is nothing to stream until prefill finishes.
• Cost. Input tokens are cheaper than output tokens and a million of them is still a million. A long-context request repeated per user turn without attention to what is being re-sent each time is the most expensive shape of application there is.

One more limit is self-inflicted and worth naming: the unit. Context windows are quoted in tokens and documents are measured in words or pages, and the conversion is not a constant. English prose runs somewhere near three-quarters of a word per token; code, JSON, tables, non-Latin scripts and long identifiers all run substantially worse, and a CSV of numbers can approach one token per character. Sizing a 1,047,576-token budget with a words-times-1.3 rule of thumb is fine for prose and can be off by a factor of three on a source tree. The only reliable answer is to tokenise a representative sample of your own material and measure the ratio, once, rather than to inherit somebody else’s figure.

Checking the figure yourself

Two ways, and the second is the one to automate.

1. Read the row on the model page for the exact model string you send. Aliases float: today’s gpt-4.1 resolves to some dated snapshot, and the alias’s limits are whatever that snapshot’s are. Pinning the snapshot makes the figure stable for as long as the snapshot exists.
2. Do not hard-code the number in application code that decides whether a prompt fits. Keep it in one configuration value per model, and treat a context-length error from the API as authoritative over your own arithmetic. The API knows the current limit; a constant compiled in six months ago does not.

And do not infer either figure from a competitor’s comparison table or from a summary article. Context lengths are among the most frequently mis-stated numbers in this field, usually by rounding 1,047,576 to a million and then treating the million as the constraint the code should enforce. The vendor’s own model page is the only source worth citing, including in this page’s own case.