Context Window Pricing in Extended Context Models

Context window size stopped being the interesting number in this market. Every serious provider now offers 1M tokens or close to it, so the real question moved one level down: what does it cost to actually fill that window, and does the price stay flat or jump once you cross some threshold? That second question separates the same-looking models by a factor of 71x on input pricing alone for identical workloads.

Not long ago, a context window in the tens of thousands of tokens counted as generous. Now Meta's Llama 4 Scout advertises a context window an order of magnitude beyond that, and as of September 2026, AI Model Watch tracks 37 generally-available models offering at least 1M tokens. The window isn't scarce anymore. The pricing architecture behind it produces the real differences.

The two pricing architectures and their providers

Two structures dominate, and they behave nothing alike once a workload gets big.

Flat-rate pricing charges the same per-token price no matter how much of the window gets used. Anthropic's current lineup runs flat across the full 1M window. Earlier Claude models, including Sonnet 4.5 and older versions, charged 2x input and 1.5x output once you crossed 200K tokens. Dropping that surcharge is one of the bigger pricing shifts of 2026.

OpenAI splits the difference. GPT-5.5 and GPT-5.4 stay flat up to 272K tokens, then jump to tiered rates above that: GPT-5.5 rises to $10 input / $45 output per million, GPT-5.4 to $5/$22.50.

Tiered-surcharge pricing doubles (or worse) once you cross a set line. Google's Gemini 3.1 Pro doubles input from $2.00/M to $4.00/M at the 200K mark, with output climbing from $12.00/M to $18.00/M, a threshold low enough to catch a lot of routine long-context work, not just extreme cases. Alibaba's Qwen3.5-Plus tiers at a context threshold ($0.40 to $0.50 input, $2.40 to $3.00 output), with the exact cutoff point varying by deployment. MiniMax M3 tiers at 512K with a straight doubling. xAI's Grok doubles at 200K tokens and up.

DeepSeek V4 adds a wrinkle nobody else really has. Its flat base rates are already the cheapest in the field ($0.14/$0.28 for Flash, $0.435/$0.87 for Pro), but API calls placed during Beijing peak hours carry a 2x multiplier over off-peak pricing. That's a scheduling problem disguised as a pricing footnote, and it won't show up if you're just skimming the headline rate.

Two teams running the exact same model on the exact same workload can land on wildly different bills, purely because one of them crossed a threshold the other stayed under. For heavy users, architecture affects the total bill more than the sticker price does.

What filling a 1M-token window costs across the model landscape

Per-million-token rates are the wrong unit here. The number that actually matters is: what does one full 1M-token request cost, start to finish?

Using the standard, cache-miss rates from the June 2026 Morph comparison table, the input cost of a full 1M-token window ranges like this:

• DeepSeek V4 Flash: $0.14
• DeepSeek V4 Pro: $0.44
• Qwen3.5-Plus: $0.50 (once past its 256K tier)
• MiniMax M3: $0.60 (once past its tier)
• GPT-5.4: $2.50
• Claude Sonnet 4.6: $3.00
• Gemini 3.1 Pro: $4.00 (once past its 200K tier)
• GPT-5.5: $5.00
• Claude Opus 4.8: $5.00
• Claude Fable 5: $10.00 (currently suspended, per the source that tracks it)

That's the 71x spread between DeepSeek V4 Flash and Claude Fable 5 for filling the same window. And output pricing widens the gap further for anything generation-heavy: Claude Fable 5 runs $50 per million output tokens against DeepSeek V4 Flash's $0.28.

The GPT-5.6 family adds three more reference points: Sol at $5/$30 input/output per million, Terra at $2.50/$15, and Luna at $1/$6.

Not everyone chased the 1M ceiling. Grok 4.5 caps its window at 500K tokens, priced at $2/$6 per million, the one frontier flagship that stopped short of 1M rather than following the pack. Meta's Llama 4 Scout, meanwhile, offers 10M tokens at zero cash cost, but that's open weights: running it means self-hosting or paying a third party for inference. "Free" Here is a compute problem.

Before ranking any of these models, convert everything to cost-per-full-window. The order changes substantially from what the headline per-token rate suggests.

How prompt caching reshapes the cost comparison

