Snellere agentic workflows met WebSockets in de Responses API

Wanneer je Codex vraagt een bug te verhelpen, doorzoekt het je codebase naar relevante bestanden, leest het deze om context op te bouwen, brengt het wijzigingen aan en voert het tests uit om te controleren of de oplossing werkt. Achter de schermen betekent dat tientallen heen-en-weergaande requests aan de Responses API: de volgende actie van het model bepalen, een tool op je computer uitvoeren, de tooluitvoer terugsturen naar de API en dat herhalen.

Al deze verzoeken kunnen ertoe leiden dat gebruikers minutenlang moeten wachten terwijl Codex complexe taken uitvoert. Qua latentie brengt de agentlus van Codex het grootste deel van de tijd door in drie hoofdfasen: verwerking in de API-services (om verzoeken te valideren en te verwerken), modelinferentie en client-side verwerking (zoals het uitvoeren van tools en het opbouwen van modelcontext). Inferentie is de fase waarin het model op GPU’s draait om nieuwe tokens te genereren. In het verleden was LLM-inferentie op GPU’s het traagste onderdeel van de agentlus, waardoor de overhead van API-services makkelijk verborgen bleef. Nu inferentie sneller wordt, valt de opgetelde API-overhead binnen een agentic workflow veel meer op.

In deze post leggen we uit hoe we agentlussen via de API end-to-end 40% sneller hebben gemaakt. Daardoor hebben gebruikers meer profijt van de hogere inferentiesnelheid, die van 65 naar bijna 1.000 tokens per seconde is gestegen. Dat hebben we bereikt met caching, het wegnemen van onnodige netwerkstappen, verbeteringen aan onze veiligheidsstack om problemen sneller te signaleren en, het belangrijkst, door een persistente verbinding met de Responses API mogelijk te maken in plaats van een reeks synchrone API-aanroepen.

In de Responses API draaiden eerdere vlaggenschipmodellen zoals GPT‑5 en GPT‑5.2 met ongeveer 65 tokens per seconde (TPS). Voor de lancering van GPT‑5.3‑Codex‑Spark, een snel model, was ons doel om een orde van grootte sneller te zijn: meer dan 1.000 TPS, mogelijk gemaakt door gespecialiseerde Cerebras-hardware die is geoptimaliseerd voor LLM-inferentie. Om ervoor te zorgen dat gebruikers de werkelijke snelheid van dit nieuwe model konden ervaren, moesten we de API-overhead verminderen. 

Rond november 2025 zijn we gestart met een prestatiesprint voor de Responses API, waarbij we veel optimalisaties hebben doorgevoerd in de latentie van het kritieke pad voor een aanvraag: 

• Tokens en modelconfiguratie cachen voor minder tokenisatie en minder netwerkaanroepen bij meerstapsreacties
• Het verminderen van netwerkhop-latentie door aanroepen naar tussenliggende services (bijvoorbeeld beeldverwerkingsresolutie) te elimineren en rechtstreeks de inferentieservice zelf aan te roepen
• Onze beveiligingsstack verbeteren zodat we bepaalde classifiers konden uitvoeren om gesprekken sneller te markeren

Met deze verbeteringen zagen we een verbetering van bijna 45% in de time-to-first-token (TTFT), wat aantoont hoe responsief de API aanvoelt. Maar deze verbeteringen waren nog steeds niet snel genoeg voor GPT‑5.3‑Codex‑Spark. Zelfs met deze verbeteringen was de overhead van de Responses API te groot in verhouding tot de snelheid van het model, dat wil zeggen dat gebruikers moesten wachten op de CPU's waarop onze API draaide voordat ze de GPU's konden gebruiken waarop het model draaide.

Het dieperliggende probleem was structureel: we behandelden elk Codex-verzoek als onafhankelijk, waarbij we de gespreksstatus en andere herbruikbare context in elk vervolgverzoek verwerkten. Zelfs wanneer het grootste deel van het gesprek niet was veranderd, betaalden we nog steeds voor werk dat gekoppeld was aan de volledige geschiedenis. Naarmate gesprekken langer werden, werd die herhaalde verwerking duurder.

Om het ontwerp te vereenvoudigen en efficiënter te maken, hebben we het transportprotocol opnieuw bekeken: konden we een persistente verbinding behouden en status in cache houden, in plaats van voor elk vervolgverzoek opnieuw via HTTP een verbinding op te zetten en de volledige gespreksgeschiedenis mee te sturen? Het idee was om alleen nieuwe informatie te versturen die validatie en verwerking vereist, en herbruikbare status voor de duur van de verbinding in het geheugen te bewaren. Zo konden we de overhead van dubbel werk verminderen.

We hebben een paar verschillende benaderingen overwogen, waaronder WebSockets en gRPC bidirectional streaming. We zijn uitgekomen op WebSockets, omdat gebruikers als eenvoudig protocol voor berichttransport hun input- en outputstructuren voor de Responses API niet hoefden te wijzigen. Het was ontwikkelaarsvriendelijk en paste goed binnen onze bestaande architectuur zonder veel verstoring.

Met het eerste WebSocket-prototype bleek veel lagere latency mogelijk voor de Responses API dan we hadden verwacht. Een ingenieur in het Codex-team met diepgaande expertise in de volledige API-stack stelde een prototype samen door ’s nachts een Codex-agent te laten draaien.

