Skip to content
InfratoApp
InfratoApp / Blog / state-the-context-window-on-every-model-page

State the context window on every model page

A filter on context window cannot include a model with no stated window. With no figure on the page, the model drops out of the list.

INFRATOAPP · PUBLISHED 17 OCTOBER 2026 · 5 MIN READ · 3 SOURCES · PRICES LAST CHECKED 18H AGO

A filter drops what it cannot read

State the context window for every model on the page where its price is, in tokens, for the model as you serve it. A buyer who sets a minimum window before looking at price is running a filter, and a model with no stated window is no answer on record to that filter. It does not rank low. It disappears from the comparison, and the buyer never sees the rate beside it.

That is how we read a blank too: a missing value is no answer on record, never a no, and how values are read says so. The effect on a buyer's shortlist is the same either way.

Sellers sometimes leave the window off because it is the maker's figure and seems obvious. To a buyer comparing sellers it is the opposite of obvious, since the served figure is the one that can differ.

Why the model maker's figure is not enough

A model has a context length set by the people who trained it. A seller may serve it with a shorter one, to fit memory or to keep latency down. Of the 467 models we price, 93 are sold by more than one seller, and a buyer comparing those sellers needs each one's served window, not the maker's.

The arithmetic behind a shorter window is honest. The key-value cache grows with context length and with the number of requests served together, on top of the weights, so a long window costs the seller memory on every request. That memory cannot be given as one figure, but its direction is clear, and a seller that trims the window for it should say so.

The team most exposed is one that tested the model at its maker and then moved to a cheaper seller. Their prompts were sized for the longer window, and the first sign of the difference is an error in production.

Input window and output limit

Two numbers are often folded into one: the total context, and the most the model will write in one response. Generating long documents depends on the second; passing long documents in depends on the first. State both, labelled, and say whether the output counts against the total.

If the window can be raised on request, or differs by tier, say that on the same row. A footnote saying longer contexts are available on enterprise plans tells the buyer there is a number and that you have not shared it.

Count the system prompt and any tool definitions against the window as well, and say so. Tools that take a large share of every request leave less room for the buyer's own text than the headline window suggests.

When price changes with length

Some sellers charge a different rate above a certain prompt length. That is reasonable and has to be on the pricing page itself, with the threshold in tokens and the second rate for both input and output. Otherwise prompts that sit near the threshold get costed at the lower rate, and the higher one turns up on the invoice.

Put the long-context rate on its own row rather than in a sentence under the table. The token price table can only hold a rate it can read as a rate.

Say also whether the long-context rate applies to the whole prompt once the threshold is passed or only to the tokens above it. The two readings give very different bills for a prompt just over the line.

Memory arithmetic a buyer may already have done

Some buyers have run the model themselves before shopping for an API, and they know what a long window costs in memory. Weights take roughly the parameter count times the bytes per parameter: a 13 billion parameter model in 16-bit is about 26 GB before anything else. The key-value cache comes on top, grows with every token of context and every request in the batch, and has no single figure.

A buyer who knows this reads a short served window as a sign of how the seller fitted the model onto its hardware, and a long one as a cost the seller is carrying. Either reading is fair. What they cannot do is read a blank, so the window you chose has to be printed even when it is shorter than the maker's.

Buyers who have not done the arithmetic still meet its result. A long-document feature that worked in testing at one seller and fails at another is one way to learn that served windows differ, and the model itself may not be at fault.

How to write it so it is read correctly

Give the window in tokens as a plain number with the word tokens beside it. Avoid writing it as a count of pages or words, which depends on language and formatting and cannot be compared. If you write a shorthand such as 128k, also give the full figure, since some pages use a thousand and some use 1,024.

Then keep it current. When you raise a window, the old figure is what buyers filter against until the next read, and a claimed listing is how you correct it sooner.

When the window changes, add a dated line to the changelog as well as changing the figure. Buyers who filtered you out last month have no reason to look again unless something tells them the answer moved.

What we could not answer

  • ⚑We do not hold served context windows for every seller, so this cannot say how many sellers shorten a model's window.
  • ⚑How often buyers filter on context before price is reasoned from how comparison works, not measured.
infratoapp, “State the context window on every model page”, read 27 October 2026. models sold by more than one seller: 93. https://www.infratoapp.com/blog/state-the-context-window-on-every-model-page

Questions people ask about this

What is an LLM context window?

The largest number of tokens a model will process in one request, counting the prompt and, at many providers, the response as well. A token is roughly four characters of English. A seller may serve a model with a shorter window than the one its makers set.

Why do providers serve the same model with different context windows?

A longer window needs more memory per request, because the key-value cache grows with context length and with the number of requests served together. A seller may shorten the window to fit its hardware or keep responses quick. The served window is the one a buyer gets.

Does a longer context cost more per token?

At some providers, yes: a second, higher rate applies once a prompt passes a stated length. At others the rate is flat whatever the length. Only the provider's own pricing page can say which, and the threshold should be given in tokens.

These render as FAQPage structured data · answers are filled from the same live figures

Read next

Deprecation notices buyers can plan around

A model retirement notice is useful when it gives a date, a named replacement and a migration note in one place. Buyers read the policy before they commit.

Rate limits belong on the pricing page, not only in the docs

A token price without the rate limit attached is half a price. Buyers hit limits at launch, so state them by tier where the rates are, in the same units.

What buyers compare before they choose an LLM API

An LLM API is checked on the token rate, then context length, then rate limits, then what happens when the model retires. Skip one and the buyer can leave.