The Long-Context Price Cliff: 200K and 272K Thresholds

A long-context pricing threshold is the token count at which an LLM vendor stops billing your request at the headline rate — and on the two providers that state the rule outright, OpenAI and xAI, crossing it reprices the entire request, not just the tokens above the line. One token past the threshold, and every input token you sent bills at the higher rate.

That asymmetry is what makes these thresholds cliffs rather than tiers. A marginal scheme — pay the premium only on the overflow — would make a 201,000-token prompt cost pennies more than a 199,000-token one. Whole-request repricing makes it cost roughly twice as much on the vendors that bill this way. Teams budgeting long-context workloads off the headline per-million rate are budgeting off a number that, on some models, covers less than a fifth of the advertised window.

This guide maps every documented cliff as of the time of writing — OpenAI’s 272K line, xAI’s and Google’s 200K lines, and Anthropic’s deliberate absence of one — then works the arithmetic: what a single crossing costs, why prompt caching does not dodge it, and the four engineering mitigations that actually hold up. Every number is recomputed from vendor-published rates.

The mechanism is easy to miss because the pricing pages present it as an innocuous second table row. It is not a surcharge on the tokens above the threshold. It is a request-level classification: the moment the prompt qualifies as long-context, the long-context rate applies to all tokens in that request — input, output, and cached input alike.

Both vendors that run the largest cliffs say this in so many words. OpenAI’s GPT-5.6 model pages state that prompts above 272K input tokens are priced at 2x input and 1.5x output for the full request. xAI’s pricing docs make the same rule explicit as a general policy across its long-context models.

Two properties follow. First, the cost function is discontinuous: request cost jumps at the threshold rather than bending. On Grok 4.6, the input bill for a 201,000-token prompt is $0.804 at the long-context rate of $4.00 per million, while a 199,000-token prompt bills $0.398 at the standard $2.00 — a 2.02x jump for 1% more context. Second, the multiplier stacks with every other multiplier the vendor runs. On OpenAI, batch and flex tiers stay at 50% of standard at both context lengths, fast mode stays at 2x, and the 10% regional data-residency uplift applies on top — the long-context multiplier compounds independently with each. The batch-pricing lane halves the long-context rate the same way it halves the short one; it does not remove the cliff.

Most coverage we reviewed while researching this post reports one vendor’s threshold in isolation, which is exactly how the pattern stays invisible. Lined up side by side, the vendor docs show three distinct multiplier shapes: OpenAI and Google share 2x input / 1.5x output, xAI runs a uniform 2x on everything — input, cached input, and output — and Anthropic runs no threshold at all. The shapes are similar in mechanism but not identical in ratio; conflating Grok’s 2x output multiplier with OpenAI’s 1.5x would overstate or understate a budget by real money at scale.

The table below assembles every documented threshold from the vendors’ own pricing and model pages. Two cells need flags. The GPT-5.6 Luna row is inferred from OpenAI’s shared short-context / long-context pricing table — the 272K sentence is verbatim on the Sol and Terra model pages, but Luna’s own page was not independently confirmed. And Google’s tier is phrased as a per-request bracket (prompts up to 200K versus above 200K), which is consistent with whole-request billing, but unlike OpenAI and xAI, we found no explicit sentence in the fetched Gemini API pricing pages stating the higher rate applies to the entire request.

Reading the footnotes: † the Luna threshold and rates are inferred from OpenAI’s shared short/long pricing table; the verbatim 272K sentence was confirmed on the Sol and Terra model pages only. ‡ Google’s pricing table brackets prompts at 200K in the wording it has used since earlier Gemini generations — consistent with whole-request billing, but without the explicit full-request sentence OpenAI and xAI publish. All rates are standard-tier, per million tokens, from the vendors’ live pricing pages at the time of writing. For raw window sizes across the wider field, see our context-window comparison across every frontier model.

One more OpenAI detail worth knowing: cache writes bill at 1.25x the uncached input rate of whichever tier applies. On Terra that is $2.50 per million short-context but $5.00 per million once the request is long-context — the write premium compounds on top of the doubled base, a detail that matters for agent frameworks that re-write large prefixes.

Anthropic is the one major vendor in this comparison with no long-context premium of any kind. This is not an omission in its context-windows documentation — it is stated policy, twice, in unusually plain language.

The models carrying the full 1M-token window at flat pricing, per the same page: Claude Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6, Fable 5, Mythos 5, and Mythos Preview. Claude Sonnet 4.5 and Haiku 4.5 remain capped at a 200K window — they have no long-context tier because they physically cannot exceed 200K, which is a different thing from a cliff.

This asymmetry has a practical consequence that is easy to state and easy to forget: on Anthropic, trimming context is a quality argument, not a cost argument. Retrieval quality can still degrade at extreme lengths, so keeping prompts tight remains good engineering — but the billing meter does not care. On OpenAI, xAI, and Google, the same trim is a direct line item. Conflating the two arguments leads teams to over-invest in retrieval infrastructure for Anthropic workloads and under-invest for the vendors where the cliff is real. Our break-even math for 1M-context workloads covers the Claude-specific side of that decision.