In dat prototype werden agentic roll-outs gemodelleerd als één langlopende Response. Met behulp van asyncio-functionaliteit blokkeerde de Responses API asynchroon in de samplingloop nadat een toolaanroep was geselecteerd, en stuurde de Responses API een response.done-event terug naar de client. Na het uitvoeren van de toolaanroep stuurden clients een response.append-event terug met het resultaat van de tool. Daarmee werd de samplingloop hervat en kon het model doorgaan.

Je kunt dit zien als het behandelen van een lokale toolaanroep alsof het een gehoste toolaanroep is. Wanneer het model web search aanroept, pauzeert de inferentielus, roept een webzoekservice aan en voegt het antwoord van die service toe aan de modelcontext. In ons ontwerp deden we hetzelfde, maar in plaats van een externe service aan te roepen, stuurden we de toolaanroep van het model via de WebSocket terug naar de client. Zodra de client reageerde, voegden we het resultaat van de toolaanroep toe aan de context en ging het model verder met genereren.

Dit ontwerp was uiterst effectief omdat het herhaald API-werk tijdens de uitrol van een agent overbodig maakte. We zouden één keer pre-inferentiewerk kunnen doen, pauzeren voor het uitvoeren van tools, en aan het einde één keer post-inferentiewerk doen.

Helaas ging dit ten koste van een minder vertrouwde en ingewikkeldere API-opzet. We wilden dat ontwikkelaars WebSocket-ondersteuning konden toevoegen zonder hun API-integratie te hoeven herschrijven rond een nieuwe interactiemodus.

Voor de versie die we hebben gelanceerd, zijn we teruggegaan naar een vertrouwde vorm: blijf response.create met dezelfde body gebruiken en gebruik previous_response_id om de gesprekscontext voort te zetten vanuit de status van de vorige response.

Bij een WebSocket-verbinding houdt de server een verbindingsgebonden in-memorycache bij van de status van eerdere responses. Wanneer een vervolg-response.create previous_response_id bevat, halen we die status op uit de cache in plaats van het volledige gesprek helemaal vanaf het begin opnieuw op te bouwen.

Die in cache opgeslagen status omvat:

• Het vorige response-object
• Eerdere invoer- en uitvoeritems
• Tooldefinities en namespaces
• Herbruikbare sampling-artefacten, zoals eerder gerenderde tokens

Door de eerdere responsstatus in het geheugen te hergebruiken, konden we verschillende belangrijke optimalisaties doorvoeren:

• Sommige van onze veiligheidsclassifiers en aanvraagvalidators zo aanpassen dat ze alleen nieuwe input verwerken, in plaats van telkens de volledige geschiedenis
• Een in-memorycache van gerenderde tokens bijhouden en uitbreiden, zodat we onnodige tokenisatie kunnen overslaan
• Onze succesvolle modelafhandelings- en routeringslogica hergebruiken voor verschillende verzoeken 
• Niet-blokkerend post-inferentiewerk, zoals facturering, laten overlappen met daaropvolgende verzoeken

Het doel was om zo dicht mogelijk in de buurt te komen van het prototype met minimale overhead, maar dan met een API-structuur die ontwikkelaars al begrepen en waarop ze al bouwden.

Na een sprint van twee maanden waarin we de WebSocket-modus bouwden, brachten we een alfaversie uit voor toonaangevende startups op het gebied van programmeeragents, zodat zij deze in hun infrastructuur konden integreren en het verkeer veilig konden opschalen. Alphagebruikers waren er enthousiast over en meldden tot 40% verbeteringen⁠(opent in een nieuw venster) in hun agentic workflows. Gezien de positieve feedback uit de alfafase waren we klaar voor de lancering.

De resultaten van de lancering waren onmiddellijk. Codex heeft het merendeel van hun Responses API-verkeer snel naar de WebSocket-modus overgezet, wat leidde tot aanzienlijke verbeteringen in latentie. Voor GPT‑5.3‑Codex‑Spark haalden we onze doelstelling van 1.000 TPS en zagen we pieken tot 4.000 TPS, wat aantoonde dat de Responses API gelijke tred kon houden met veel snellere inferentie in echt productie-verkeer. De impact was ook snel zichtbaar in de ontwikkelaarscommunity:

• Codex heeft het merendeel van hun verkeer snel overgezet op WebSockets. Codex-gebruikers die de nieuwste modellen gebruiken, zoals GPT‑5.3‑Codex⁠(opent in een nieuw venster), GPT‑5.4⁠(opent in een nieuw venster) en toekomstige modellen, profiteren allemaal van de snelheidswinst van de WebSocket-modus.
• Vercel integreerde de WebSocket-modus in de AI SDK en zag de latentie met tot wel 40%⁠(opent in een nieuw venster) afnemen.
• Cline’s multi-file workflows zijn 39% sneller⁠(opent in een nieuw venster).
• OpenAI-modellen in Cursor werden tot 30% sneller⁠(opent in een nieuw venster).

De WebSocket-modus is een van de belangrijkste nieuwe mogelijkheden in de Responses API sinds de lancering ervan in maart 2025. Dankzij de nauwe samenwerking tussen de API- en Codex-teams van OpenAI gingen we in slechts een paar weken van idee naar een productieklare oplossing. Het verbetert niet alleen de latentie bij het uitrollen van agents aanzienlijk, maar ondersteunt ook in een groeiende behoefte van bouwers: naarmate model-inferentie sneller wordt, moeten de services en systemen rondom inferentie ook sneller worden om deze winst aan gebruikers door te geven.