OpenAI Responses API: GPT-6 Astra erzwingt den Wechsel

In der Praxis sind zwei Entscheidungen entscheidend: Wie viel Entwicklungsarbeit gehört in die Migration – und können die neuen Steuerungsmöglichkeiten die Kosten für Wartezeiten, Korrekturen und Neustarts von Agentenläufen senken?

Was ändert sich mit der OpenAI Responses API?

Das vorab bekannte Bild von Astra zeigte ein Forschungsmodell hinter verschlossenen Türen. Mit der Veröffentlichung im September erhält es die öffentliche Modell-ID gpt-6-astra, eine Preisstruktur und Unterstützung sowohl für Chat Completions als auch für Responses. Zunächst erhalten Unternehmen im Trusted Access Program von OpenAI Zugriff; API-Zugang und weitere Tarife sollen in den kommenden Tagen folgen.

Welcher Endpunkt passt, hängt von der Anwendung ab. Eine reine Textintegration über Chat Completions kann Astra nutzen. Sobald Astra jedoch eigene Funktionen oder von OpenAI gehostete Tools aufrufen soll, ist die Responses API Pflicht.

Mit Responses ändert sich der Vertrag zwischen Anwendung und API. Chat Completions nimmt eine Nachrichtenliste entgegen und liefert eine Auswahlliste zurück. Responses arbeitet dagegen mit typisierten Items: Eine Nachricht ist ein Item, ein function_call ein weiteres. Das Tool-Ergebnis kommt als function_call_output zurück und trägt die ursprüngliche call_id.

Bei der Migration lauern zwei leicht zu übersehende Fallen. Wenn Requests über previous_response_id verkettet werden, werden instructions auf oberster Ebene nicht übernommen und müssen erneut gesendet werden. Structured Outputs wandert außerdem von response_format zu text.format. Der Migrationsleitfaden führt sämtliche Änderungen an Parser, Zustand, Tools und Streaming auf.

Warum jetzt zwei Änderungen ins Budget gehören

Das erste Budget betrifft die Entwicklungszeit. Eine produktive Tool-Schleife umfasst Endpunkt, Request-Schema, Ausgabeparser, Funktionsdefinitionen, Ergebniszuordnung, Zustandsverwaltung, Streaming-Events, Protokollierung, Wiederholungsversuche und Evals. Wer nur den Modellnamen austauscht, lässt den Großteil dieser Arbeit unerledigt.

Das zweite Budget betrifft die Kosten pro abgeschlossenem Auftrag. Für GPT-6 Astra gelten im Standardtarif bei kurzem Kontext $10.00 je 1 Million Eingabetokens, $1.00 für gecachte Eingaben, $12.50 für Cache-Schreibvorgänge und $50.00 für Ausgaben. Die aktuellen Aktionspreise von GPT-5.6 Sol liegen für dieselben vier Positionen bei $4.00, $0.40, $5.00 und $20.00. Bei identischem Tokenvolumen kostet Astra in jeder Position das 2.5-Fache.

Für den Endpunkt selbst fällt keine separate Gebühr an. Kosten entstehen durch Modelltokens, kostenpflichtige integrierte Tools, die eigene Tool-Infrastruktur, Wiederholungsversuche und abgebrochene Arbeit. Bei Prompts mit mehr als 272,000 Eingabetokens werden für den gesamten Astra-Request zudem die doppelten Eingabe- und Cache-Preise sowie das 1.5-Fache des Ausgabepreises berechnet. Diese Zahlen von der aktuellen Preisseite gehören ins Pilotbudget.

Die Mehrkosten könnten sich teilweise auffangen lassen, doch belegen lässt sich das nur mit eigenen Daten. Laut OpenAI erzielt Responses in internen Tests eine um 40% bis 80% bessere Cache-Nutzung als Chat Completions. Außerdem weist OpenAI für mehrere Evaluationen niedrigere geschätzte Astra-API-Kosten pro Aufgabe aus, weil Astra trotz des höheren Tokenpreises weniger Ausgabetokens verbrauchte. Keine dieser Aussagen garantiert allgemeine Einsparungen.

Gemessen werden sollte stattdessen:

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

Der Nenner ist entscheidend. Ein günstiger Lauf, der nach einer späten Korrektur neu gestartet werden muss, kann pro fertigem Ergebnis teurer sein als ein kostspieligerer Lauf, der bereits geleistete Arbeit bewahrt.

