Responses API vs. Chat Completions für Agents: Die Wahl des richtigen Vertrags

Für Agenten-Workloads ist die Responses API die bessere Standardwahl: Sie bietet serverseitigen Konversationsstatus über previous_response_id, typisierte Ausgabe-Elemente anstelle eines einzelnen Nachrichten-Blobs sowie semantische Streaming-Ereignisse. Diese Funktionen reduzieren den Buchhaltungsaufwand, den ansonsten Ihre Orchestrierungsschicht übernehmen müsste. Chat Completions bleibt eine valide Wahl, wenn Sie die volle Kontrolle über den Nachrichtenverlauf benötigen oder in Tooling integrieren, das auf dem OpenAI-Chat-Nachrichtenformat basiert. Für Agenten mit Multi-Turn-Tool-Calling ist Responses jedoch die direktere Lösung.

Beide Endpunkte sind auf den aktuellen Modell-Referenzseiten für GPT-5.6 und GPT-5.5 dokumentiert, und der gemeinsame Request/Response-Vertrag für Responses ist in der Responses Create-Referenz spezifiziert.

Wichtige Erkenntnisse

• Chat Completions wird vom Aufrufer verwaltet: Sie senden bei jeder Anfrage das vollständige messages-Array und rekonstruieren den Verlauf selbst.
• Responses ist servergestützt: Sie senden input sowie optionale instructions und können Turns mit previous_response_id verketten, anstatt den Verlauf erneut zu senden.
• Tool-Calling unterscheidet sich strukturell: Chat Completions verschachtelt Aufrufe unter choices[0].message.tool_calls; Responses gibt sie als typisierte Elemente in einem flachen output-Array aus.
• Tool-Ergebnisse werden über tool_call_id (Chat) gegenüber call_id in einem function_call_output-Element (Responses) zugeordnet.
• Streaming basiert in Chat Completions auf Chunk-basierten Deltas, in Responses hingegen auf benannten semantischen Ereignissen.
• Gehostete Tool-Unterstützung (Websuche, Code Interpreter, Dateisuche usw.) ist bei beiden APIs modellabhängig; prüfen Sie die Seite des jeweiligen Modells, bevor Sie von einer Verfügbarkeit ausgehen.

Vergleich auf Feldebene

Aspekt	Chat Completions	Responses
Endpunkt	POST /v1/chat/completions	POST /v1/responses
Primäre Eingabe	messages: [] (vollständiges Array bei jedem Aufruf)	input (String oder Array von Elementen)
System-Anweisungen	messages[0].role = "system"	Top-Level instructions-Feld
Multi-Turn-Fortführung	Aufrufer sendet gesamten messages-Verlauf erneut	previous_response_id referenziert den vorherigen Turn serverseitig
Ausgabeformat	choices[0].message (einzelnes Nachrichtenobjekt)	output: [], ein Array typisierter Elemente (Nachricht, function_call, etc.)
Ort des Tool-Aufrufs	choices[0].message.tool_calls[]	Elemente in output mit type: "function_call"
Übermittlung von Tool-Ergebnissen	Neue Nachricht mit role: "tool", tool_call_id	Element mit type: "function_call_output", call_id
Streaming	chunk.choices[0].delta Fragmente	Benannte Ereignisse (response.output_text.delta, response.completed, etc.)

previous_response_id: Was sie tatsächlich bewirkt

Bei Chat Completions liegt die Verantwortung für das Konversationsgedächtnis vollständig bei Ihnen. Jede Anfrage muss den vollständigen Nachrichtenverlauf enthalten, und der Server hat keine Kenntnis von einem vorherigen Turn. Die Responses API hingegen gibt bei jedem Response-Objekt eine id zurück. Wenn Ihre Anwendung diese id speichert und beim nächsten Aufruf als previous_response_id übergibt, rekonstruiert der Server den vorherigen Konversationsstatus auf seiner Seite. Sie müssen nur den neuen input für den aktuellen Turn sowie (optional) neue instructions senden. Dies verlagert das Zustandsmanagement von Ihrer Anwendungsschicht auf die Infrastruktur von OpenAI, was für Agenten, die viele sequentielle Tool-Calling-Turns durchführen, wichtig ist, da Sie das erneute Serialisieren und Übertragen eines wachsenden Verlaufs bei jedem Schritt vermeiden.

