September 7, 2026 ·

openaipricingagentscodingapistrategy

OpenAI shipped three new Astra API primitives. Only one has money attached, and OpenAI's own Codex client does not use it

TL;DR: OpenAI’s API changelog for 3 September 2026 added three Responses API primitives alongside GPT-6 Astra: async function calling, mid-turn steering, and reasoning-effort changes that preserve the prompt cache. The first two are ergonomics. The third is a bill. Astra prices cached input at $1.00/MTok and cache writes at $12.50/MTok — so an effort change that invalidates a 200,000-token prefix costs $2.50 where a preserved one costs $0.20, a 12.5x spread on the most-repeated line in an agent session. The saving only lands if your harness appends a configuration_update item instead of changing request-level reasoning.effort. An open issue filed against OpenAI’s own Codex client on 5 September says Codex still does the latter. Meanwhile openclaw merged support for all three on 4 September. For buyers: the discount is real, it is not on by default, and it is not automatic in the vendor’s own tool.

Three primitives, one price tag

OpenAI’s developer changelog carries three entries dated 3 September 2026, shipped with GPT-6 Astra. OpenAI DevRel’s Nikunj Handa summarised them the same day as “cool new responses api features releasing today with astra.”

Async function calling. The model keeps working after issuing a tool call rather than blocking on the result. Your application still executes the tool — nothing moves to OpenAI’s side — and results come back in a later request matched by the original call_id. It is Astra-and-later only, applies to function and custom tools rather than hosted built-ins, and cannot be combined with parallel tool calls in multi-agent mode. The docs suggest an accompanying synchronous “wait tool” so the model can decide when it actually needs a pending result.

Mid-turn steering. You send a response.steer event carrying previous_response_id and new user input while a response is still running; the API acknowledges with response.steer.accepted and creates a continuation. It requires a WebSocket connection to the Responses API and is unavailable over plain HTTP. It does not rewrite output already sent or cancel in-flight tool calls, and it rejects further steers past a too_many_pending_steers threshold.

Reasoning-effort changes that keep the cache. You append an input item — {"type": "configuration_update", "reasoning": {"effort": "high"}} — while leaving request-level reasoning.effort alone. Because the request prefix is unchanged, the prompt cache still matches.

The first two make agents nicer to write. The third makes them cheaper to run, and by a margin most coverage of the launch did not print.

The number nobody printed

Astra’s price sheet has four input-side rates, not two:

Line item	GPT-6 Astra (≤272K)	GPT-6 Astra (>272K)	GPT-5.6 Sol (≤272K)
Input (uncached)	$10.00 / MTok	$20.00 / MTok	$4.00 / MTok
Cache write	$12.50 / MTok	$25.00 / MTok	$5.00 / MTok
Cache read	$1.00 / MTok	$2.00 / MTok	$0.40 / MTok
Output	$50.00 / MTok	$75.00 / MTok	$20.00 / MTok

Writing to cache costs 1.25x an uncached input token. Reading from it costs 0.1x. The ratio that matters is not the 10x discount everyone quotes on reads — it is the 12.5x gap between a write and a read, because that is the gap you pay every time a prefix is rebuilt instead of reused.

That gap is cheap to amortise once. Write a million tokens at $12.50 and read them back once at $1.00 and you have spent $13.50, against $20 for sending the same tokens twice uncached. Caching pays for itself on the first reuse. The trap is not the surcharge, it is repetition: a loop that rewrites its prefix every other turn is paying a 25% premium for a cache it barely uses.

Astra’s cache also has exactly one TTL — prompt_cache_options.ttl accepts "30m" and nothing else — and a 1,024-token minimum cacheable prefix. So a short prefix cannot be cached at all, and a sparse session rewrites at least every half hour regardless of what you do.

What one toggle costs

Take a coding agent carrying a 200,000-token stable prefix: tool schemas, system policy, resident repository context. Below the 272K line, so standard rates.

Preserved prefix: one read per turn, $0.20.
Rebuilt prefix: one write per turn, $2.50.

Now run a 40-turn session in which the harness raises effort for hard steps and drops it for routine follow-ups twelve times — precisely the pattern the feature exists to enable:

	Writes	Reads	Input-side cost
`configuration_update` (cache preserved)	1	39	$10.30
Request-level `reasoning.effort` (cache busted)	13	27	$37.90

Same work, same model, same output tokens. 3.7x the input bill, from a difference that is invisible in your prompts and surfaces only as an input-token line nobody can explain. Twenty engineers running a dozen toggles a day puts the gap somewhere near $550 a day. Push the prefix past 272,000 tokens and each rebuild is $7.50 rather than $2.50.

This is the same lesson Anthropic’s Fable 5.1 cache-read cut taught a week earlier from the other direction: frontier pricing is no longer a number you compare across a row, it is a structure, and vendors compete on the line item that suits their infrastructure rather than the one that dominates your bill.

Astra versus Fable 5.1, on the only line that differs

