The context window is not the number that should drive your architecture. The threshold inside it is.
GPT-6 Astra ships with a 1,050,000-token context window. That number gets the headline, and it is the wrong number to design against.
The one that will actually show up on your invoice is 272,000. Cross it on input, and the entire request reprices, not just the tokens above the line. Input doubles. Output goes up by half. Cached input doubles too.
If you are building agents that accumulate context as they work, and most useful agents do exactly that, this is the most important thing to know about the model.
Per million tokens:
| Standard | Above 272K input | |
|---|---|---|
| Input | $10 | $20 |
| Output | $50 | $75 |
| Cached input | $1 | $2 |
| Cache writes | $12.50 | $25 |
And the service tiers, at standard context:
| Tier | Input | Output |
|---|---|---|
| Batch | $5 | $25 |
| Flex | $5 | $25 |
| Fast | $20 | $100 |
Fast mode runs roughly 2.5 times quicker for double the price, and is not available with EU data residency.
One warning about secondary sources. Early coverage of this model reported $5 and $25 as the standard rates. Those are the batch and flex rates, which are half price. If you budgeted from a summary rather than the pricing table, you may be planning at half the real cost. We nearly published that error ourselves.
Most people read a threshold and mentally model it as a tax on the overage. That is not what happens here.
Send 271,000 input tokens and you pay $10 per million across the request. Send 273,000 and you pay $20 per million across the whole request, not on the 1,000 tokens that crossed the line. The 2,000-token difference in what you sent roughly doubles the input cost of the call.
That discontinuity has a specific and unpleasant shape for agents. An agent's context grows monotonically through a session: it reads a file, gets a tool result, appends an observation. The cost per step is flat, flat, flat, and then one step doubles it, and every subsequent step in that session stays doubled.
The result is a cost profile that looks fine in testing on small inputs and surprises you in production on large ones, which is the worst possible time to discover it.
Treat 272,000 as a design constraint, not a limit to use. The window is a million tokens. Your operating budget is 272,000. Anything above that is a deliberate decision you make for a specific request, not somewhere you drift into.
Instrument the input size, not just the bill. Log input tokens per call and alert on approach to the threshold, not on crossing it. By the time the invoice tells you, the session is over.
Summarise before you cross, not after. The moment a session is heading for the threshold is the moment to compact context. Compacting at 400,000 tokens saves you nothing on the request that already crossed.
Push the big reads out of the main context. Retrieval exists for this. If an agent needs to consult a large corpus, retrieve the relevant slice rather than loading the corpus. This is old advice that the million-token window made people feel they could ignore, and the pricing quietly reinstates it.
Use caching deliberately. At $1 per million, cached input is a tenth the price of fresh input, and cache writes cost $12.50, more than fresh input. That asymmetry means caching pays when a prefix is reused several times and costs you money when it is not. Cache the stable system preamble, not the volatile tail.
Move anything latency-tolerant to batch. Half price is half price. Overnight evaluation runs, bulk classification, and backfills have no business paying interactive rates.
That is a different question from "is it better," and the answer depends on what you are doing.
The quality case is real. On hallucination, Astra scores 4.2% against 12.2% for GPT-5.6 Sol, which is a substantial reduction in the failure mode that costs you the most trust. On coding it reports 57.9% on Terminal-Bench 4.0 and 74.1% on DeepSWE v1.1. On long-context retrieval it reports 96.3% on OpenAI's MRCR evaluation in the 512K to 1M range, which is the relevant claim if you intend to use the upper half of that window at all.
The case against is the cost curve, not the sticker price. Sticker prices are easy to compare. What is hard is that agentic workloads consume tokens in a pattern that interacts badly with a repricing threshold, and that interaction is invisible until you are past it.
It is worth noting that the industry is moving in two directions at once here. Anthropic cut cache reads to $0.25 per million with Fable 5.1, a 75% reduction aimed squarely at long agent sessions. OpenAI's structure prices the long tail up instead. Neither is wrong; they are different bets about where agent workloads concentrate. If your workload is long sessions over a stable corpus, that difference is worth modelling rather than assuming.
Working out what an agent workload will actually cost? Get in touch.
This article is a live example of the AI-enabled content workflow we build for clients.
| Stage | Who | What |
|---|---|---|
| Direction | Tom Hundley | Set the angle: a budgeting guide, not a launch write-up |
| Research | Claude Opus 5 | Pricing taken from the provider's model documentation and corroborated against independent pricing trackers before any figure was used |
| Drafting | Claude Opus 5 | Written on the Claude subscription in an interactive session |
| Fact-Check | Human + AI | Every dollar figure confirmed by at least two sources that do not share a source; one claim was dropped entirely for failing that test |
| Editorial | Tom Hundley | Final review for accuracy, tone, and value |
What we dropped and why. An early source described asynchronous tool calls as a headline capability of this model. Two subsequent checks, including the provider's own model documentation, did not mention the feature. Rather than describe something we could not confirm, we left it out. Similarly, the first pricing figure we encountered was half the real rate, because it quoted the batch tier; that is why every number here was checked twice before publication. We apply the same rule to client work, and it is the reason we are comfortable publishing numbers at all.
Want to build this capability for your team? Let's talk about AI enablement →
Discover more content:
