Context window length and what it costs

A large context window is a limit, not a charge; the charge is every token you actually place in it, billed as input on every call that carries it.

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

You pay for the context you fill, on every call

A context window is the most tokens a model can take in one request, and having a large one costs nothing by itself. What costs money is filling it: every token placed in the context is billed as input, and it is billed again on every call that carries it. A long document attached to a conversation is paid for once per turn, not once per conversation.

So the useful question is not how big the window is but how much of it your requests use on average, and how many times the same material is sent. Both multiply straight into the input side of the bill described on the token price table.

Output length is separate from the window. Models commonly set a lower limit on how many tokens one answer may contain, and a request that needs a long answer can be cut off even when the input fits easily. A truncated answer that has to be requested again is billed twice.

Why the same material gets billed again

Most LLM APIs are stateless. The model remembers nothing between calls, so anything it needs to know has to be in the request. In a chat, that means the whole history is resent each turn. In a document tool, it means the document goes along with every question.

That turns long context into a repeated cost. A conversation that grows by a few hundred tokens per turn sends the first turn again on the second call, the first two on the third, and so on, so total input across the conversation rises faster than its length.

Where a seller publishes a cached input rate, the repeated part can be billed lower, provided it sits at the start of the prompt in the same order each time. Where no cached rate exists, every repeat is billed at the standard input rate.

The window as a filter, not a price

Window sizes are given in tokens, often in thousands, and they vary widely between models. The size decides what fits. A model with a smaller window cannot take a long contract in one piece, however cheap its rate.

That makes the window a floor you set before comparing price. The LLM cost calculator, in its Help me choose mode, asks for the longest prompt the model must take and leaves out models whose window is smaller. Models whose window we do not hold are left out too, rather than assumed to fit, so an empty result means a gap in what has been read, not that no model exists.

A model's own documentation states its window. A size such as 8K, 32K or 128K tokens says how much text fits. It says nothing about the price per token, which is set by the seller and read from its pricing page.

Pricing a contract review tool both ways

Take a tool where a lawyer loads a contract and asks questions about it. The long-context design sends the whole contract with every question. Input per request is contract tokens plus question tokens, and monthly input is that times questions per contract times contracts per month.

The retrieval design splits the contract into passages, picks the few that match each question and sends only those. Input per request is a handful of passages plus the question. Monthly input is far smaller, and there is a new cost: embedding the contract once and running a search per question, which belongs on the bill too.

Which comes out cheaper depends on how many questions are asked per contract. Few questions favour sending the whole thing; many favour retrieval. The quality trade, whether the right passages are found, is yours to test, and nothing on this site measures it.

Keeping context from growing on its own

Summarise old turns instead of resending them word for word. Drop tool outputs from the history once the model has acted on them. Set a token budget per request in code and log when a request exceeds it, so growth shows up as an alert rather than an invoice.

Also check what the model returns. Some sellers count reasoning tokens on long inputs as output, and a model asked to work through a long document may write more than expected. The output cap is the control for that half.

Each of these controls lives in your code and needs no seller to agree to anything. Each can be switched on for one feature at a time and measured from the usage logs before it goes wider.

Measuring how full your requests really are

Log input tokens per request and look at the distribution, not the average alone. A feature where most requests are short and a few fill most of the window behaves differently from one where every request is half full, and the long requests can belong to a small group of users or a single integration.

Once the long tail is visible, decide what to do with it. A hard limit that truncates old history, a summary step that kicks in past a threshold, or a separate path for very long documents can each pull the tail in without touching the ordinary requests.

Do the arithmetic before choosing. Average input tokens per request times requests per month, divided by a million, times the input rate, is the monthly input cost now. Run the same sum with the capped average to see what the limit is worth.

What we could not answer

⚑Context window sizes are held for some models and not others, so a model can be missing from a context filter because the figure was not read.
⚑Nothing here measures whether a model answers as well near the end of a long context as near the start.

What this rests on

infratoapp, “Context window length and what it costs”, read 27 October 2026. models with a token price on record: 467. https://www.infratoapp.com/blog/context-window-length-and-what-it-costs

Questions people ask about this

Does a bigger context window cost more?

Not by itself. You are billed for the tokens you send, not for the size of the window. A large window only costs more if you fill it, and then every token in it is billed as input on every request that carries it. A long attached document is paid for again on each turn.

Why does a long chat get more expensive per message?

The API is stateless, so each new turn resends the earlier conversation as input. The first message is sent once, the second carries the first, the third carries both, and so on. Total input grows faster than the conversation, unless old turns are summarised or a cached rate applies.

Is retrieval cheaper than long context?

Often, when many questions are asked of the same material, because each request sends only matching passages instead of the whole document. Retrieval adds embedding and search costs, and whether it finds the right passages is a quality question you have to test on your own data.

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