Context windows: what a million tokens costs to fill

A FinOps guide by OptimNow · prices from the live OptimToken catalogue

A context window is advertised as a capability: 1M tokens, 400K, 200K. The number says what the model will accept and nothing about what filling it costs, and the two facts are published in different places. An input rate is quoted per 1M tokens, so for any model that accepts a 1,000,000-token prompt, the published input price is the price of one full-length request. Nothing has to be multiplied. Every figure below comes from the 2026-09-20 catalogue snapshot and is recomputed nightly.

What one million tokens costs

On that snapshot, 89 of the 265 priced models accept a prompt of 1,000,000 tokens or more. Filling that prompt once costs $0.03 on Qwen3.7 Flash and $30.00 on GPT-5.5 Pro. That is 1,000x across models sold on the same advertised capability. The median is $0.75.

Take $0.01 of input per request as the budget line. It is an assumption chosen to stand for one interactive call, not a figure measured from any deployment. At that budget Qwen3.7 Flash gives you 33.3% of a 1,000,000-token prompt and GPT-5.5 Pro gives you 0.03%.

OpenRouter publishes an exact context_length for every model and the OptimToken table rounds it for display. The models labelled 1M are not all the same size. The label covers 1,000,000, 1,048,576 (2²⁰, the value most vendors ship), 1,050,000 and 1,310,720. A cost computed by multiplying the label would be wrong by up to 24% on the last of those.

Every figure on this page is anchored to exactly 1,000,000 tokens. That prompt fits every model counted here, because the rounded label only carries an M suffix from 1,000,000 upward, and its cost is the published input rate with no arithmetic applied.

The second read is where the bill is decided

A long context is rarely read once. Agent loops, multi-turn chat and document Q&A re-send the accumulated history on every call, and the provider bills it as input each time. Per token, input is the cheaper side: across the 265 priced models here, output costs 4.0x input at the median. That price signal is why teams look at the output rate first, and why the input line is the one that grows with conversation length.

Prompt caching is the published lever. A cache-read rate charges a fraction of the input price for tokens the provider has already seen. Among the 89 models accepting a 1M prompt, 76 publish one, at a median 90% off the input rate.

In the under 100K band, 4 of 18 models publish a cache-read price, against 76 of 89 at 1M and above. Vendors selling a large window mostly also sell the discount that makes re-reading it affordable. That is a pattern in the 2026-09-20 snapshot, not a policy any vendor has stated, and it is measured on published rate cards rather than on negotiated ones.

Worked example: 10 reads of the same context

The 10 reads are an assumption, not a measurement. They stand for one document held across a short agent run or a chat session that keeps referring back to it. The first read is billed at the input rate in every case, because there is nothing cached yet.

Prices are per 1M tokens, which at this prompt size is per request. Compare Qwen3.7 Flash and GPT-5.5 Pro side by side for the full rate cards, output and cache rates included.

Where the discount is not available

Of the 89 models accepting a 1M prompt, 13 publish no cache-read rate at all. For those the tenth read costs what the first did. The dearest of them, GPT-5.5 Pro, fills at $30.00, so 10 reads is $300.00 with no published discount to apply.

The cheap end has the same gap. Qwen3.5-Flash fills a 1,000,000-token prompt for $0.065 and publishes no cache rate either. Across 10 reads it costs $0.65, which is less than what 55 of the 76 models with a published cache rate charge over the same 10 reads. A missing cache rate is a reason to run the arithmetic, not a reason to drop the model.

What to do with this

Context selection is a cost decision as much as a quality one. The levers below come from OptimNow's FinOps practice library and apply from the first production workload, not only at scale:

• Minimum viable context: one document, not the corpus. One file, not the repository.
• Rolling window: keep the last N turns. Cheap to implement, and it loses long history.
• Summarization checkpoints: compress the history into a summary as the conversation approaches the limit.
• Retrieval precision: broad-match RAG puts marginally relevant fragments into every prompt. Tune top-k and the relevance threshold.
• Set max_tokens on every call. Unbounded responses are the most common avoidable overrun.

These matter most where one workload sends large prompts repeatedly. On an estate at Crawl maturity, with no per-feature cost allocation in place, measure the average prompt size before optimizing it. The practice library lists an average prompt size above the design estimate as a detection signal in its own right, and that measurement comes before any lever.

Pull the average input tokens per request for your largest AI feature from last month's usage export and multiply by the published input rate for the model it runs on. If that figure sits above your output spend, the window is your cost driver.

Figures on this page come from the 2026-09-20 price snapshot and rebuild nightly.

The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own prompt sizes and cache rates measured against the models you already run, OptimNow runs that review.

Data snapshot: 2026-09-20 · Compare all models · Cloud compute pricing · All guides