WebSocket Mode in der Responses API zielt auf ein konkretes Problem: Agenten mit vielen Tool Calls verlieren Zeit durch wiederholte HTTP Requests und das ständige Neubewerten von Kontext. Laut OpenAI lassen sich solche Agent Loops damit in der Praxis um bis zu 40 Prozent beschleunigen, weil pro Turn nur noch inkrementelle Inputs plus previous_response_id übertragen werden und der Server Zustand im Speicher weiterverwendet.
Übersicht:
Warum die API plötzlich bremst
Wenn die Inferenz schneller wird, rückt der Rest der Kette ins Rampenlicht: Validierung, Kontextaufbereitung, Routing, Safety Checks und Netzwerkwege addieren sich über viele Agent Turns zu spürbarer Wartezeit. Genau das beschreibt das Unternehmen im Engineering Beitrag vom 22. April 2026, am Beispiel von Codex Agent Workflows, die aus dutzenden Hin und Her Schritten bestehen.
Für die Latenz ist nicht ein einzelner Engpass entscheidend, sondern die Summe aus drei Zeitblöcken: API Services, Modell Inferenz und Client Zeit, also Tool Ausführung und Kontextbau. Sobald die GPU Ausgabe sehr schnell ist, kann ausgerechnet CPU Arbeit vor und nach der Inferenz zum dominanten Anteil werden, obwohl sie pro Request klein wirkt.
Mini Modell für die Einordnung
Ein hilfreiches Denkmodell ist das Tempo Dreieck:
- Inferenztempo: Tokens pro Sekunde bestimmen, wie schnell das Modell Text erzeugt.
- Orchestrierungs Overhead: Alles, was zwischen den Turns passiert, inklusive Validierung, Safety, Kontextmanagement und Transport.
- Tool Laufzeit: Lokale oder entfernte Aktionen wie Tests, Suche, Dateizugriffe, Browser und Datenbankabfragen.
WebSocket Mode greift vor allem die zweite Ecke an, also die Orchestrierung, nicht die Tool Laufzeit. Deshalb ist der Effekt am größten, wenn ein Agent viele kurze Turns hat.
Was sich mit WebSocket Mode ändert
WebSocket Mode ersetzt nicht die Responses API Semantik, sondern den Transport: Statt jedes Mal neu per HTTP zu verbinden, bleibt eine WebSocket Verbindung offen und jeder Turn wird als Event gesendet. Laut Dokumentation läuft die Verbindung gegen /v1/responses, typischerweise als wss://api.openai.com/v1/responses, und die Fortsetzung erfolgt über previous_response_id plus ausschließlich neue Input Items.
Der zentrale Trick ist serverseitiger Zustand im Arbeitsspeicher, der an die Verbindung gebunden ist. Die API kann dadurch den zuletzt genutzten Response State wiederverwenden, anstatt Gesprächshistorie und Tool Definitionen immer wieder vollständig zu verarbeiten, was insbesondere bei langen Ketten teurer wird.
| Aspekt | Klassisch per HTTP | WebSocket Mode |
|---|---|---|
| Verbindung | pro Turn neu | persistent, bis zu 60 Minuten |
| Payload pro Turn | häufig viel Kontext | nur neue Items plus previous_response_id |
| State Nutzung | nur über persistierte Chains | zusätzlich in Memory Cache auf dem aktiven Socket |
| Parallelität | einfach über mehrere Requests | pro Socket sequenziell, kein Multiplexing |
| Datenspeicherung | abhängig von store | kompatibel mit store=false und ZDR, weil State nicht auf Disk muss |
Weiterführende Links
- Engineering Beitrag des Unternehmens
- WebSocket Mode Guide
- Responses API Referenz
- Agents SDK Beispiel für WebSocket Sessions
Welche Stellschrauben den größten Hebel bringen
WebSockets allein sind nicht die ganze Geschichte. Laut OpenAI ging dem Launch eine Performance Phase voraus, in der mehrere Engpässe pro Request reduziert wurden, besonders mit Blick auf Time to First Token, also das Responsiveness Gefühl.
Die wichtigsten Bausteine in der Praxis
- In Memory Caching: Vorgerenderte Tokens und Modellkonfiguration bleiben verfügbar, damit nicht jeder Turn erneut teure Vorbereitung triggert.
- Weniger Netzwerkstationen: Kürzere Wege durch das System, indem Zwischenservices dort entfallen, wo sie nicht nötig sind.
- Inkrementelle Safety und Validierung: Prüflogik kann sich auf neue Inputs konzentrieren, statt die komplette Historie erneut zu klassifizieren.
- Wiederverwendung von Routing: Wenn die Modellauflösung bereits geklärt ist, wird sie nicht bei jeder Fortsetzung neu berechnet.
- Überlappung von Nacharbeit: Nicht blockierende Post Inferenz Aufgaben wie Abrechnung können mit dem nächsten Turn überlappen.
Ein zusätzlicher Performance Kniff aus der WebSocket Dokumentation ist Warmup: Mit generate=false</i lässt sich Zustand vorbereiten, ohne sofort Modelloutput zu erzeugen, damit der nächste Turn schneller startet.
Wann sich der Umstieg lohnt und wo es knallt
Als Faustregel gilt: WebSocket Mode ist dann am wertvollsten, wenn ein Agent viele kurze Modell Tool Wechsel hat. Die Dokumentation nennt explizit lange Ketten mit vielen Round Trips, und verweist auf bis zu rund 40 Prozent schnellere End to End Ausführung bei Workflows mit 20 oder mehr Tool Calls.
Konkretes Praxisbeispiel
Ein Coding Agent soll einen Testfehler beheben. Typischer Ablauf:
- Kontext holen: Der Agent sucht Dateien, liest betroffene Stellen, sammelt Fehlermeldungen.
- Eingriff: Der Agent ändert Code, passt Imports an, aktualisiert Tests.
- Verifikation: Der Agent startet Testläufe, bewertet Output, iteriert.
Per HTTP wirkt jeder Schritt wie ein eigener kleiner Chat, der erneut Kontext, Tools und Historie mitschleppt. Mit WebSocket Mode läuft derselbe Loop als fortgesetzte Response Chain, der Client sendet nur die neuen Tool Outputs und der Server nutzt den zuletzt bekannten Response State aus dem Socket Cache.
Entscheidungsregel für Teams
- WebSocket Mode wählen, wenn eine Session viele Tool Calls hat, der Nutzer auf flüssige Interaktion wartet und die Kette ansonsten an API Overhead stirbt.
- HTTP Streaming reicht, wenn es überwiegend um einzelne Antworten, kurze Chats oder seltene Tool Nutzung geht, oder wenn Infrastruktur WebSockets erschwert.
Typische Stolperstellen
- Nur ein In Memory State: Laut Guide hält der Service pro Verbindung den letzten Response State im Cache. Fortsetzung ist am schnellsten, wenn direkt an die letzte Antwort angehängt wird.
- Reconnect Strategie: Nach 60 Minuten muss eine neue Verbindung aufgebaut werden. Fortsetzung funktioniert dann entweder über persistierte Responses mit store=true, oder man startet neu, wenn bei store=false der alte State nicht mehr verfügbar ist.
- Keine Multiplexing Unterstützung: Pro WebSocket läuft nur ein Response gleichzeitig. Wer parallele Agent Runs will, braucht mehrere Verbindungen.
Markteinordnung
WebSocket Mode ist weniger ein Feature für Chat, sondern eine Infrastruktur Antwort auf ein Marktproblem: Agenten werden schneller als ihre Umgebung. Deshalb taucht der Nutzen zuerst dort auf, wo Agent Loops produktiv laufen, etwa in Coding Tools und SDKs. Im Beitrag nennt das Unternehmen unter anderem Integrationen in der Vercel AI SDK Welt sowie messbare Beschleunigungen in Toolchains wie Cline und Cursor, jeweils verlinkt über öffentliche Posts.
- Vercel Beitrag zur AI SDK und der verlinkte Performance Hinweis: Post zur WebSocket Mode Beschleunigung
- Cline Repository plus der genannte Messwert: Post zu schnelleren Multi File Workflows
- Cursor Website plus der genannte Messwert: Post zu schnelleren OpenAI Modellen in Cursor