Beschleunigung von agentischen Workflows mit WebSockets in der Responses API

Wenn du Codex bittest, einen Fehler zu beheben, durchsucht es deine Codebasis nach relevanten Dateien, liest diese, um den Kontext zu erfassen, nimmt Änderungen vor und führt Tests aus, um zu überprüfen, ob die Fehlerbehebung erfolgreich war. Hinter den Kulissen bedeutet das Dutzende von API-Anfragen, die hin- und hergehen: die nächste Aktion des Modells bestimmen, ein Tool auf deinem Computer ausführen, die Tool-Ausgabe an die API zurücksenden und so weiter.

All diese Anfragen können sich zu mehreren Minuten summieren, die Nutzer:innen darauf warten, dass Codex komplexe Aufgaben abschließt. Aus Latenzsicht verbringt die Codex-Agenten-Schleife die meiste Zeit in drei Hauptphasen: der Arbeit in den API-Diensten (zum Validieren und Verarbeiten von Anfragen), der Modellinferenz und der clientseitigen Zeit (beim Ausführen von Tools und beim Erstellen des Modellkontexts). Inferenz ist die Phase, in der das Modell auf GPUs ausgeführt wird, um neue Token zu generieren. In der Vergangenheit war die Ausführung von LLM-Inferenz auf GPUs der langsamste Teil der Agentenschleife, sodass sich der API-Dienst-Overhead leicht verbergen ließ. Je schneller die Inferenz wird, desto stärker fällt der kumulative API-Overhead eines agentischen Rollouts ins Gewicht.

In diesem Beitrag erklären wir, wie wir Agentenschleifen mit der API durchgängig um 40 % beschleunigt haben, sodass Nutzer:innen den Sprung bei der Inferenzgeschwindigkeit von 65 auf fast 1 000 Tokens pro Sekunde merken können. Wir haben dies durch Caching, die Eliminierung unnötiger Netzwerkwechsel, die Verbesserung unseres Sicherheits-Stacks zur schnellen Erkennung von Problemen und – am wichtigsten – durch die Entwicklung einer Möglichkeit erreicht, eine persistente Verbindung zur Responses API herzustellen, anstatt eine Reihe synchroner API-Aufrufe durchführen zu müssen.

In der Responses API liefen frühere Flagship-Modelle wie GPT‑5 und GPT‑5.2 mit etwa 65 Token pro Sekunde (TPS). Für die Einführung von GPT‑5.3‑Codex‑Spark, einem schnellen Modell zum Programmieren, war unser Ziel, eine Größenordnung schneller zu sein: über 1.000 TPS, ermöglicht durch spezialisierte, für LLM-Inferenz optimierte Cerebras-Hardware. Um sicherzustellen, dass Nutzer:innen die tatsächliche Geschwindigkeit dieses neuen Modells erfahren konnten, mussten wir den API-Overhead reduzieren. 

Um November 2025 herum haben wir für die Responses API einen Performance-Sprint gestartet und dabei zahlreiche Optimierungen für die Latenz des kritischen Pfads bei einer einzelnen Anfrage umgesetzt: 

• Zwischenspeichern von gerenderten Tokens und der Modellkonfiguration im Speicher, um aufwendige Tokenisierung und Netzwerkaufrufe für mehrstufige Antworten zu überspringen
• Reduzierung der Latenz bei Netzwerkwechseln durch den Wegfall von Aufrufen an zwischengeschaltete Dienste (beispielsweise zur Auflösung der Bildverarbeitung) und durch den direkten Aufruf des Inferenzdienstes selbst
• Verbesserung unseres Sicherheits-Stacks, damit wir bestimmte Klassifikatoren ausführen können, um Gespräche schneller zu kennzeichnen

Mit diesen Verbesserungen konnten wir bei der Zeit bis zum ersten Token (Time to first token, TTFT) eine Verbesserung von fast 45 % verzeichnen – was widerspiegelt, wie reaktionsschnell die API wirkt. Doch selbst diese Verbesserungen waren für GPT‑5.3‑Codex‑Spark noch nicht schnell genug. Selbst damit war der Overhead der Responses API im Verhältnis zur Geschwindigkeit des Modells zu hoch – das heißt, die Nutzer:innen mussten auf die CPUs warten, auf denen unsere API lief, bevor sie die GPUs nutzen konnten, auf denen das Modell ausgeführt wurde.

