GPT-6 Astra changes what happens after you press Run

A user presses Run, sees the first result, and changes the brief. GPT-6 Astra's mid-turn steering gives applications a documented way to handle that moment. The details matter: accepting the correction and acting on it are different events.

OpenAI's September 3, 2026 API release introduced GPT-6 Astra, with the model ID gpt-6-astra. It is a separate release from GPT-5.6 Sol, Terra, and Luna. The standard API rate is $10 per million input tokens and $50 per million output tokens for prompts of up to 272K input tokens. The model page lists a 1,050,000-token context window and 128,000-token maximum output.

Mid-turn steering makes a correction part of the workflow

GPT-6 Astra supports steering over a WebSocket connection to the Responses API. GPT-5.6 and earlier models do not support this feature. The application sends a user update after the response has started, and the service carries it into a continuation.

That creates an important distinction for an interface. A status such as “Change received” means something different from “Working from the revised brief.” OpenAI's steering guide explicitly says that acceptance only queues the input. It does not confirm that the model has already incorporated it.

1. The response starts. After response.created, the client can send response.steer with the response ID and the user's new instruction.
2. The update is accepted. response.steer.accepted confirms that the input is queued.
3. Existing work reaches the continuation point. The server finishes the current output item and hosted tool work already running. Required client tool results or approvals can keep steering pending.
4. A continuation uses the new instruction. The client keeps reading events and follows the successor response.

A correction cannot undo an action that already happened

Steering does not rewrite output already delivered, reverse earlier actions, or cancel tools that have started. That is the limitation a product should make easy to understand. If an application has already started an external operation, a later instruction is not a rollback mechanism.

Our recommendation is to track corrections and actions separately. A change to the brief can update future work; the application still needs its own rules for canceling a job or reversing a completed operation. The distinction also matters when the user sees partial output before the correction arrives.

“Incomplete” can be an expected handoff

If steering interrupts the original response, it can end with response.incomplete and the reason steered. That is a documented transition to the revised work. If the original response finishes normally first, it can still have a steering continuation.

An interface that treats every incomplete response as a generic failure would misrepresent this transition. Equally, stopping at the first completed response could hide the answer to the corrected brief. Follow the event sequence through to the appropriate continuation.

There is a budget implication, too: OpenAI documents that token and tool-call limits apply separately to each response. If your product promises a limit for the entire task, track it across continuations as well as within individual responses.

Async tool calling changes who is waiting

A normal function call pauses the model's turn until the tool response arrives. With async: true on a function or custom tool definition, Astra can continue independent work before the application returns that result.

OpenAI's async tool documentation is precise about responsibility: your application still executes the tool and manages the running job. When the result is ready, it is returned using the original call_id. Setting the flag does not create an OpenAI-hosted job queue for your software.

The useful design question is whether a piece of work genuinely depends on the missing result. Independent analysis can continue. A conclusion that needs a tool's data still has to wait for that data. Showing separate states for the ongoing response, pending tools, and queued user updates makes the workflow easier to follow.

That is why adopting Astra is more than changing a model name for an application that wants these controls. The runtime needs to retain task state across tool results and response continuations. Model intelligence cannot substitute for a result the application has never delivered.

GPT-6 Astra pricing vs GPT-5.6: use the September rates

At current short-context Standard rates, Astra's input and output tokens each cost 2.5 times as much as GPT-5.6 Sol's. The comparison uses OpenAI's September 6 pricing page. GPT-5.6 launch prices from July are no longer the right baseline: OpenAI reduced Sol's input and output rates on August 21.

Source: OpenAI API pricing. Sol's listed promotional pricing is available at least through November 21, 2026. This table covers direct API token rates; tool fees, regional uplifts, subscriptions, and credits are separate.

The context window and the price threshold are different numbers

Astra's 1,050,000-token context window is larger than its short-context pricing band. For prompts above 272K input tokens, the full request uses the higher rates: $20 input, $2 cached input, $25 cache writes, and $75 output per million tokens. The higher rate does not apply only to the portion above the threshold.

Batch and Flex processing are priced at 50% of the corresponding Standard rates. API Fast mode is twice the applicable rate. The current docs also state that Astra Fast mode is unavailable with EU data residency and does not include a latency SLA. These are different service choices, not interchangeable ways of describing one price.

OpenAI's model guide reports lower estimated API cost per task on several evaluations because Astra used fewer output tokens, despite higher token rates. That finding does not establish your application's cost. Compare actual usage for accepted work, including retries and continuations, before deciding which rate produces the better result.

API migration: four requirements that affect existing applications

For an API integration, gpt-6-astra is the documented identifier. The official migration guide calls out compatibility changes that matter even if you do not immediately add steering.

1. Use Responses for tool calling. Astra supports Chat Completions, but tool calling requires the Responses API. An existing Chat Completions tool integration needs that migration.
2. Choose a supported reasoning effort. The model lists low, medium, high, xhigh, and max. The none setting is unsupported.
3. Remove unsupported sampling and log-probability settings. Review temperature, top_p, top_logprobs, and endpoint-specific log-probability fields using the migration guide.
4. Preserve caching when changing effort. In supported standard, single-agent requests, use configuration_update items to change effort during the conversation. OpenAI advises keeping the original request-level effort unchanged to preserve the cached prefix.

For steering specifically, a WebSocket connection is required. An ordinary HTTP streaming request does not acquire the steering event flow just because its model ID changes. Async tools also need application support for outstanding calls and their eventual outputs.

Judge the upgrade at the moment the brief changes

A useful evaluation should include a task where the user adds a requirement after work has begun. Review whether the correction appears in the final result, whether completed work survives appropriately, and whether the interface accurately shows what is still running.

For an app-building workflow, we would review three outcomes: the accepted artifact, the time until it is ready to review, and the total cost to reach it. Then inspect the handoffs that produced them: queued corrections, pending tool results, and continuations. This is an evaluation recommendation, not a claim about results we measured on Astra.

The same approach can reveal when an upgrade offers little value. If a workflow never needs steering or work to continue around a slow tool, these particular features do not explain a higher budget. A capability gain on the actual task would need to justify the choice.

For the earlier tier structure, see our GPT-5.6 Sol, Terra, and Luna guide; use the current table above for rates. If preserving long-session context is the central concern, the Claude Fable 5.1 analysis looks at that problem from the conversation-history side.

GPT-6 Astra questions

Sources and editorial method

Checked September 6, 2026 against the official pages below. Pricing comparisons are calculations from published API rates. Recommendations concern application design; we did not run a Casagbic benchmark or measure a productivity improvement for this article.

1. OpenAI API changelog — Astra's September 3 release and the August 21 Sol price change.
2. GPT-6 Astra model page — identifier, context, output limits, and supported reasoning efforts.
3. OpenAI API pricing — Standard, long-context, Batch, Flex, and Fast rates.
4. Mid-turn steering — WebSocket events, continuations, pending input, and limits.
5. Async tool calling — application responsibilities and result delivery.
6. Using GPT-6 Astra — migration, prompting, caching, and Fast-mode compatibility.