The 272K Token Cliff: How One Extra Token Doubles Your GPT-6 Astra Bill

GPT-6 Astra advertises a 1,050,000-token context window. What is much less advertised is that crossing <strong>272,000 input tokens</strong> reprices the entire request &mdash; input at 2&times;, cached input at 2&times;, and output at 1.5&times;. Not the tokens above the line. The whole call. That puts a doubling threshold at roughly a quarter of the window the model is sold on, and it is the single easiest way to be surprised by an Astra invoice.

The wording on OpenAI's own model page is unambiguous: prompts with more than 272K input tokens are priced at 2&times; input and cache rates and 1.5&times; output <em>for the full request</em>.

That last clause is the whole story. Most tiered pricing charges the higher rate only on the portion above a threshold, the way income tax brackets work. This does not. It is a cliff, not a slope, and the entire request falls off it.

• ▸<strong>Below 272K input tokens:</strong> $10 per million input, $1 per million cached input, $50 per million output.
• ▸<strong>Above 272K input tokens:</strong> $20 per million input, $2 per million cached input, $75 per million output.
• ▸<strong>Applies to:</strong> the entire request, including every token below the threshold.
• ▸<strong>Triggered by:</strong> input tokens only &mdash; output length does not move you across the line, though it is billed at the higher rate once you have crossed.

Take two requests that differ by two thousand input tokens, each generating 5,000 output tokens.

Request A - 271,000 input tokens, 5,000 output
  input   271,000 x $10/1M   = $2.71
  output    5,000 x $50/1M   = $0.25
  total                      = $2.96

Request B - 273,000 input tokens, 5,000 output
  input   273,000 x $20/1M   = $5.46
  output    5,000 x $75/1M   = $0.375
  total                      = $5.84

0.7% more input  ->  97% more cost

A request 0.7% larger costs 97% more. There is no gradual approach to this: the marginal cost of the token that crosses the threshold is, in effect, the entire bill again.

Most coverage of this rule mentions input and output and stops there. The cache rate doubles too, from $1 to $2 per million, and on agentic workloads that is often the line item that dominates.

Consider an agent that carries a 300,000-token context, of which 90% is a stable cached prefix, and generates 5,000 tokens per turn. Every single turn is above the threshold. The cached prefix bills at $2 per million instead of $1, the fresh input at $20 instead of $10, and the output at $75 instead of $50. That agent is paying the penalty on every turn it ever takes, and prompt caching &mdash; normally the strongest cost lever available &mdash; is itself running at double rate.

The uncomfortable implication is that the workload most likely to sit permanently above 272K is exactly the long-running agent that Astra is marketed for.

Filling Astra's full window once costs about $10 of input at the base rate. In practice it costs about $20, because any request that large is above the threshold by a factor of nearly four.

So the honest way to describe the pricing is that Astra has two prices: one below 272K and another, double, above it. The advertised 1.05M window is real and the retrieval quality up there is genuinely strong &mdash; 96.3% on OpenAI's MRCR v2 8-needle test in the 512K&ndash;1M band &mdash; but the economically comfortable window is the first quarter of it.

For comparison, Claude Fable 5.1 lists at the same $10 and $50 with no equivalent threshold, and reads cached input at $0.25 per million rather than $1. On long-context work specifically that gap widens from parity to roughly fourfold. We cover that in <a href="/blog/gpt-6-astra-vs-fable-5-1">Astra against Fable 5.1</a>.

Plenty of workloads never approach 272,000 input tokens and can ignore this entirely. A rough guide to whether you are exposed.

• ▸<strong>Single-turn chat and short tasks:</strong> not exposed. A long prompt is a few thousand tokens; you are two orders of magnitude away.
• ▸<strong>Document analysis:</strong> possibly. 272,000 tokens is roughly 200,000 words, or about two full-length novels. A large PDF corpus reaches it; a single report does not.
• ▸<strong>Whole-repository code context:</strong> very likely. A mid-sized codebase pasted in full clears the threshold comfortably.
• ▸<strong>Long-running agents:</strong> almost certainly, eventually. Context accumulates turn by turn, and the crossing happens mid-session without any single action causing it.

The last case is the dangerous one, because nothing in the interface announces it. A session that started cheap becomes twice as expensive partway through and stays that way for every remaining turn.

• ▸<strong>Instrument your input token distribution.</strong> Not the average &mdash; the distribution. An average of 200K with a long tail means a meaningful share of your requests are being billed at double, and the average will never reveal it.
• ▸<strong>Set a hard budget below the threshold.</strong> Cap assembled context at something like 260,000 tokens and drop the least relevant material rather than crossing. A retrieval step that trims context is almost always cheaper than the penalty.
• ▸<strong>Split rather than stuff.</strong> Two 200K requests cost $4 of input. One 400K request costs $8. If the task decomposes at all, decomposing it halves the input bill.
• ▸<strong>Watch conversation growth.</strong> Agent loops accumulate context. A conversation that starts at 150K and grows will silently cross the line partway through a session and stay there, doubling every subsequent turn.

Sometimes the threshold is worth paying. If a task genuinely requires half a million tokens of context in one pass, splitting it may cost more in failed reasoning than the repricing costs in dollars, and Astra's long-context retrieval is strong enough that the capability is real rather than nominal.

The point is not to avoid long context. It is to cross the line deliberately, knowing that the request just became roughly twice as expensive, rather than discovering it at the end of the month. A pricing cliff you have chosen is a trade-off; one you have not noticed is a budget problem.

Suppose an agent runs 500 times a month, and its context has grown such that 40% of runs sit above the threshold. Each run consumes 250,000 input tokens below the line or 320,000 above it, plus 8,000 output tokens.

300 runs below the line
  250,000 x $10/1M x 300  = $750.00
    8,000 x $50/1M x 300  = $120.00
                            $870.00

200 runs above the line
  320,000 x $20/1M x 200  = $1,280.00
    8,000 x $75/1M x 200  = $120.00
                            $1,400.00

Monthly total               $2,270.00
If all 500 runs stayed under 272K:  ~$1,480
Cost of crossing on 40% of runs:      ~$790

Roughly $790 a month, or $9,500 a year, for a context overrun on two runs in five. That is the kind of number that never appears in a model comparison and routinely appears on an invoice.

Threshold pricing is becoming common and it is rarely prominent in launch coverage. Batch processing on Astra runs at 50% of standard rates, and fast mode at 2&times; applicable rates &mdash; both of which compound with the 272K rule rather than replacing it. A fast-mode request above the threshold is paying two multipliers at once.

If you take one habit from this, make it reading the pricing page past the headline table. The numbers that determine a real bill are increasingly in the footnotes, and this one costs 97% on a 0.7% change in input size.

And for the substantial share of work that does not need a 272,000-token context at all, an open-weight model on your own hardware has no thresholds, no per-token cost and no surprises. Our <a href="/models">Model Explorer</a> shows what your GPU can hold.