Context window planning: what a 1M-token window actually costs
A big context window is a capacity limit, not a budget.
Computed from the SelfBench catalog of 30 models, Oct 15, 2026. Prices are published list rates; every model page links to its source.
23 of the 30 models in our catalog accept at least a million tokens of context. That is enough for most codebases and most document sets — so the interesting question is no longer "does it fit" but "what does filling it cost".
What is available
| Model | Context window | Max output | Cost to fill the window, one request |
|---|---|---|---|
| GPT-5.6 Sol | 1.1M | 128K | $4.20 |
| GPT-6 Astra | 1.1M | 128K | $10.50 |
| GPT-6 Luna | 1.1M | 128K | $0.105 |
| GPT-6.1 Sol | 1.1M | 128K | $2.10 |
| Gemini 3.1 Pro Preview | 1.0M | 65.5K | $2.10 |
| Gemini 3.8 Flash | 1.0M | 65.5K | $0.786 |
| Gemini 3.8 Flash Cyber | 1.0M | 65.5K | $1.57 |
| Gemini 4 Argon | 1.0M | 1.0M | $2.10 |
| Kimi K3 | 1.0M | — | $3.15 |
| Qwen3.7-Plus | 1M | — | $0.300 |
| Qwen3.8-Flash | 1M | — | $0.120 |
| Qwen3.8-Max | 1M | — | $1.79 |
| Claude Fable 5.1 | 1M | 128K | $10 |
| Claude Haiku 5.5 | 1M | 128K | $0.100 |
| Claude Opus 5.5 | 1M | 128K | $4 |
| Claude Sonnet 5.5 | 1M | 128K | $2 |
| DeepSeek-V4-Pro-0813 | 1M | 384K | $1.32 |
| DeepSeek-V4.1-Flash | 1M | 384K | $0.300 |
| Muse Wonder | 1M | — | $4 |
| Grok 4.3 | 1M | — | $1.25 |
| GLM-5.3 | 1M | — | $1.19 |
| GLM-5.3-Flash | 1M | — | $0.120 |
| GLM-5.3-FlashX | 1M | — | $0.300 |
| Grok 4.5 | 500K | — | $1 |
| Grok 4.6 | 500K | — | $1 |
| Grok 4.7 | 500K | — | $1 |
| GPT-5.3-Codex | 400K | 128K | $0.700 |
| Kimi K2.6 | 262.1K | — | $0.249 |
| Kimi K2.7 Code | 262.1K | — | $0.249 |
| Grok Build 0.1 | 256K | — | $0.256 |
"Cost to fill the window" is the input price at the standard short-context rate — a planning number, not a quote. Models with a long-context tier cost more than this at the top of their range; the tier is noted on each model page.
The number that matters
Filling a million-token window costs between $0.100 and $10.50 per request across the million-token models here. Run that against your request volume before building a pipeline that re-sends a full corpus on every turn.
Two patterns make this tractable:
- Cache the stable prefix. A corpus that does not change between requests should be cached, not re-sent at full price. Cache pricing →
- Send only what the request needs. Retrieval exists because sending everything is both expensive and less accurate — models attend worse to a million tokens than to the twenty thousand that matter.
How to choose
- Measure your input distribution: what fraction of requests exceed 100K tokens? If it is small, the big-window models are not the constraint you are solving for.
- Price the 95th percentile request, not the typical one — the expensive requests are what blow a budget.
- Check the tier boundary. A workload sitting just under a threshold is fine until it crosses it.
- Keep a cheaper model for the requests that fit in a small window, and route the big ones to a large-window model.
Frequently asked questions
Does a bigger context window cost more?
The window itself is free; the tokens you put in it are not. A 1M-token window used fully costs a thousand times a 1K-token request at the same input rate — and some vendors additionally raise the rate above a threshold.
Can I split a document across several requests instead?
Sometimes, and it is often cheaper, but it changes the task: summarising in chunks then combining is a different (usually weaker) approach than one pass, and it costs extra output tokens for the intermediate results.
Should I choose the model with the biggest window?
Only if your workload needs it. Window size is a constraint you must satisfy, not a feature you benefit from — and models with very large windows are rarely the cheapest for small requests.