One adjacent data point, scoped to exactly what we checked: the Kimi K3 pricing page presents K3 as a single flagship-tier product with a 1M-token context and no second context-length pricing row visible in the page structure — consistent with flat pricing. Its per-token dollar figures render client-side and were not re-verified in this pass, so we print none of them.

The marketing number for these models is the context window — 1M tokens, 500K tokens. The budgeting number is the headline per-million rate. What the cliff does is quietly decouple the two: the headline rate only applies while the prompt stays under the threshold, which on the vendors with cliffs is a minority share of the advertised window. Computed from each vendor’s own window and threshold: Gemini 3.1 Pro Preview’s $2.00 input rate covers 200,000 of 1,048,576 tokens — 19% of the window. GPT-5.6 Terra and Sol’s headline rates cover 272,000 of 1,050,000 tokens — 26%. Grok 4.6’s covers 200,000 of 500,000 — 40%. Everything beyond those lines lives on the repriced tier.

This is the chart to keep in mind when reading the context-window arms race coverage: as advertised windows grow faster than thresholds move, the fraction of the window that the headline rate actually covers shrinks. A vendor can double its context window without touching its pricing page and, if the threshold stays put, the marketing number improves while the effective economics of using the new headroom get worse relative to the headline. Watching the threshold, not the window, is the procurement-grade habit.

Two worked examples, computed from the standard-tier rates in the table above. Take GPT-5.6 Terra, with a 300,000-token prompt and 5,000 output tokens. Stuffed — sent as one over-threshold request — the whole request bills long-context: 300,000 tokens at $4.00 per million is $1.20, plus 5,000 output tokens at $18.00 per million is $0.09, for $1.29. Trim the same task to 250,000 tokens with retrieval, and it bills short-context: 250,000 at $2.00 per million is $0.50, plus 5,000 at $12.00 per million is $0.06, for $0.56. Same task, $0.73 cheaper per request — a 56.6% saving, and the stuffed version costs 130% more than the trimmed one.

Grok 4.6, same exercise: a 250,000-token prompt with 10,000 output tokens bills $1.00 input plus $0.12 output long-context — $1.12. Trimmed to 190,000 tokens, it bills $0.38 plus $0.06 short-context — $0.44. That is $0.68 saved, or 60.7% — and note the output line doubled too, because Grok’s output multiplier is 2x, not OpenAI’s 1.5x.

The general form is worth having on hand. With short-context rates Cs_in and Cs_out, input multiplier r, output multiplier s, a stuffed prompt of P tokens, a trimmed prompt of P' tokens, and O output tokens, splitting beats stuffing whenever your per-request retrieval overhead E satisfies:

E < Cs_in × (r×P − P') + Cs_out × O × (s − 1)

Plugging the Terra example in: $2.00/M × (2 × 300,000 − 250,000) plus $12.00/M × 5,000 × 0.5 = $0.70 + $0.03 = $0.73 of headroom per request. Any retrieval or compaction infrastructure that costs less than that per request pays for itself immediately — which is most of them, at any reasonable volume. That formula is the honest version of the abstract advice to avoid the cliff: it tells you exactly how much engineering spend the avoidance is worth.

The tempting mitigation is prompt caching: if the big prefix is cached, surely the cliff stops mattering. The vendor rate cards say otherwise. On OpenAI, cached-input reads keep their 90% discount off whichever tier applies — $0.20 per million on a short-context Terra request, $0.40 per million once the request is long-context. On xAI the shape is the same: $0.50 short, $1.00 long, an exact 2x matching the input multiplier. A cache hit on an over-threshold request bills at the elevated cached rate, every time.

On Anthropic this whole section is moot — with no cliff, caching discounts apply uniformly regardless of prompt length, which is one more way the no-cliff design simplifies cost modeling. For the mechanics of structuring prefixes so they actually hit cache, see our guide to prompt caching mechanics. And remember the write side on OpenAI: cache writes at 1.25x the tier’s uncached input rate mean an agent framework that re-writes a 300K-token prefix pays the long-context write premium of $5.00 per million on Terra — double the $2.50 short-context write rate — before it has answered a single question.

The mitigations below are ordered by leverage. None of them requires switching vendors; all of them require knowing your prompt size before you send it — which is the real discipline shift, because most stacks today discover token counts on the invoice.

Projecting forward: thresholds are schedule terms, and schedules move. Google’s bracket has now outlived several model generations, and xAI applies the same rule to its grok-build-0.1 coding model as well as to Grok 4.6 — so the pattern is stable enough to build against, but none of it is contractual. Treat the threshold like any other price term your vendor can change: know what notice your AI vendor owes you before a price change, and keep the routing layer flexible enough that a moved threshold is a config edit, not a re-architecture. Teams that want the cliff map, token-measurement layer, and routing rules built into their stack — rather than rediscovered on an invoice — can lean on our AI transformation engagements, which start with exactly this kind of cost-surface audit. For the launch-day context on xAI’s pricing decisions, see Grok 4.6’s launch pricing.