EU buyers pay 10% more for GPT-6 Astra and cannot buy the fast tier at any price — and on Azure they cannot buy Astra in Europe at all

Update (1 October 2026) — the same pattern reached the agent layer, with one revealing difference. This article’s finding was that an EU-resident Astra deployment cannot buy the fast service tier at any price. On 29 September OpenAI launched dots — always-on GPT-6 Astra agents with their own cloud computer — and Pro access excludes the EEA, Switzerland and the UK at launch with no dated rollout. The difference worth noting is that Business Premium reportedly gets dots across all supported ChatGPT regions, at roughly the same monthly outlay as a Pro subscription. So where Astra’s fast tier was unavailable to European buyers regardless of contract, the agent exclusion tracks plan type rather than geography — which makes it a procurement decision a European team can act on this week rather than a wall. Separately, the new Ultrafast tier now has a published API price and a consumer tier but still no published region list, so the question this article raised about speed tiers in the EU remains open for the newest one.

Update (9 October 2026) — the EU speed gap closed on every model except this one. On 8 October 2026 OpenAI shipped Ultrafast for GPT-6.1 Sol and stated it is available in all supported regions, including US and EU data residency; the same update added EU residency support to GPT-6.1 Sol Fast and GPT-6 Luna Fast. That resolves the open question above, but not in Astra’s favour: GPT-6 Astra Ultrafast supports US data residency and global processing only and does not support EU or other non-US regional processing endpoints. So the finding in this article still holds for the flagship — an EU-resident Astra deployment cannot escalate above Standard at any price — while the mid-tier and small models now can, at $12/$60 and a 2x Fast multiplier respectively. The practical effect is to turn the restriction this article described into a model-selection rule rather than a dead end: in Europe, latency is now something you buy on Sol, not on Astra.

Update (9 October 2026) — the Azure half of this article has been resolved, and the price is worse than the estimates. Microsoft shipped GPT-6 Astra, Sol and Luna to the Foundry EU Data Zone on 22 September 2026, on Standard and Provisioned deployments. The availability gap this article described on Azure is closed. Two caveats survive it: Priority Processing is still Global and US Data Zone only, so the capability restriction simply moved platforms; and the EU Data Zone now carries a 20% premium over Global rather than the 10% the US zone carries, which is the high end of the 9–20% range this article told readers to treat as an estimate. The full per-model, per-tier picture is in our buyer’s guide to which AI APIs you can actually buy with EU data residency.

OpenAI’s GPT-6 Astra launched on 3 September with a benchmark table, a 2.5x price increase and an argument about why tokens are the wrong unit. The arithmetic in that argument is worth its own reckoning. This is a different problem, and it is not in the launch post at all.

It is in the model guide, in one sentence:

“GPT-6 Astra does not support service_tier: "fast" or service_tier: "priority" with EU data residency.”

That is not a price. It is a product boundary. And it means the Astra a European buyer can procure is a materially different product from the one on the launch chart — slower at the tail, with no escalation path, and about 10% more expensive for the privilege.

Three clouds, one number, and then a discontinuity

Start with what is genuinely settled, because it is the good news.

The cost of keeping inference inside a jurisdiction has converged. AWS put a public figure on it in August when Grok 4.6 arrived on Bedrock with a 10% data-residency premium. OpenAI’s pricing page states that regional processing endpoints carry a 10% uplift for models released on or after 5 March 2026. Microsoft’s own Astra listing prices the US Data Zone at precisely 10% over Global.

Three vendors arrived independently at the same surcharge. That is a market forming a price, and for anyone budgeting a regulated deployment it is a real improvement over the era when residency was a bespoke line in an enterprise contract.

Then look at the bold rows. Those are not prices. They are the absence of a price, and no amount of budget converts them into one. One of the two has since been converted — Microsoft opened the EU Data Zone for Astra on 22 September, at a 20% premium rather than 10%. The OpenAI fast-tier row has not.