The two flagships are now priced identically on the headline numbers — $10 input, $50 output — and identically on the cheaper cache write at $12.50. They differ on one line and one duration:

	GPT-6 Astra	Claude Fable 5.1
Cache write	$12.50 / MTok (30-min TTL)	$12.50 (5-min) / $20 (1-hour)
Cache read	$1.00 / MTok	$0.25 / MTok

Astra’s write buys thirty minutes for what Anthropic charges for five. Anthropic’s read is four times cheaper. Let k be reads per write on that same 200,000-token prefix:

Astra: $2.50 + $0.20k
Fable 5.1 (1-hour cache): $4.00 + $0.05k

They cross at k = 10. Under ten reads per write, Astra’s input side is cheaper because you are buying residency, not re-reads. Above ten, Fable 5.1 wins and the lead widens, because a long session is overwhelmingly re-reads. Against Anthropic’s five-minute tier — roughly six writes to span half an hour — Astra stays ahead until about 83 reads.

That is a checkable rule you can apply to your own traffic today: count reads per write in the usage fields you are already being returned, and if the number is comfortably above ten, Astra’s cache is the expensive one no matter what the headline row says.

It is not on by default — including at OpenAI

Here is the part that turns a pricing note into a buying decision. On 5 September, an issue was filed against OpenAI’s own Codex client — openai/codex#42996 — reporting that changing the selected reasoning effort mid-session “changes the request-level reasoning configuration” instead of appending a positional configuration_update item to history. That is precisely the cache-busting path. The issue notes that PR #42328 already added durable ResponseItem::ConfigurationUpdate plumbing in early September, but the reasoning-settings code never wired into it, and it references two earlier reports (#35416 from 26 July, #32533) documenting empirical cache misses and WebSocket reuse failures when effort changes mid-session. At the time of writing the issue is open with no assignee and no linked fix.

The contrast is instructive. OpenClaw merged support for all three primitives — async tools, steering and cache-preserving effort updates — on 4 September, in a change carrying 439 tests across 21 files plus five authenticated live scenarios. Its published cache trace shows the mechanism working: zero cached tokens on the first request, then 3,979 cached tokens after a low-to-high effort change, then 4,007 after high-to-medium. The prefix survives the toggle.

So the primitive is a week old, it is worth multiples on the input side of an agent bill, and whether you get it depends entirely on which harness you run — not on which model you bought. That is a new axis for tool selection, and it is not on any of the comparison pages the vendors publish. If you evaluate coding agents or agent harnesses, “does it preserve the prompt cache across an effort change” now belongs on the checklist next to context window and model support, and it is the sort of thing you can only answer by reading usage fields, not marketing pages.

The portability bill

All three primitives are Responses API features, and all three are gated to gpt-6-astra or later. configuration_update additionally fails in pro and tournament multi-agent modes. Steering requires a WebSocket transport with no analogue at any other vendor. This lands on top of a migration Astra already forces, since tool calling with Astra requires the Responses API at all — Chat Completions users have to move.

The pattern should be familiar by now. It is the same shape as Coder’s Agent Relay keeping execution on-premises while the reasoning loop still leaves the building, and the same shape as OpenAI cutting Cursor’s model access on 12 November: the useful thing and the lock-in are the same object. A router or gateway layer of the kind Stripe, OpenRouter and Ramp have been building out can absorb some of this, but not steering, which needs a persistent socket the router would have to proxy.

What to do

Read your usage fields before anything else. Count cached-read tokens against cache-write tokens per session. If writes are a meaningful fraction of reads, something in your loop is invalidating the prefix — effort changes are one candidate, but so is any mutation ahead of the stable prefix.
If you toggle effort on Astra, use configuration_update. Leave request-level reasoning.effort fixed. Do not place two update items adjacent in history; the API rejects that.
Check your harness, not just your model. If you run Codex, track #42996 before you assume the saving applies to you. This is a live differentiator between Cursor, Claude Code, Codex and open harnesses, and it is worth more per month than most of the features those tools advertise against each other.
Cap your prefix below 272,000 tokens deliberately. Every rate on the input side doubles above the line, so a rebuild there costs $25 per million rather than $12.50.
Do the read-per-write arithmetic before choosing between Astra and Fable 5.1. Above roughly ten reads per write on a comparable prefix, Anthropic’s $0.25 read is the cheaper structure despite identical headline pricing.

The broader point is the one this desk keeps arriving at from different directions, including on Astra’s EU tiering and agent-fleet orchestration: the list price is now the least interesting number on a frontier model’s page. What you actually pay is decided by cache behaviour, threshold cliffs, and whether the client you happen to run implements a primitive that shipped four days ago. None of that is visible from the pricing table.

