GPT-6 Astra Forces a Responses API Decision

The practical decisions are how much engineering work belongs in the migration and whether the new controls can lower the cost of waiting, correcting, and restarting agent runs.

What actually changed

The pre-release Astra picture was a research model behind a locked door. The September release gives it a public model ID, gpt-6-astra, prices it, and puts it on both Chat Completions and Responses. Access starts with enterprises in OpenAI's Trusted Access Program, with API and wider plan access rolling out in the coming days.

The endpoint choice depends on what your application does. A text-only Chat Completions integration can use Astra. An integration that lets Astra call your functions or OpenAI-hosted tools has to use the Responses API.

Responses is a different application contract. Chat Completions moves a list of messages in and a list of choices out. Responses moves typed Items. A message is one Item, a function_call is another, and your tool result returns as a function_call_output carrying the original call_id.

There are two easy migration traps. Top-level instructions do not carry forward when you chain with previous_response_id, so send them again. Structured Outputs also moves from response_format to text.format. The migration guide lists the full set of parser, state, tool, and streaming changes.

Why it matters: you now budget for two changes

The first budget is engineering time. A production tool loop touches the endpoint, request schema, output parser, function definitions, result correlation, state handling, streaming events, logs, retries, and evals. Changing only the model name leaves most of that work undone.

The second budget is cost per completed job. GPT-6 Astra's Standard short-context rates are $10.00 per 1 million input tokens, $1.00 for cached input, $12.50 for cache writes, and $50.00 for output. GPT-5.6 Sol's current promotional rates are $4.00, $0.40, $5.00, and $20.00 on the same four lines. At identical token volume, Astra is 2.5 times the price on each line.

The endpoint itself has no separate fee. Your bill comes from model tokens, priced built-in tools, your own tool infrastructure, retries, and work that gets abandoned. Prompts over 272,000 input tokens also push the full Astra request to twice the input and cache rates and 1.5 times the output rate. Those are the numbers to put into the pilot budget from the current pricing page.

There is a possible offset, but it needs your own data. OpenAI reports 40% to 80% better cache utilization for Responses than Chat Completions in internal tests. It also reports lower estimated Astra API cost per task in several evaluations because Astra used fewer output tokens, despite the higher token price. Neither claim gives you a universal saving.

Measure this instead:

cost per completed job = model tokens + built-in tool fees + your tool costs + retries + operator time

That denominator matters. A cheaper run that has to restart after a late correction can cost more per finished result than a pricier run that keeps useful work.

Async tool calling changes the waiting loop

A normal function call pauses the model until your application returns a result. With Astra, an application-run function or custom tool can carry async: true. The model can issue the call, continue reasoning, call another independent tool, or answer an independent part of the request while your application runs the job.

Your server still owns the work. It must start the job, keep a registry, save the original call_id, and deliver the result in a later Responses request. If other turns happen before that result arrives, the continuation should use the latest response ID while the tool output still points to the original call ID.

For a research product, that means a slow data-provider request can run while Astra organizes the sources already available. For an internal ops agent, two independent account lookups can start early while the model drafts the part of the report that does not depend on them. The payoff is less idle time, not free execution.

Mid-turn steering changes the restart loop

Mid-turn steering lets a user correct a job while Astra is still working. Your application sends a response.steer event on the same Responses WebSocket, points it at the active response with previous_response_id, and supplies the new instruction. The server finishes the current output Item and any hosted tool work already running, then creates a continuation with the update.

That is useful for an agency operator who notices the report is aimed at the wrong market, or an engineering lead who needs a running migration plan cut to a smaller scope. They can correct the work before the whole turn finishes.

The spent work stays spent. Steering does not rewrite output already delivered, undo an earlier action, or cancel a tool that has started. Token and tool-call limits apply separately to the original response and its continuation. The business case is fewer full restarts when the correction arrives late, and you still have to measure whether that happens often enough to matter.

Steering is Astra-only and requires the Responses WebSocket. Queued steering lives only on that connection, so your application needs to record each accepted update and recover carefully after a disconnect. OpenAI caps a WebSocket connection at 60 minutes. For WebSocket rollouts with 20 or more tool calls, the WebSocket guide reports up to roughly 40% faster end-to-end execution, but that is a transport result rather than a promised steering saving.

A migration walk you can run