Asynchrone Tool-Aufrufe verändern die Warteschleife

Bei einem normalen Funktionsaufruf pausiert das Modell, bis die Anwendung ein Ergebnis zurückgibt. Mit Astra kann eine von der Anwendung ausgeführte Funktion oder ein Custom Tool async: true tragen. Das Modell kann den Aufruf auslösen, weiterarbeiten, ein weiteres unabhängiges Tool aufrufen oder einen unabhängigen Teil der Anfrage beantworten, während die Anwendung den Auftrag ausführt.

Die Arbeit bleibt Aufgabe des eigenen Servers. Er muss den Auftrag starten, ein Auftragsregister führen, die ursprüngliche call_id speichern und das Ergebnis in einem späteren Responses-Request übermitteln. Falls vor dem Eintreffen des Ergebnisses weitere Turns stattfinden, sollte die Fortsetzung die neueste Response-ID verwenden, während die Tool-Ausgabe weiterhin auf die ursprüngliche Call-ID verweist.

In einem Rechercheprodukt kann so etwa eine langsame Anfrage an einen Datenanbieter laufen, während Astra bereits verfügbare Quellen ordnet. Bei einem internen Ops-Agenten können zwei unabhängige Kontenabfragen früh beginnen, während das Modell den davon unabhängigen Berichtsteil entwirft. Der Gewinn besteht in weniger Leerlauf, nicht in kostenloser Ausführung.

Mid-Turn Steering verändert die Neustartschleife

Mid-Turn Steering erlaubt es, einen laufenden Auftrag zu korrigieren, während Astra noch arbeitet. Die Anwendung sendet auf demselben Responses-WebSocket ein response.steer-Event, verweist über previous_response_id auf die aktive Response und übermittelt die neue Anweisung. Der Server beendet das aktuelle Ausgabe-Item und bereits laufende Arbeiten gehosteter Tools; anschließend erstellt er eine Fortsetzung mit der Aktualisierung.

Das hilft beispielsweise, wenn in einer Agentur auffällt, dass ein Bericht auf den falschen Markt zielt, oder wenn eine technische Leitung den Umfang eines laufenden Migrationsplans verkleinern muss. So lässt sich die Richtung korrigieren, bevor der gesamte Turn abgeschlossen ist.

Bereits angefallene Arbeit bleibt angefallen. Steering schreibt ausgelieferte Ausgaben nicht um, macht frühere Aktionen nicht rückgängig und bricht gestartete Tools nicht ab. Token- und Tool-Aufruflimits gelten separat für die ursprüngliche Response und ihre Fortsetzung. Wirtschaftlich sinnvoll wird die Funktion durch weniger vollständige Neustarts bei späten Korrekturen – ob das oft genug vorkommt, muss weiterhin gemessen werden.

Steering steht nur mit Astra zur Verfügung und setzt den Responses-WebSocket voraus. Wartende Steering-Anweisungen existieren ausschließlich auf dieser Verbindung. Deshalb muss die Anwendung jede akzeptierte Aktualisierung protokollieren und die Wiederherstellung nach einem Verbindungsabbruch sorgfältig lösen. OpenAI begrenzt eine WebSocket-Verbindung auf 60 Minuten. Bei WebSocket-Rollouts mit 20 oder mehr Tool-Aufrufen nennt der WebSocket-Leitfaden eine bis zu rund 40% schnellere End-to-End-Ausführung. Das ist allerdings ein Ergebnis des Transports und keine zugesicherte Einsparung durch Steering.

Ein praxistauglicher Ablauf für die Responses API Migration

Beginnen Sie mit einem risikoarmen Funktionsablauf, nicht mit dem am stärksten ausgelasteten Produktions-Agenten.

Installieren Sie das aktuelle Python-SDK und setzen Sie die Umgebungsvariable wie im OpenAI-Quickstart gezeigt:

pip install openai
export OPENAI_API_KEY="your_api_key_here"

Dies ist das ausführbare Async-Tool-Beispiel von OpenAI mit Demo-Wetterdaten. Es kann ausgeführt werden, sobald das API-Projekt Zugriff auf Astra hat:

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)

Entscheidend ist die leicht zu übersehende Zeile call_id: call.call_id. Das spätere Ergebnis gehört zum ursprünglichen Tool-Aufruf, selbst wenn neuere Turns inzwischen die aktuelle Response-ID verändert haben.

