GPT-6 Astra on Bedrock: the endpoint decides what you audit

The model card is more informative than the announcement. openai.gpt-6-astra has a 1,050,000-token input window, a 128,000-token output ceiling and an April 30, 2026 knowledge cutoff. Input accepts text and image; output is text only — anyone expecting image or audio generation from the same model ID will hit a wall. EOL no sooner than September 8, 2027, with a legacy period of at least 6 months: that is a one-year contractual floor for planning migration, and it is the kind of fact that belongs in your ADR, not in your slide.

The API surface is smaller than it looks. On bedrock-runtime, the model answers on Converse, Responses and Chat Completions — and not on InvokeModel. If your internal wrapper standardized everything on InvokeModel to get a single instrumentation point, it does not call Astra. On bedrock-mantle, only Responses and Chat Completions, served at /openai/v1/responses and /openai/v1/chat/completions.

One service tier. Standard only. Priority, Flex and Reserved are all listed as unsupported. There is no reserved throughput to hold peak latency, and no Flex tier to soften an overnight batch. Your whole workload shares the same pay-per-token queue, and your only control over tail latency is which Region you pick.

Astra's pricing is not a pair of numbers; it is a two-dimensional matrix, and both dimensions are architectural decisions.

Dimension 1 — the inference profile. Global CRIS costs US$ 10.00 per 1M input tokens and US$ 50.00 per 1M output. In-Region and Geo CRIS cost US$ 11.00 and US$ 55.00. You pay 10% more precisely to gain control over where inference happens. That is the explicit price of residency, and it is cheap next to a fine.

Dimension 2 — the 272K cut. Above 272,000 input tokens, the entire request reprices: US$ 20.00 input and US$ 75.00 output on global, US$ 22.00 and US$ 82.50 in-Region. It is not the overflow that changes tier — it is everything. A 280,000-token prompt on global costs US$ 5.60 of input; the same prompt trimmed to 270,000 costs US$ 2.70. A 3.7% difference in size becomes 107% on the invoice.

And you do not get CountTokens. The bedrock-runtime feature list marks CountTokens and structured outputs as unsupported for this model. So: there is a price cliff at 272,000 tokens and no official API to learn which side of it your payload landed on before you send. Counting has to happen in your code, with the right tokenizer and a safety margin — and the ceiling has to be a parameter, not a number buried inside a function.

Quota is a third currency. The burndown is 10x: 1 output token consumes 10 TPM units. A run that emits the full 128,000-token ceiling burns 1,280,000 units — 4.7 times what reading 272,000 input tokens costs you in quota. In an agent, output is the scarce resource, not context.

Prompt caching for OpenAI models on Bedrock is not the same mechanism as for Claude. There is no cachePoint in Converse: you mark "prompt_cache_breakpoint": {"mode": "explicit"} on a Responses API content block, with a 1,024-token minimum prefix and up to 4 breakpoints. prompt_cache_options.mode decides the behavior: implicit (the default) adds an automatic breakpoint on the latest message on top of yours; explicit disables the automatic one — and if you declare no breakpoint at all, the request simply does not use caching and incurs no write charge. Minimum 30-minute TTL, controlled by prompt_cache_options.ttl.

The savings are aggressive and break-even is immediate. A write costs 1.25x uncached input; a read costs 10% of it. Take a stable 40,000-token prefix — instructions, tool definitions, reference documents — running 30 calls inside the same 30-minute window on bedrock-mantle: without caching, 30 × 40,000 × US$ 11.00/1M = US$ 13.20. With caching, US$ 0.55 of write plus 29 reads at US$ 0.044 = US$ 1.83. An 86% drop, and the second call already paid for the write.

One more detail changes capacity planning: tokens read from cache do not count against the input-tokens-per-minute quota. Caching here is not only a discount — it is headroom.

The problem is where it lives. For Astra, the model card lists Implicit and Explicit Prompt Caching only on bedrock-mantle, through the Responses API. And bedrock-mantle for Astra exists only in us-west-2, with no geographic profile and no global profile.

Here the analysis stops being about cost. The Responses API is stateful by default: with store set to true — the default, to match the OpenAI specification — Bedrock retains the request and the response for 30 days so previous_response_id works. And the documentation is blunt about where: the response lives in the Region that served the request. With a global profile, that is any commercial Region the profile routed to.

Translating for anyone operating under BACEN and LGPD: in sa-east-1, Astra exists only through the global profile. No in-Region, no Geo. A team in São Paulo calling Astra is accepting worldwide routing and, by default, 30-day retention of input and output outside the country. The geographic path us.openai.gpt-6-astra covers five Regions — us-east-1, us-east-2, us-west-1, us-west-2 and ca-central-1 — and none of them is Brazil. There is no national residency path for this model today. The mitigation is store explicitly set to false on every request, or the account retention mode set to none, which rejects store=true outright. But zero retention costs you stateful multi-turn conversation — which is exactly why many teams moved to the Responses API.

And there is an IAM trap. The two endpoints authorize actions from different namespaces: bedrock:InvokeModel on one side, bedrock-mantle:CreateInference on the other. An SCP written as "Action": "bedrock:" to restrict which models the organization may invoke simply does not match bedrock-mantle:. Add the condition-key behavior: bedrock:ModelArn is valued at the profile the request named — never the destination models CRIS routed to. You cannot constrain the processing Region by policy on the target; you constrain it only by picking the right profile.