Caching cuts input costs by 75 to 90% on repeated prompt prefixes, things like system prompts or static reference documents that show up in call after call. Anthropic, OpenAI, and Google all support it. The mechanism is simple: pay full price the first time a prefix gets sent, then pay a much lower cached-read rate on every repeat.

Anthropic prices cached reads at 0.1x the base input rate, with a surcharge on the first write. DeepSeek Flash's cache-hit rate drops to $0.0028 per million tokens, which more or less erases input cost on repeated sends. Gemini 3.1 Pro charges $0.20/M for cached reads but adds $4.50 per million tokens for every hour the cache sits in storage, a running cost that accrues even if no one calls it.

Adoption isn't even close to universal. Token spend data shows roughly 74.5% of businesses on Anthropic's API have caching turned on, against 50.8% on OpenAI. That means close to half of OpenAI's user base is paying full price on prefixes they're reusing over and over.

Caching can flip a ranking. A model with a higher sticker price but aggressive cached-read pricing can end up cheaper than a nominally cheaper model, once call volume and prefix reuse get high enough. And in agent sessions, where the same history gets carried forward across dozens or hundreds of tool calls, the savings from caching compound with every step. A single-request comparison badly understates what caching saves across a full session.

The tokenizer and output cap variables that alter the comparison after you've chosen a model

Picking a model doesn't end the cost conversation. Two variables inside the model itself keep moving the number after that decision's made.

First, tokenizers aren't standardized across versions. Claude Opus 4.7 and later, including Fable 5, use a new tokenizer that can produce up to 35% more tokens for the same input text compared to pre-4.7 Claude models. Same document, same words, more tokens consumed, and a bigger bite out of both the context window and the budget. Any cost estimate built on old token counts from earlier Claude versions will run short. Teams moving between Claude generations need to re-benchmark actual token counts on their own content rather than carry forward last year's numbers.

Second, output caps haven't kept pace with input windows. Reading capacity exploded; writing capacity mostly didn't. Most 1M-class models still cap output somewhere between 64K and 128K tokens. DeepSeek V4 Flash stands out as an exception at 384K, roughly three times the output ceiling of most peers in the same class. Claude Opus 5 can reach 300K output tokens, but only through the Message Batches API with a specific beta header (output-300k-2026-03-24); the standard Messages API tops out at 128K.

Reasoning tokens complicate this further. Models with always-on adaptive thinking can consume a meaningful share of the output budget on internal reasoning steps, reducing what remains for the final answer the user actually sees. So a task like "translate this entire book" or "write out the full report" still requires chunking the generation across multiple calls on most models, no matter how big the input window looks on the spec sheet. Output caps decide what fits in one call. Input window size doesn't.

Advertised context vs. effective context, the accuracy degradation hiding inside the window

A 1M-token window tells you what fits. It doesn't tell you what the model actually pays attention to, and those two numbers aren't the same. Effective capacity is around 60 to 70% of the advertised maximum, and the drop-off isn't gradual.

This is the well-documented "lost in the middle" problem: accuracy on questions that require pulling information from the middle of a long context can fall 20 to 40% compared to questions about content near the beginning or end. The pattern holds across multiple models. Performance stays solid right up to a threshold, then falls off a cliff rather than sloping down. There's no early warning sign before it happens.

Needle-in-haystack tests, the benchmark most providers lean on to demonstrate long-context skill, turn out to be a weak proxy. Nearly every model tested can find a single needle in a huge haystack perfectly, yet on the broader RULER benchmark suite, models tend to lose ground on other long-context tasks as the context grows. Passing needle-in-haystack doesn't mean the model actually understands the full context; it means the model is good at finding one specific fact.

Even the strongest published numbers leave real gaps. GPT-5.6 Sol scores 73.8% on the MRCR v2 eight-needle test between 512K and 1M tokens, and 77.1% on GraphWalks BFS at 1M tokens, per the Morph comparison. Claude Fable 5 reports 77% on the AA-LCR long-context benchmark. Those are the best figures on record right now, and they still mean roughly a quarter of relevant retrievals miss.

That has a direct cost consequence: paying to fill 900K tokens of a window the model only reliably uses 60 to 70% of means a real slice of every dollar spent on long-context input buys tokens the model may never effectively act on. This flips the model-selection approach on its head. A model with a smaller but more reliable effective window can outperform a model with a bigger window that degrades once content lands in the middle.