Für wen eignet sich welcher Baustein?

Backend-Team, das bereits Funktionen aufruft

Planen Sie die Responses-Migration im Budget ein, bevor Astra für diesen Pfad eingeführt wird. So entsteht eine kontrollierte Umstellung mit vergleichbaren Protokollen und Evals, statt Endpunkt-, Parser- und Modellwechsel gleichzeitig zu debuggen.

SaaS-Agent mit Wartezeiten bei langsamen Diensten

Async eignet sich nur für Aufgaben, die tatsächlich unabhängig sind. Eine CRM-Abfrage, interne Suche oder ein Dokumentexport kann starten, während Astra einen anderen Zweig bearbeitet. Blockiert eine Abhängigkeit die nächste Entscheidung, sollte sie synchron bleiben oder ein ausdrückliches Warte-Tool verwenden.

Operations- oder Agenturteam mit lang laufenden Aufträgen

Steering lohnt sich für Korrekturen, die andernfalls einen Abbruch und Neustart auslösen. Erfassen Sie, wie viele Neustarts dadurch tatsächlich entfallen und wie viel fertige Arbeit jede Korrektur bewahrt. So entsteht ein belastbarer Business Case statt einer Feature-Demo.

Reguliertes Unternehmen mit Zero Data Retention

Der Responses-WebSocket-Modus funktioniert mit store: false und Zero Data Retention, doch die Zustandsverwaltung liegt dann bei der eigenen Anwendung. Bewahren Sie bei Bedarf verschlüsselte Reasoning-Items auf, spielen Sie den vollständigen Kontext erneut ein, wenn eine Response-ID nicht mehr verfügbar ist, und entwerfen Sie diesen Wiederherstellungspfad, bevor Nutzer Steering erhalten.

Die ehrliche Einordnung

Der Zugang zu Astra wird weiterhin schrittweise freigeschaltet. Die Migration lässt sich jetzt vorbereiten; die vollständige Produktionsumstellung sollte jedoch warten, bis das Projekt Zugriff hat und Evals für die konkrete Arbeitslast vorliegen.

Asynchrone Tools erfordern ein Auftragsregister und den Umgang mit Ergebnissen außerhalb ihrer Aufrufreihenfolge. Steering ergänzt Verbindungszustand, Fortsetzungslogik und Wiederherstellung. Beides kann verschwendete Wartezeit oder Neustarts reduzieren – und beides schafft zusätzlichen Code, der ausfallen kann.

Ob sich der Preis rechnet, bleibt offen, bis eigene Telemetriedaten vorliegen. Bei identischen Tokens kostet Astra das 2.5-Fache der aktuellen Aktionspreise von GPT-5.6 Sol. Bessere Cache-Nutzung, weniger Ausgabetokens und weniger Neustarts können diese Lücke bei manchen Aufträgen schließen. Sichern Sie den Piloten mit einem festen Ausgabenlimit ab und bewerten Sie Astra anschließend nach Kosten pro abgeschlossenem Auftrag und Bedienzeit.

Was am Montag ansteht

• Wenn Ihre Anwendung Tool-Aufrufe über Chat Completions nutzt und Astra einsetzen soll, erfassen Sie einen produktiven Ablauf und finanzieren Sie noch diese Woche einen Responses-Schattenpfad.
• Bei einer reinen Textanwendung sollte der stabile Pfad während der schrittweisen Freischaltung bestehen bleiben. Für diesen Pfad ist kein Endpunktwechsel vorgeschrieben.
• Wenn langsame Tools den Großteil der Laufzeit verursachen, testen Sie eine asynchrone Funktion und messen Sie Leerlauf, Fehler sowie Kosten pro abgeschlossenem Auftrag.
• Wenn späte menschliche Korrekturen Neustarts verursachen, erproben Sie Steering erst, nachdem die Tests für WebSocket-Wiederverbindung und -Wiedergabe bestanden sind.
• Wenn die Rechnung bei Astras 2.5-fachem Tokenpreis schon vor jedem gemessenen Ausgleich nicht aufgeht, belassen Sie diese Arbeitslast auf GPT-5.6 Sol, Terra oder Luna.

Wer auch die nächste Plattformänderung in konkrete Abläufe und Budgetentscheidungen übersetzt bekommen möchte, kann den Newsletter abonnieren.