Das tieferliegende Problem war strukturell: Wir haben jede Codex-Anfrage als unabhängig behandelt und bei jeder Folgeanfrage den Gesprächsstatus und anderen wiederverwendbaren Kontext verarbeitet. Selbst wenn der Großteil des Gesprächsverlaufs unverändert geblieben war, mussten wir dennoch für Arbeit bezahlen, die an den vollständigen Verlauf gebunden war. Mit zunehmender Länge der Gespräche wurde diese wiederholte Verarbeitung kostspieliger.

Um das Design zu straffen, überdachten wir das Transportprotokoll: Könnten wir eine persistente Verbindung beibehalten und den Status zwischenspeichern, anstatt für jede Folgeanfrage eine neue Verbindung über HTTP herzustellen und den gesamten Gesprächsverlauf zu senden? Die Idee war, nur neue Informationen zu senden, die validiert und verarbeitet werden müssen, und wiederverwendbare Status für die Dauer der Verbindung im Speicher zu halten. Dies würde den Overhead durch redundante Arbeit reduzieren.

Wir haben einige verschiedene Ansätze in Betracht gezogen, darunter WebSockets und bidirektionales gRPC-Streaming. Wir haben uns für WebSockets entschieden, weil Nutzer:innen bei einem einfachen Nachrichtenübertragungsprotokoll ihre Eingabe- und Ausgabeformate für die Responses API nicht ändern müssen. Es war entwicklerfreundlich und fügte sich mit nur geringem Anpassungsaufwand in unsere bestehende Architektur ein.

Der erste WebSocket-Prototyp hat verändert, was wir bei der Latenz der Responses API für möglich hielten. Ein Codex-Teammitglied mit umfassender Expertise über den gesamten API-Stack hinweg stellte einen Prototyp zusammen, indem es einen Codex-Agenten über Nacht laufen ließ.

In diesem Prototyp wurden agentische Rollouts als eine einzelne langlaufende Antwort modelliert. Bei Verwendung von asyncio-Funktionen blockiert die Responses API in der Sampling-Schleife asynchron, nachdem ein Tool-Aufruf gesampelt wird, und die Responses API sendet ein response.done-Ereignis an den Client zurück. Nach dem Ausführen des Tool-Aufrufs senden Clients ein response.append-Ereignis mit dem Tool-Ergebnis zurück, was die Sampling-Schleife entsperrt und dem Modell erlaubt, fortzufahren.

Eine passende Analogie ist hier, den lokalen Tool-Aufruf wie einen gehosteten Tool-Aufruf zu behandeln. Wenn das Modell eine Websuche aufruft, blockiert die Inferenzschleife, ruft einen Websuchdienst auf und legt die Antwort des Dienstes im Modellkontext ab. In unserem Design haben wir dasselbe gemacht; aber anstatt einen Remote-Dienst aufzurufen, haben wir den Tool-Aufruf des Modells über den WebSocket an den Client zurückgesendet. Wenn der Client geantwortet hat, haben wir die Antwort des Clients zum Tool-Aufruf in den Kontext eingefügt und mit dem Sampling fortgefahren.

Dieses Design war äußerst effektiv, weil es wiederholte API-Arbeit bei einem Rollout von Agenten vermied. Wir konnten die Präinferenz-Arbeit einmal durchführen, für die Tool-Ausführung pausieren und die Post-Inferenz-Arbeit einmal am Ende durchführen.

Leider erforderte dies eine weniger vertraute und kompliziertere API-Struktur. Wir wollten, dass Entwickler:innen WebSocket-Unterstützung einfach hinzufügen können, ohne ihre API-Integration für einen neuen Interaktionsmodus neu schreiben zu müssen.

Für die Version, die wir eingeführt haben, sind wir wieder zu einer vertrauten Form zurückgekehrt: wir verwenden weiterhin response.create mit demselben Body und nutzen previous_response_id, um den Gesprächskontext aus dem Status der vorherigen Antwort fortzusetzen.