A capability tier is not a discount you declined

The distinction that matters here is between paying more and being unable to pay.

Fast mode is OpenAI’s latency product. It is reachable as either service_tier: "fast" or service_tier: "priority", it is marketed as up to 2.5x faster with more consistent latency, and it costs exactly double the standard rate. For a US-resident Astra deployment, that is a lever: when p95 degrades and the product team starts filing tickets, an engineer can flip a parameter and pay $20/$100 instead of $10/$50.

For an EU-resident deployment, that lever is not connected to anything. The parameter is rejected. There is no premium SKU, no enterprise escalation, no “contact your account director” path that the docs point at — the model guide simply says to use Standard processing.

This is the first time residency has cost a capability rather than a percentage, and it deserves to be read as a category change rather than a footnote. Every residency decision until now could be modelled as a cost: pick the jurisdiction, add 10%, move on. Astra introduces a residency decision that has to be modelled as a capability ceiling, which is a different kind of entry in a risk register and a different conversation with a product owner.

It is also worth being precise about who is actually hurt. If your EU workload is queued — batch summarisation, overnight agent runs, document processing, anything where a human is not waiting — Standard is what you would have chosen anyway and this restriction costs you nothing at all. The exposure is concentrated in interactive surfaces: assistants, voice, human-in-the-loop review, anything where tail latency is the product. Those teams have just lost their only knob.

The tier you can buy stopped being a promise

There is a second regression sitting alongside the first, and it applies globally rather than only in Europe.

OpenAI’s fast mode guide is explicit that fast mode for GPT-6 Astra does not include a latency SLA. For GPT-5.6 and earlier, the same guide describes fast mode and Scale Tier as receiving the same service-level treatment, with eligible enterprise agreements able to earn service credits when latency targets were not met.

So the ladder has shortened at both ends. The contractual rung became best-effort for everyone, and the best-effort rung disappeared entirely for EU-resident traffic. A US team paying 2x for Astra fast mode is buying a marketing claim about speed, not a commitment about it — which is a materially weaker purchase than the same parameter bought against Sol last month.

This is the same pattern visible when Anthropic withdrew the priority tier that promised uptime rather than keep selling a commitment it was missing. Frontier capability and contractual reliability are drifting apart across the whole category, and the newest model is consistently the one with the fewest guarantees attached. Anyone who watched four providers wobble inside the same three-hour window on 3 September already knows what the guarantees were worth in practice; the change here is that they are no longer being offered.

On Azure, the gap is not a tier — it is the whole model

The OpenAI-direct situation is a degraded Astra. The Microsoft Foundry situation is no Astra.

Microsoft’s own launch blog lists Astra in Global and US Data Zone deployments. There is no EU Data Zone, no other regional option, and no published timeline for one. Independent analysis of the Foundry listing reaches the same conclusion in blunter terms: no paid Astra deployment currently guarantees processing within the EU data boundary. (This held for sixteen days. Microsoft opened the EU Data Zone for Astra, Sol and Luna on 22 September 2026 — Standard and Provisioned deployments, at a 20% premium over Global. Priority Processing remains Global and US-only.)

For a large number of European enterprises, Azure is the procurement path — the contracts are signed, the tenancy exists, security review has already run once. For those buyers, “GPT-6 Astra is generally available” is not true in any sense they can act on. It is available to a subsidiary in a different jurisdiction.

The pricing detail underneath makes the wait worse rather than better. Microsoft’s model deployment pricing update took effect on 1 September 2026 and applies its revised data zone premiums only to models launched on or after that date; customers who stay on their current models see no increase. Astra launched on 3 September. Whenever an EU zone arrives, it arrives priced under the new schedule — and Astra is the first flagship to sit on the wrong side of that line. Published estimates of the revised EU premium vary between roughly 9% and 20% across secondary coverage, and Microsoft has not posted Astra EU prices for the simple reason that there is nothing to price yet. Treat any specific figure circulating this week as an estimate, and plan the availability risk instead.