Update, 7 September 2026 — the volumes that make this worth caring about. The arithmetic above assumes an agent estate large enough for a 12.5x line item to matter. OpenAI has now published what that looks like at the frontier: as of mid-August its research organisation ran 3.1 agent-workdays per human workday, with the median researcher consuming more than $600 a day of inference at API prices — roughly $150,000 a year per head — and the 90th percentile past $7,000 a day. At $600 a day, the difference between a preserved and a rebuilt 200,000-token prefix is not a rounding error on a seat licence; it is the largest controllable term in the bill. This is the volume regime where cache behaviour stops being a technical footnote and becomes the procurement question. The per-head numbers.

Frequently asked questions

What actually changed on 3 September, in one paragraph?

OpenAI's API changelog added three Responses API capabilities alongside GPT-6 Astra. Async tool calling lets the model keep working while your application executes a function or custom tool, with results returned later against the original call_id; it is supported by Astra and later models, applies only to tools you run rather than hosted built-ins, and cannot be combined with parallel tool calls in multi-agent mode. Mid-turn steering lets you inject user instructions into a response that is still running, via a response.steer event over a WebSocket connection to the Responses API; it is Astra-only, unavailable over plain HTTP, and does not rewrite output already sent or cancel in-flight tool calls. The third is a configuration_update input item that changes reasoning effort mid-conversation while leaving request-level reasoning.effort untouched, so the cached prompt prefix survives. That third one is the only one of the three with a price directly attached to whether you use it.

Why is a cache write more expensive than a plain uncached input token?

Because you are paying for storage as well as processing. On GPT-6 Astra a fresh uncached input token costs $10 per million, a token written into the prompt cache costs $12.50 per million — a 25% surcharge — and a token read back out of cache costs $1.00 per million. Above the 272,000-token long-context threshold every rate doubles except output: input $20, cache writes $25, cache reads $2. The surcharge is trivially cheap to amortise: write once at $12.50 and read once at $1.00 and you have already spent $13.50 against $20 for sending the same tokens twice uncached, so caching pays back on the first reuse. The surcharge only hurts when you write repeatedly. A workload that rebuilds its prefix on every other turn is paying $12.50 per million tokens for a cache it barely reads, which is worse than not caching at all. GPT-5.6 Sol has the same structure at $4 input, $5 cache write and $0.40 cache read.

How much does a careless reasoning-effort toggle actually cost?

It costs the difference between a cache read and a cache write on your entire stable prefix, every time you do it. On a 200,000-token prefix — tool definitions, system policy, repository context, the sort of thing a coding agent carries — a preserved turn reads that prefix for $0.20 and a busted turn rewrites it for $2.50. That is 12.5x, and it recurs. Model a 40-turn agent session where the harness raises effort for hard steps and lowers it for routine ones twelve times: preserving the cache costs one write and thirty-nine reads, about $10.30 on the input side; rebuilding on each toggle costs thirteen writes and twenty-seven reads, about $37.90. Same work, 3.7x the input bill. Scale that to twenty engineers running a dozen toggles a day and the gap is in the region of $550 a day, which is real money for a difference that is invisible in your code and shows up only as an unexplained input-token line. Cross the 272K threshold and each rebuild is $7.50 rather than $2.50 on a 300,000-token prefix.

Is Astra's caching cheaper or dearer than Claude Fable 5.1's?

It depends entirely on how many times you read each cache write, and the crossover is computable. Astra and Fable 5.1 have identical headline pricing — $10 per million input, $50 per million output — and identical five-minute-equivalent cache write pricing at $12.50. They differ on exactly one line: Astra reads cached tokens at $1.00 per million, Fable 5.1 reads them at $0.25. Astra's cache has a single 30-minute TTL; Anthropic sells a five-minute tier at $12.50 and a one-hour tier at $20. Take a 200,000-token prefix and let k be the number of reads per write. Astra costs $2.50 + $0.20k. Fable 5.1 on the one-hour cache costs $4.00 + $0.05k. They are equal at k = 10. Below ten reads per write Astra's input side is cheaper because its write buys thirty minutes for the price of Anthropic's five; above ten reads Fable 5.1 wins and keeps winning, because the read is where a long session spends its money. Against Anthropic's five-minute tier, which needs roughly six writes to span half an hour, Astra stays ahead until about eighty-three reads.

Should we adopt these primitives, given they are OpenAI-only?

Adopt the cache behaviour, be deliberate about the rest. All three are Responses API features, all three are gated to gpt-6-astra or later, configuration_update additionally does not work in pro or tournament multi-agent modes, and steering requires a WebSocket transport that has no equivalent at any other vendor. That is a genuine portability cost on top of the migration Astra already forces, since tool calling with Astra requires the Responses API at all. The pragmatic split is that cache-preserving effort changes are worth wiring in now because the saving is large, mechanical and needs about ten lines of harness code; async tool calling is worth it if your agent genuinely waits on slow I/O; and mid-turn steering is the one to hold, because a WebSocket-only, single-vendor control channel is a lot of architecture to take on for an ergonomic win. If you route across providers, keep all three behind your own abstraction or a gateway rather than letting them shape your agent loop, or you will find the loop only runs on one model.

Sources

Related tool reviews

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