Bei einer WebSocket-Verbindung verwaltet der Server einen verbindungsbezogenen In-Memory-Cache des vorherigen Antwortstatus. Wenn ein nachfolgendes response.create-Ereignis previous_response_id enthält, rufen wir diesen Status aus dem Cache ab, anstatt die gesamte Konversation von Grund auf neu zu erstellen.

Dieser zwischengespeicherte Status umfasst:

• Das vorherige response-Objekt
• Vorherige Eingabe- und Ausgabe-Elemente
• Tool-Definitionen und Namespaces
• Wiederverwendbare Sampling-Artefakte, wie zuvor gerenderte Tokens

Durch die Wiederverwendung des im Speicher befindlichen Zustands der vorherigen Antwort konnten wir mehrere wichtige Optimierungen erzielen:

• Dafür sorgen, dass einige unserer Sicherheitsklassifikatoren und Anfragevalidierungen nur neue Eingaben und nicht jedes Mal den vollständigen Verlauf verarbeiten
• Führen eines In-Memory-Cache für gerenderte Tokens, den wir erweitern, um eine unnötige Tokenisierung zu vermeiden
• Wiederverwendung unserer erfolgreichen Modell-Auflösungs-/Routinglogik über Anfragen hinweg 
• Überlappung von nicht blockierender Post-Inferenz-Arbeit wie der Abrechnung mit nachfolgenden Anfragen

Ziel war es, dem Prototyp mit minimalem Overhead so nahe wie möglich zu kommen, jedoch mit einer API-Gestaltung, die Entwickler:innen bereits verstanden und auf deren Grundlage sie bereits entwickelt hatten.

Nach einem zweimonatigen Sprint zur Entwicklung des WebSocket-Modus haben wir gemeinsam mit führenden Start-ups im Bereich Programmier-Agenten eine Alpha-Version eingeführt, damit sie diese in ihre Infrastruktur integrieren und den Traffic sicher hochfahren konnten. Alpha-Nutzer:innen waren begeistert und berichteten von Verbesserungen von bis zu 40 %⁠(wird in einem neuen Fenster geöffnet) in ihren agentischen Workflows. Angesichts des positiven Alpha-Feedbacks waren wir bereit für den Launch.

Die Ergebnisse der Einführung waren sofort sichtbar. Codex hat den Großteil seines Responses-API-Traffics schnell auf den WebSocket-Modus umgestellt und dabei deutliche Verbesserungen bei der Latenz erzielt. Für GPT‑5.3‑Codex‑Spark haben wir unser Ziel von 1.000 TPS erreicht und Spitzen von bis zu 4.000 TPS beobachtet, was zeigt, dass die Responses API auch mit deutlich schnellerer Inferenz unter realem Produktions-Traffic Schritt halten konnte. Die Wirkung zeigte sich auch in der Entwickler-Community schnell:

• Codex hat den Großteil seines Traffics schnell auf WebSockets umgestellt. Nutzer:innen von Codex, die die neuesten Modelle wie GPT‑5.3‑Codex⁠(wird in einem neuen Fenster geöffnet), GPT‑5.4⁠(wird in einem neuen Fenster geöffnet), und darüber hinaus verwenden, profitieren alle vom Geschwindigkeitsvorteil des WebSocket-Modus.
• Vercel hat den WebSocket-Modus in das AI SDK integriert und konnte die Latenz um bis zu 40 %⁠(wird in einem neuen Fenster geöffnet) senken.
• Clines Workflows mit mehreren Dateien sind 39 % schneller⁠(wird in einem neuen Fenster geöffnet).
• OpenAI-Modelle in Cursor wurden um bis zu 30 % schneller⁠(wird in einem neuen Fenster geöffnet).

Der WebSocket-Modus ist seit der Einführung der Responses API im März 2025 eine ihrer wichtigsten neuen Funktionen. Durch die enge Zusammenarbeit zwischen den API- und Codex-Teams von OpenAI schafften wir es in nur wenigen Wochen von der Idee bis zum produktiven Einsatz. Sie verbessert nicht nur die Latenz bei der Bereitstellung von Agenten erheblich, sondern unterstützt auch einen wachsenden Bedarf von Entwickler:innen: Je schneller die Modellinferenz wird, desto schneller müssen auch die Dienste und Systeme werden, die die Inferenz umgeben, um diese Leistungsgewinne an die Nutzer:innen weiterzugeben.