Warum schnellere Agenten-Loops wichtig sind
OpenAI sagt, es habe die Infrastruktur hinter seiner Responses API überarbeitet, um agentenartige Workflows deutlich schneller zu machen. Ziel ist es, die Zeit zu verkürzen, die Nutzer warten, während Werkzeuge, Modelle und API-Aufrufe bei komplexen Aufgaben hin und her springen.
In einem technischen Beitrag vom 22. April beschrieb das Unternehmen, wie Systeme wie Codex Dutzende sequentielle Anfragen benötigen können, um eine einzelne Aufgabe abzuschließen: Das Modell entscheidet, was als Nächstes zu tun ist, ein Tool läuft auf der Client-Seite, das Ergebnis wird an die API zurückgesendet, und der Zyklus wiederholt sich. Dieses Muster sorgt dafür, dass sich selbst kleine Overheads schnell summieren.
Laut OpenAI wurde das Leistungsproblem sichtbarer, als die Inferenz selbst schneller wurde. Frühere Flaggschiff-Modelle in der Responses API liefen demnach mit etwa 65 Tokens pro Sekunde. Für GPT-5.3-Codex-Spark zielte OpenAI mit Cerebras-Hardware auf mehr als 1.000 Tokens pro Sekunde. Sobald die Modellerzeugung so schnell wurde, waren die langsameren Teile des Loops nicht mehr leicht zu verstecken.
Vom Inferenz-Engpass zum API-Engpass
OpenAI teilt die Latenz von Agenten in drei grobe Stufen auf: Arbeit des API-Dienstes, Modellinferenz und Zeit auf der Client-Seite. Die Client-Seite bleibt wichtig, weil Tools ausgeführt und Kontext zusammengesetzt werden müssen, doch das Unternehmen sagte, die API-Schicht selbst sei zu einem relevanten Engpass geworden.
Dieser Wandel erforderte eine andere Optimierungsstrategie. Statt sich nur auf GPU-Durchsatz zu konzentrieren, begann OpenAI nach eigener Aussage, Reibung entlang des Request-Pfads zu entfernen. Um November 2025 startete das Unternehmen das, was es als Performance-Sprint für die Responses API bezeichnete. Dazu gehörten das Caching gerenderter Tokens und der Modellkonfiguration im Speicher, weniger unnötige Netzwerksprünge durch direktere Aufrufe der Inferenzdienste und schnellere Teile des Safety-Stacks, damit einige Unterhaltungen schneller klassifiziert werden konnten.
Diese Änderungen verbesserten laut dem Unternehmen die Zeit bis zum ersten Token um fast 45 %. OpenAI sagt jedoch, dass das immer noch nicht ausreichte, um die Geschwindigkeitsgewinne seines neueren Inferenz-Stacks vollständig sichtbar zu machen.
Der Wechsel zu WebSocket
Die größere Änderung war architektonisch: eine Reihe getrennter synchroner API-Aufrufe wurde durch eine persistente Verbindung zur Responses API über WebSockets ersetzt. Praktisch bedeutet das, dass Client und API über den gesamten Agenten-Loop verbunden bleiben können, statt den Request-Status ständig abzubauen und neu aufzubauen.
OpenAI sagt, persistente Sitzungen hätten es ermöglicht, nützliche Informationen direkt an die Verbindung zu binden. Das reduzierte wiederholte Einrichtungsarbeit und half dem System, Kontext über mehrere Runden hinweg effizienter wiederzuverwenden. Das Ergebnis sei, so das Unternehmen, eine Verbesserung der End-to-End-Geschwindigkeit des Agenten-Loops um rund 40 % gewesen.
Für Nutzer ist die Bedeutung klar. Wenn ein Coding- oder Research-Agent viele Tool-Aufrufe braucht, um eine Aufgabe zu beenden, kann das Abschneiden von Overhead in jedem Zyklus mehr bewirken als nur eine einzelne Stufe zu beschleunigen. Ein Workflow, der sich früher zwischen Aktionen festgefahren anfühlte, kann sich näher an einer Live-Interaktion anfühlen.
Was OpenAI optimiert hat
- Verbindungsgebundenes Caching, um teure Einrichtungsarbeit nicht zu wiederholen.
- Weniger unnötige Netzwerksprünge zwischen API-Diensten und Inferenzdiensten.
- Schnellere Sicherheitsprüfungen in Teilen der Moderations- und Klassifizierungs-Pipeline.
- Ein persistenter WebSocket-Kanal, um die Kosten von Tool-Nutzung über viele Runden hinweg zu senken.
OpenAI stellte die Arbeit als Reaktion auf einen breiteren Branchenwandel dar: Inferenz wird schnell genug, dass umliegende Systeme zunehmend die wahrgenommene Produktqualität bestimmen. In diesem Umfeld kann ein Modell schnell denken, aber die Erfahrung kann sich dennoch langsam anfühlen, wenn Orchestrierungsschichten hinterherhinken.
Warum das über Codex hinaus wichtig ist
Obwohl OpenAI das Problem mit Codex veranschaulichte, reichen die Auswirkungen bis zu jedem Tool-nutzenden Agenten. Unternehmensassistenten, Kundenservice-Systeme, Forschungs-Copiloten und Software-Agenten beruhen alle auf vielen kleinen Interaktionen statt auf einer langen Modellvollendung. Persistente Sitzungen und geringerer Orchestrierungs-Overhead können daher ebenso wichtig sein wie rohe Benchmark-Leistung.
Der Beitrag gibt auch einen Einblick in eine sich wandelnde Wettbewerbslandschaft. Jahrelang betonten Modellanbieter besseres Reasoning und größere Kontextfenster. Zunehmend konkurrieren sie aber auch über Systems Engineering: Durchsatz, Reaktionsfähigkeit, Sicherheitslatenz und wie effizient ein Modell mit externen Tools in der Schleife bleiben kann.
Die Botschaft von OpenAI ist, dass die Infrastruktur rund um das Modell nun selbst ein Produktmerkmal ist. Wenn die Inferenzgeschwindigkeiten weiter steigen, wird das voraussichtlich noch wahrer werden.
Das größere Signal
Die tiefere Erkenntnis ist nicht nur, dass WebSockets schneller sind als wiederholte synchrone Aufrufe. Es geht darum, dass Agenten-Produkte zu Echtzeit-Softwaresystemen reifen, deren Leistung von der Koordination zwischen APIs, Caches, Safety-Layern und Tool-Runtimes abhängt.
Damit ist dieses Update mehr als eine technische Randnotiz. Es ist ein Zeichen dafür, dass die nächsten Gewinne bei der Nutzbarkeit von KI wahrscheinlich aus der Verringerung der Reibung zwischen Modellschritten kommen, nicht nur daraus, jeden einzelnen Schritt klüger zu machen. Wenn agentische Systeme längere und komplexere Aufgaben übernehmen, könnte genau dieser Unterschied entscheiden, ob sie experimentell oder operativ wirken.
Dieser Artikel basiert auf Berichten von OpenAI. Zum Originalartikel.
Originally published on openai.com