What this does to a model evaluation

The habit this should break is treating a model launch as a single event with a single date.

It is now a matrix. Jurisdiction × service tier × platform, and each cell has its own availability date, its own price and — as of this week — its own capability set. “GPT-6 Astra, GA, 3 September” describes exactly one cell of that matrix: global routing, US-resident, on OpenAI’s direct API. It is the cell the benchmarks were run in and the cell most launch coverage was written from. It may well not be the cell you deploy in.

That has a direct consequence for how benchmark tables should be read. Astra’s published results — the ones underpinning the split of frontier lineups into buyable and gated tiers — were produced without an EU residency constraint attached. That does not make them wrong; latency tier does not change model quality. It does make them incomplete as a procurement input for a team that will run the model on a tier the vendor benchmarked nothing on.

What to do about it

1. Classify the workload before you classify the model. Split EU traffic into latency-sensitive and queued. Only the first is affected. Teams that skip this step end up escalating a restriction that costs their actual workload nothing.
2. Re-run the price comparison at the tier you can actually buy. For EU-resident Astra that is Standard plus 10% — roughly $11/$55 short context. Compare that against Claude Fable 5.1, Gemini 3.8 Flash and the EU-domiciled alternatives on the same basis, not against Astra’s $10/$50 headline. Update, 8 September 2026: the EU-domiciled column now has a priced entry. Mistral — which closed a €3bn Series D the same week — sells EU-resident inference with a Priority Tier at 1.75x list and a 99.5% uptime SLA, making it the only vendor currently publishing an in-region latency-escalation path. The capability gap still favours Astra; the availability gap does not.
3. Check what your latency objective is written against. If an internal SLO or a customer commitment leans on OpenAI’s previous fast-mode service-level language, Astra does not inherit it. That is a document to update this week, not next quarter.
4. Put an Astra EU Data Zone date in the risk register, not the roadmap. On Azure there is no zone and no timeline. Anything that assumes one arrives before year end is an assumption, and it should be labelled as one. Resolved 22 September 2026: the zone shipped, at 20% over Global rather than the US zone’s 10%, with Priority Processing still excluded — so re-price rather than re-plan, and check the current residency matrix before signing.
5. Keep the routing layer between you and this. A gateway that can move EU traffic to a different provider without a code change is worth more this week than it was last week — the argument for neutral routing infrastructure has rarely been this concrete. Compare the shortlist properly: Claude against ChatGPT on residency terms, not just quality, and check the agent platforms you are building on for the same jurisdictional gaps.
6. Ask the vendor for the matrix in writing. Jurisdiction, tier, platform, date. If a sales team cannot fill that grid in, the answer to “is it GA in the EU” is no.

The bottom line

Nothing here is hidden. OpenAI documents the restriction in its model guide, prices the residency uplift on its pricing page, and states the missing SLA in its fast mode guide. Microsoft lists exactly two deployment types. Every fact in this piece comes from a vendor’s own documentation.

What none of them do is put it in the launch announcement. The 3 September changelog entry for Astra lists the model’s other constraints in detail — no none reasoning effort, no custom temperature or top_p, tool calling via the Responses API only — and says nothing about jurisdictions. It is the same silence that surrounds the three Responses API primitives shipped the same day, one of which decides whether an effort change costs $0.20 or $2.50 on a 200,000-token prefix. The EU AI Act transparency regime governs how AI output is disclosed to end users; it has nothing to say about whether a vendor’s launch post accurately describes where and how fast the model runs. That gap is a buyer’s problem to close, the same way the EEA consent-or-pay split on ChatGPT ads turned out to be.

So the honest summary of Astra’s first week in Europe is short. The surcharge is standard. The restriction is new. And the frontier model launch and the compliant frontier model launch are now two different events, separated by an interval nobody has announced.

Price the cell you will deploy in, not the one the benchmarks were run in.

Questions or corrections? Email Pick Right. Want the full list? See all news.