Der Kompromiss besteht darin, dass Ihre App die id zwischen den Turns dauerhaft speichern muss (in einem Session-Store, einer Datenbankzeile); die API bietet keine unendliche Aufbewahrung oder Suche über vergangene Antworten, sie erlaubt Ihnen lediglich, den unmittelbar vorangegangenen Turn als Fortsetzungspunkt zu referenzieren.

Aktuelle Request-Beispiele (gpt-5.6)

Chat Completions: Sie verwalten den vollständigen Verlauf:

{
  "model": "gpt-5.6",
  "messages": [
    { "role": "system", "content": "You are a support agent." },
    { "role": "user", "content": "Check order #4471 status." }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_order_status",
        "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
      }
    }
  ]
}

Responses: Erster Turn mit instructions und input:

{
  "model": "gpt-5.6",
  "instructions": "You are a support agent.",
  "input": "Check order #4471 status.",
  "tools": [
    {
      "type": "function",
      "name": "get_order_status",
      "parameters": { "type": "object", "properties": { "order_id": { "type": "string" } } }
    }
  ]
}

Responses: Folge-Turn, kein Verlauf erneut gesendet:

{
  "model": "gpt-5.6",
  "previous_response_id": "resp_abc123",
  "input": "What about order #4472?"
}

Lebenszyklus von Funktionsaufrufen

Chat Completions:

1. Das Modell gibt choices[0].message.tool_calls zurück, jeweils mit einer id und Funktionsname/Argumenten.
2. Sie führen die Funktion lokal aus.
3. Sie fügen die Assistant-Nachricht (mit tool_calls) Ihrem messages-Array hinzu und hängen dann eine neue Nachricht an: { "role": "tool", "tool_call_id": "<id>", "content": "<result>" }.
4. Sie senden das gesamte aktualisierte messages-Array erneut, um fortzufahren.

Responses:

1. Das output-Array enthält ein Element mit type: "function_call", einschließlich call_id, name und arguments.
2. Sie führen die Funktion lokal aus.
3. Sie senden eine neue Anfrage mit previous_response_id (gesetzt auf die id der vorherigen Antwort) und einem input, das ein Element mit type: "function_call_output", der passenden call_id und dem Ergebnis enthält.
4. Der Server hat den Kontext des Funktionsaufrufs bereits beibehalten, daher müssen Sie keine vorherigen Turns erneut senden.

Der strukturelle Unterschied zwischen flachen, typisierten Ausgabe-Elementen und einer einzelnen Nachricht mit verschachteltem Array vereinfacht in der Regel die Parsing-Logik in Responses, da Sie über output iterieren und nach type unterscheiden können, anstatt in den optionalen Feldern einer Nachricht zu graben.

Entscheidungs-Checkliste

• Bau eines Multi-Turn-Agenten mit Tool-Calls? Standardmäßig Responses verwenden; previous_response_id eliminiert die Buchhaltung des Verlaufs.
• Exakte Kontrolle über den Verlauf erforderlich (Schwärzung, benutzerdefinierte Zusammenfassung, nicht-standardisierte Nachrichteneinfügung)? Chat Completions bietet diese Kontrolle explizit, da Sie messages selbst zusammenstellen.
• Migration einer bestehenden Chat Completions-Integration? Wägen Sie die Refactoring-Kosten gegen die Einsparungen beim Zustandsmanagement ab; bei kurzlebigen Single-Turn-Aufrufen ist der Nutzen geringer.
• Abhängigkeit von gehosteten Tools (Suche, Code Interpreter, Datei-Tools)? Überprüfen Sie die Unterstützung auf der Seite des jeweiligen Modells, bevor Sie sich festlegen, da die Verfügbarkeit je nach Modell und Endpunkt variiert.
• Streaming mit fein abgestimmter Ereignissemantik erforderlich (z. B. Unterscheidung von Text-Deltas und Tool-Call-Deltas ohne Untersuchung der Delta-Form)? Die benannten Ereignisse von Responses sind expliziter als die generischen Delta-Chunks von Chat Completions.
• Arbeit innerhalb eines bestehenden Frameworks oder SDKs, das auf Chat-Nachrichten basiert? Bestätigen Sie die Reife der Responses-Unterstützung, bevor Sie den Vertrag mitten im Projekt wechseln.

Multi-Provider-Agenten und Vertragsübersetzung

Agenten bleiben selten lange bei einem einzigen Anbieter. Ein Coding-Agent könnte für Implementierungsarbeiten an Claude Sonnet 5 oder Kimi K2.7 Code weiterleiten, für günstige Entwürfe auf DeepSeek V4 Flash oder Gemini 3.5 Flash zurückgreifen und gelegentlich GLM-5.2 oder Qwen3.7 Plus zur Kostenkontrolle bei Open-Weight-Modellen aufrufen. Keiner dieser Anbieter stellt notwendigerweise den Chat Completions- oder Responses-Vertrag von OpenAI nativ bereit.

