What you need to know
OpenAI released GPT-6 Astra on 3 September 2026, exposed in the API as gpt-6-astra, with a context window of 1,050,000 tokens and a maximum output of 128,000 tokens per response. AWS announced general availability on Amazon Bedrock on 8 September, and Microsoft's Foundry catalogue lists the model as well, so for most teams in India and the UK the model is reachable through whichever cloud contract they already have.
The number everyone has written down is $10 per million input tokens and $50 per million output tokens. That number is correct and it is also, for a meaningful share of real workloads, not the number that will appear on the invoice. OpenAI's model documentation carries a second clause underneath the rate card: "Prompts with more than 272K input tokens are priced at 2x input and cache rates and 1.5x output for the full request."
Read that last phrase slowly. For the full request. This is threshold pricing, not marginal pricing. It is not that the tokens above 272,000 cost double while the first 272,000 stay at the list rate. Once a single request crosses the line, every token in it — including the first one — is billed at the higher rate, and the output tokens come along for the ride at 1.5x. There is no tapering, no blended rate, no partial credit.
The model advertises a 1.05M-token window, but only the first 272K of it is priced at the headline rate. Roughly three-quarters of the advertised context sits on the expensive side of the line. If your capacity plan says "1M context at $10 per million", your capacity plan is wrong by up to 2x on input.
The rate card, both sides of the line
All figures below are per million tokens, drawn from OpenAI's published API docs for gpt-6-astra. The above-threshold column is the multiplier applied, not a separately published list — OpenAI states the multipliers rather than printing a second table, so treat the right-hand column as the arithmetic result of the stated rule.
| Rate | Request ≤ 272K input | Request > 272K input | Multiplier |
|---|---|---|---|
| Input | $10.00 | $20.00 | 2x |
| Cached input | $1.00 | $2.00 | 2x |
| Cache write | $12.50 | $25.00 | 2x |
| Output | $50.00 | $75.00 | 1.5x |
| Batch / Flex | 50% of the applicable Standard rate | 0.5x | |
| Fast mode | 2x the applicable rate | 2x | |
Two details in that table deserve attention. First, cache writes already cost 1.25x the uncached input rate — $12.50 against $10 — so warming a large cache is not free, and warming it with a prompt that itself exceeds 272K costs $25 per million. Second, Batch and Flex apply after the threshold, not instead of it: a 400K-token Batch request is half of $20, which is $10, not half of $10.
What a 5,000-token overshoot actually costs
Here is the cleanest way to see the cliff. Two requests, near-identical in size, one either side of the line. Output held constant at 8,000 tokens. Rupee and sterling conversions use roughly ₹96 and £0.75 to the dollar, the mid-market rates in the third week of September 2026; treat them as illustration, not as your finance team's booking rate.
| Request | Input tokens | Input cost | Output cost | Total | Approx. INR / GBP |
|---|---|---|---|---|---|
| Just under | 270,000 | $2.70 | $0.40 | $3.10 | ₹298 / £2.31 |
| Just over | 275,000 | $5.50 | $0.60 | $6.10 | ₹587 / £4.55 |
An extra 5,000 input tokens — 1.9% more context, perhaps one more file pasted into the prompt, or a tool result that came back longer than usual — raises the bill for that request by 97%. There is no workload shape in which that trade is worth making deliberately. The only reason it happens is that nobody instrumented for it.
The agent loop is where this bites
A single long document is easy to measure before you send it. An agent is not, because its context grows on its own while the run is in progress. Tool outputs accumulate, the assistant's own prior turns are replayed, retrieved chunks pile up, and nothing in the loop announces that it has just crossed a billing boundary.
Consider a coding agent working through a refactor. It starts with a 40,000-token working set — system prompt, repository map, the open files — and each turn adds roughly 9,000 tokens of tool output and assistant reasoning to the transcript that gets replayed on the next call. Output averages 1,500 tokens per turn. The run takes 30 turns.
Turn 27 is where the context reaches 274,000 tokens and the whole request reprices. The last four turns of that run are billed at $20 and $75 while the first twenty-six were billed at $10 and $50.
| Segment | Input tokens | Output tokens | Rate applied | Cost |
|---|---|---|---|---|
| Turns 1–26 (40K → 265K context) | 3,965,000 | 39,000 | $10 / $50 | $41.60 |
| Turns 27–30 (274K → 301K context) | 1,150,000 | 6,000 | $20 / $75 | $23.45 |
| Same four turns, compacted to 120K first | 534,000 | 6,000 | $10 / $50 | $5.64 |
The final 13% of the run accounts for 36% of its cost. Compacting the transcript once, at turn 26, takes those four turns from $23.45 to $5.64 — a saving of $17.81 on one session, or about ₹1,710 and £13.30. That is arithmetic from the published rate card applied to a modelled session, not a measurement from a production system; your growth rate per turn is the variable that matters most, and you should substitute your own.
Scale it the way a team actually spends. Twenty engineers, five agent sessions each per working day, twenty-two working days: 2,200 sessions a month. At $17.81 of avoidable overage per session that is roughly $39,000 a month, near enough ₹38 lakh or £29,000, thrown away on the far side of a line that a twenty-line guard would have kept you behind. The same maths is why we keep arguing that you should forecast your LLM bill before launch rather than after — threshold rules are exactly the sort of thing a spreadsheet catches and a dashboard does not.
Set your guard at 260,000 input tokens, not 272,000. Tokenisers disagree with your estimator, tool outputs vary in length, and the penalty for being 500 tokens wrong is a doubled bill for the entire request. A 12,000-token safety margin costs you almost nothing and removes the entire class of failure. This matters more for teams working in Indic scripts, where the same text costs substantially more tokens than its English equivalent.
How the threshold compares across providers
Long-context surcharges are not unique to OpenAI, but the three major providers have landed on three different structures — which means a multi-provider router has to encode three different rules, not one.
| Model | Long-context rule | Below the line | Above the line |
|---|---|---|---|
| GPT-6 Astra | > 272K input, whole request reprices | $10 / $50 | $20 / $75 |
| Gemini 3 Pro | > 200K prompt, all tokens at long-context rate | $2 / $12 | $4 / $18 |
| Claude Opus 5 | No long-context surcharge tier published | $5 / $25 | $5 / $25 |
Gemini figures are from Google's Gemini API pricing page; Claude figures are from Anthropic's published pricing page, which lists no separate long-context tier. The practical consequence for a router is that Astra's penalty is a step function you can plan around, Gemini's is a lower step at a lower threshold, and Anthropic's absence of one makes it the predictable option for workloads whose context size you genuinely cannot bound. If you are building that routing layer, our guide to model routing and cascades covers the escalation logic; the threshold simply becomes another input to the routing decision alongside quality and latency.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →Four architectural responses
1. Prune and compact before the boundary, not after
The cheapest fix is a ceiling in the loop. Estimate the input size before each call; if it would exceed your guard, compact the transcript — summarise completed sub-tasks, drop superseded tool outputs, collapse file contents you have already edited — and continue. The technique is well understood; what changes under threshold pricing is the trigger. You are no longer compacting when the window fills, you are compacting when the price is about to double, and those are different numbers. Our walkthrough of compaction for long-running agents has the mechanics.
2. Shard the task into sub-272K requests
Many jobs that look like one enormous prompt are several medium ones with a join at the end. A 600,000-token document review can run as three 200,000-token passes plus a short synthesis call. Three requests at $10 per million beat one at $20 per million even before you count the smaller output. The cases where sharding genuinely fails are those needing global cross-reference across the whole corpus in a single reasoning step — real, but rarer than the instinct to paste everything suggests.
3. Retrieve instead of stuffing
The 1M-token window made "just put the whole corpus in the prompt" a legitimate architecture, and for some workloads it still is. Threshold pricing moves the break-even point sharply back towards retrieval. A retrieval pipeline that keeps prompts at 60,000 tokens is now competing against an effective $20 per million, not $10, and it wins far more often. The decision is workload-specific, and we have set out the trade-offs in long-context versus RAG.
4. Use Batch and Flex for anything that can wait
Batch and Flex are 50% of the applicable Standard rate. Nightly document processing, evaluation sweeps, backfills and content pipelines have no business paying interactive rates. This stacks with everything above: a sharded, retrieval-fed, sub-272K Batch job pays $5 per million input against the $20 an unbounded interactive request would have. Our Batch API playbook covers the queueing and failure-handling side, which is where these migrations usually stall.
Caching sits alongside all four rather than instead of them. Cached input at $1 per million is a tenfold discount on the uncached rate, which is the single largest lever on the rate card — but note that it doubles to $2 above the threshold like everything else, so caching reduces the penalty without removing it. If your cache strategy is still ad hoc, our prompt caching guide covers the cross-provider differences, and they are substantial.
What to do this week
Three things, in order. Instrument first: log input token counts per request and plot the distribution. Most teams discover a long tail sitting just above 272,000 that nobody knew was there. Then guard: a hard ceiling at 260,000 with compaction or sharding behind it, and an alert every time it fires. Then re-forecast: rebuild your cost model with two rates rather than one, and check whether the workloads on the wrong side of the line should be on Batch, on retrieval, or on a different model entirely.
None of this is difficult. It is simply the kind of thing that stays invisible until an invoice arrives, and a doubled invoice is a poor way to learn that a rate card had a second paragraph.
Primary sources: OpenAI's model documentation at developers.openai.com, the Bedrock availability announcement at aws.amazon.com, Google's rates at ai.google.dev and Anthropic's at claude.com/pricing.