GPT-4o's Context Window: What 128K Actually Buys You

GPT-4o’s context window is 128,000 tokens. That single number answers almost nothing on its own, because it is a budget shared between your prompt and the model’s answer, and because “tokens” converts to text at a rate that depends heavily on what the text is.

The documented figure

OpenAI publishes context length per model on its models reference. For the GPT-4o family the listed context window is 128,000 tokens, and it has been that figure since the model was introduced in May 2024 — the original gpt-4o-2024-05-13 snapshot and every later one carry the same window. You can read it per snapshot on OpenAI’s models page, which is the only place worth taking it from: the number is per model and per snapshot, and a blog post about the family does not tell you what the string you actually put in model supports.

A context window is the maximum number of tokens the model can attend to in one request. It is not a per-day quota, it is not a rate limit, and it is not per conversation. It is a hard ceiling on the length of one sequence: system message, every prior turn you resend, the current user message, any tool definitions, any tool results, and the tokens the model is about to generate. Exceed it and the request fails before any generation happens, with a context_length_exceeded error rather than a truncated answer.

The window is shared with the output

This is the part that catches people, and it is why 128,000 is not the size of the prompt you can send. The window covers input plus output. If you send 127,000 tokens of prompt, there are 1,000 tokens of room left for an answer, and the model will stop at that boundary whatever you asked for.

On top of that, GPT-4o has a separate and much smaller cap on how many tokens a single response may contain — 16,384 for gpt-4o-2024-08-06 and later snapshots, 4,096 for the original May 2024 one. So the practical shape of the budget is:

usable_input  =  128,000  −  (tokens you want back)
max_response  =  min(  max_completion_tokens ,
                       16,384 ,
                       128,000 − input_tokens  )

Which means the largest prompt that still leaves room for a full-length answer is about 111,600 tokens, not 128,000. If your answers are short — a classification label, a JSON object of a few hundred tokens — you can push the prompt much closer to the ceiling. The two caps are independent and both apply; the smaller one wins. The consequences of hitting the second one are the subject of the output-token cap.

How much English is 128,000 tokens

There is no exact conversion, because tokenisation is a property of the text, not of a rate. But there is a documented approximation worth using, and the honest way to present it is to show the ratio and let you redo the arithmetic with your own.

OpenAI’s own tokenisation guidance gives the English rule of thumb as roughly four characters per token, or about 0.75 words per token. Take that ratio as the assumption and everything else is division:

assumption:  1 token ≈ 0.75 English words   (OpenAI's stated heuristic)

128,000 tokens × 0.75            =  96,000 words

double-spaced manuscript page    =  250 words
  96,000 / 250                   =  384 pages

single-spaced printed page       =  500 words
  96,000 / 500                   =  192 pages

paperback novel                  ≈  90,000 words
  96,000 / 90,000                =  1.07 novels

So: a short novel, or a few hundred pages of a manuscript, or a medium-sized codebase’s worth of source — if you spend the entire window on input and want nothing back. Halve your intuition for a real request that also has to produce an answer, and halve it again if you are resending a long conversation on every turn.

Where the ratio gets worse

The 0.75 words-per-token figure is for ordinary English prose. Several common inputs are much denser in tokens per unit of meaning, and the reason is the same in each case: the tokeniser learned merges from a corpus, and text unlike that corpus falls back to shorter pieces.

• Code. Indentation, punctuation, camelCase identifiers and rare symbols all split. A file of source typically costs noticeably more tokens per character than prose of the same length.
• Non-Latin scripts. GPT-4o moved to the o200k_base tokeniser, whose larger vocabulary reduced token counts for many non-English languages relative to the older cl100k_base. It reduced them; it did not equalise them. Compare with what o200k_base changed.
• JSON and markup. Every quote, brace, colon and escaped character is a token or part of one. Serialising tabular data as JSON can cost several times what the same data costs as CSV.
• Random strings. UUIDs, hashes and base64 have no learned merges at all and tokenise close to worst case.

Images are a separate accounting again: they do not enter the window as characters but as a computed token count based on their dimensions, which is worked through in the image tiling formula.

Planning against the number

Two habits make the window a non-issue rather than an intermittent production failure.

First, count before you send. The tokeniser is public and runs locally, so there is no reason to discover a 128,001-token request from a 400 response. Budget explicitly: a fixed reserve for the answer, a fixed reserve for tool definitions, and whatever is left for retrieved context — then trim the retrieved context to fit rather than hoping.

Second, do not treat the ceiling as a target. Filling a long window has costs that are not refusals: attention work grows faster than linearly in sequence length, so latency and price climb together, and retrieval quality inside a very long context is not uniform across positions. A prompt at 100,000 tokens is a design decision to defend, not a free consequence of the window being large.