Hier zahlt sich eine Routing-Schicht aus. Die Dokumentation von TokenLab unter docs.tokenlab.sh beschreibt eine einheitliche API-Oberfläche und einen Schlüssel, die für den Zugriff auf mehrere Modellanbieter verwendet werden, was das manuelle Schreiben einer separaten Client-Integration pro Anbietervertrag überflüssig macht. Unser zugehöriger Artikel über Header-Aliase für Vertragskompatibilität behandelt, wie Request-Header zugeordnet werden können, sodass Code, der für eine Vertragsform geschrieben wurde, Modelle erreichen kann, die diese nicht nativ sprechen. Wenn Sie einen Chatbot oder Agenten bauen, der mehr als eine Modellfamilie aufrufen muss, führt unser Leitfaden zum Bau eines KI-Chatbots mit einem API-Schlüssel das Setup konkreter aus.

Die vollständige aktuelle Liste der über TokenLab erreichbaren Modelle, einschließlich der oben genannten Frontier-, Coding- und Low-Cost-Routing-Optionen, finden Sie auf unserer Modellseite. Bestätigen Sie dort die aktuelle Verfügbarkeit und etwaige vertragsspezifische Hinweise, bevor Sie Ihre Architektur finalisieren, da sich Modell-Lineups häufiger ändern als API-Verträge.

Einschränkungen

Dieser Artikel gibt die exakte API-Referenz auf Feldebene von OpenAI für keinen der beiden Verträge wieder, da diese Details versioniert sind und sich ändern können. Betrachten Sie das obige Beispiel für die Request-Form nicht als produktionsreifen Code. Wir haben auch nicht den nativen Vertrag jedes Anbieters im Detail behandelt; Claude, Gemini, DeepSeek und GLM veröffentlichen jeweils ihre eigenen API-Referenzen, und keiner von ihnen ist verpflichtet, die Formen von OpenAI Chat Completions oder Responses zu übernehmen. Wenn Ihr Agent Garantien bezüglich der Reihenfolge von Tool-Aufrufen, Streaming-Ereignisformaten oder Batch-Verarbeitungsverhalten benötigt, überprüfen Sie diese Spezifikationen anhand der aktuellen Dokumentation des jeweiligen Anbieters, nicht anhand dieses Artikels.

FAQ

Ist die Responses API ein Ersatz für Chat Completions? Die Quickstart-Dokumentation von OpenAI positioniert die Responses API als den aktuellen Weg für neue Entwicklungen, einschließlich agentischer Anwendungsfälle, während Chat Completions Teil ihrer dokumentierten API-Oberfläche bleibt. Ob Chat Completions zu einem bestimmten Zeitpunkt als veraltet (deprecated), eingestellt (sunset) oder einfach als Legacy gilt, sollten Sie direkt in den aktuellen Dokumenten von OpenAI prüfen, da sich der Support-Status ändern kann.

Verwenden andere Anbieter wie Claude, Gemini oder DeepSeek dieselben Verträge? Nicht nativ. Jeder Anbieter definiert seine eigene Request- und Response-Form. Wenn Sie einen Agenten über OpenAI-Modelle und Anbieter wie Claude Sonnet 5 oder DeepSeek V4 Pro hinweg betreiben müssen, planen Sie eine Übersetzungsschicht ein, anstatt von einem gemeinsamen Vertrag auszugehen.

Ändert ein Wechsel des Vertrags die Qualität der Modellausgabe? Nein. Der Vertrag ist der Transport und die Struktur der Anfrage und Antwort, nicht das Modell selbst. Die Ausgabequalität wird dadurch bestimmt, welches Modell Sie aufrufen (zum Beispiel GPT-5.5 gegenüber Claude Sonnet 5), nicht dadurch, ob Sie Chat Completions oder die Responses API für den Aufruf verwendet haben.

Wenn Sie evaluieren, welcher Vertrag und welche Modelle zu Ihrem Agenten passen, beginnen Sie mit einem kleinen Test-Build gegen die dokumentierten Endpunkte von TokenLab und vergleichen Sie den Orchestrierungsaufwand direkt. Starten Sie unter docs.tokenlab.sh, um diesen Vergleich mit Ihrer eigenen Workload durchzuführen.