Start with one low-risk function flow. Do not begin with the busiest agent in production.

Install the current Python SDK and set the environment variable as shown in the OpenAI quickstart:

pip install openai
export OPENAI_API_KEY="your_api_key_here"

This is OpenAI's runnable async-tool example with demo weather data. Run it once your API project has Astra access:

import json
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI
from openai.types.responses import FunctionToolParam

def get_weather(city):
    # Demo data. Replace this function with your weather service.
    weather = {
        "Paris": {
            "city": "Paris",
            "temperature_c": 22,
            "condition": "Clear",
            "source": "demo weather snapshot",
        }
    }
    return weather[city]

worker = ThreadPoolExecutor()

def main():
    client = OpenAI()
    model = "gpt-6-astra"
    tools: list[FunctionToolParam] = [
        {
            "type": "function",
            "name": "get_weather",
            "description": "Read the demo weather snapshot for a city.",
            "async": True,
            "strict": True,
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
                "additionalProperties": False,
            },
        },
    ]

    instructions = (
        "Start the weather lookup and answer the independent packing "
        "question without waiting. Use the actual tool result when it "
        "arrives; never invent it. Identify the weather as demo data."
    )
    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        input=(
            "Check the demo weather in Paris. Meanwhile, "
            "list three essentials for any city trip."
        ),
    )

    call = next(item for item in response.output if item.type == "function_call")
    arguments = json.loads(call.arguments)
    if call.name != "get_weather" or arguments != {"city": "Paris"}:
        raise ValueError("Expected a weather lookup for Paris")

    latest_response_id = response.id
    if call.async_:
        job = worker.submit(get_weather, **arguments)
        print(response.output_text)
        # Independent work or conversation turns can happen here.
        # Update latest_response_id after each continuation.
        result = job.result()
    else:
        result = get_weather(**arguments)

    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        previous_response_id=latest_response_id,
        input=[
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": json.dumps(result),
            },
        ],
    )
    print(response.output_text)

if __name__ == "__main__":
    try:
        main()
    finally:
        worker.shutdown(wait=True)

The line people will miss is call_id: call.call_id. The later result belongs to the original tool call, even if newer conversation turns have changed the latest response ID.

Who should use each part

A backend team already calling functions

Budget the Responses migration before adopting Astra for that path. The payoff is a controlled cutover with comparable logs and evals, instead of debugging an endpoint, parser, and model change at the same time.

A SaaS agent waiting on slow services

Use async only for work that is genuinely independent. A CRM lookup, internal search, or document export can start while Astra handles another branch. A dependency that blocks the next decision should stay synchronous or use an explicit wait tool.

An ops or agency team supervising long work

Expose steering for corrections that otherwise cause a cancel and restart. Track how many restarts it actually prevents and how much completed work each correction preserves. That gives you a business case instead of a feature demo.

A regulated enterprise using Zero Data Retention

Responses WebSocket mode works with store: false and Zero Data Retention, but state becomes your responsibility. Preserve encrypted reasoning Items where needed, replay full context when a response ID is no longer available, and design that recovery path before steering reaches users.

The honest part

Astra access is still rolling out. A migration can be prepared now, but a full production switch should wait for project access and workload-specific evals.

Async tools add a job registry and out-of-order results. Steering adds connection state, continuation handling, and recovery. Both can reduce wasted waiting or restarts, and both add code that can fail.

The price case is unsettled until your telemetry exists. Identical tokens cost 2.5 times GPT-5.6 Sol's promotional rates. Better caching, fewer output tokens, and fewer restarts may close that gap for some jobs. Put the pilot behind a hard spend limit, then judge Astra by completed-job cost and operator time.

The Monday move

• If your application uses Chat Completions tool calls and you want Astra, inventory one production flow and fund a Responses shadow path this week.
• If your application is text-only, keep it stable while access rolls out. There is no forced endpoint migration for that path.
• If slow tools dominate elapsed time, trial one async function and measure idle time, failures, and completed-job cost.
• If late human corrections cause restarts, prototype steering only after WebSocket reconnect and replay tests pass.
• If Astra's 2.5 times token rate breaks the unit economics before any measured offset, keep that workload on GPT-5.6 Sol, Terra, or Luna.

For the next platform change translated into a workflow and budget move, join the newsletter.