Latency and infrastructure costs that don't appear on a token invoice

Self-attention compute scales quadratically with sequence length. That's not a tuning choice any provider made; it's baked into how transformer architecture works. Time to first token can stretch from a couple of seconds to over a minute once a request pushes toward 1M tokens, and no amount of clever pricing changes that curve.

For anything real-time, chat interfaces, interactive agents, a window that's technically affordable can still be functionally unusable if the latency at full length makes the response too slow to matter.

There's also a hardware cost that never appears on an API invoice. KV cache overhead for a 1M-token context can demand up to 125 GB of VRAM per session on large models, and the figure scales substantially with model size. Anyone using a managed API absorbs this cost indirectly, buried in the price. Anyone self-hosting an open-weight model, Llama 4 Scout, Mistral Large 3, Mistral Small 4, has to provision for it directly, with real hardware and real budget.

That tradeoff explains why Mistral Large 3 and Mistral Small 4 cap out at 256K context rather than chasing 1M: it's a deliberate ceiling set against VRAM and latency limits, not a technical shortfall. On the far end of the spectrum, Magic.dev's LTM-2-Mini advertises a 100M-token window, but there's no visible evidence anyone outside Magic.dev runs it at that scale. The infrastructure demands at 100M tokens are almost certainly why.

Agentic workflows feel this hardest. A task that runs dozens or hundreds of tool calls, each one adding to an already-loaded context, stacks latency on latency at exactly the point where quadratic attention cost bites the most.

Context compression as a cost lever before caching and routing

Compression tackles the problem from the input side, before caching or model choice even enter the picture. If effective context tops out around 60 to 70% of the advertised window, and accuracy sags in the middle of what's left, then sending less to begin with fixes both the cost and the accuracy at once.

Morph Compact, for instance, cuts context by 50 to 70% while holding 98% verbatim accuracy, meaning what survives stays word-for-word identical to the source. Nothing gets paraphrased, nothing drifts the way it can with summarization, and the process runs at around 33,000 tokens per second. Because compressed history carries forward on every later call in a multi-step agent session, compacting early in that session cuts the total session cost by far more than a single-request comparison would suggest.

There's a quality argument here too: less diluted context in the middle of the window tends to produce better output, and cheaper output.

Compression isn't the same thing as summarization, and the difference matters. Summarization generates new text and carries real hallucination risk. Extractive compression keeps the original wording intact. The model downstream is reasoning against the actual source material rather than someone's paraphrase of it.

Retrieval-augmented generation offers a different fix for a different shape of problem: instead of loading an entire corpus and hoping the model finds the right paragraph, pull only the relevant sections and place them near the end of the context, where models attend most reliably. The practical rule of thumb: use RAG when the answer lives in a specific, findable section. Use a large context window when the task genuinely needs the model reasoning across the whole corpus at once.

Routing and gateway infrastructure as an operational practice for model and pricing selection

None of this stays a one-time decision. Pricing tiers shift, tokenizers change between versions, output caps vary by API endpoint, and effective context degrades in ways that become visible only once a workload actually hits the wall. Choosing a model once and leaving the choice alone produces a slow drift away from the best available cost and accuracy tradeoff, because providers update their systems while you continue relying on that original choice.

That's why routing infrastructure, systems that direct a given request to whichever model and pricing tier fits it best, has turned from a nice-to-have into an operational necessity for anyone running meaningful volume. A short, simple query doesn't need a 1M-token flagship model billed at tiered rates. A document analysis task that will blow past 300K tokens might need exactly that, but only if it's routed to a provider whose threshold sits above the job's actual size.

Getting this right means treating model selection the way infrastructure teams treat any other cost center: track the threshold each provider sets, track cache hit rates, track actual token counts against whatever the tokenizer produces this month, and route each request to the option that fits its size and its accuracy needs. The provider with the lowest headline rate isn't always the cheapest choice once tiering, caching behavior, and effective context are all accounted for. Treating pricing architecture as an ongoing operational variable, rather than a one-time comparison chart, is what actually keeps the bill under control as these systems keep changing.