Få opp farten på agentarbeidsflyter med WebSockets i Responses API

Når du ber Codex om å fikse en feil, skanner den gjennom kodebasen din etter relevante filer, leser dem for å bygge kontekst, gjør endringer og kjører tester for å bekrefte at feilen faktisk ble rettet. Bak kulissene betyr det dusinvis av Responses API-forespørsler fram og tilbake: bestemme modellens neste handling, kjøre et verktøy på datamaskinen din, sende verktøyutdataene tilbake til API-en og gjenta.

Alle disse forespørslene kan til sammen utgjøre flere minutter som brukerne venter på at Codex skal fullføre komplekse oppgaver. Fra et latensperspektiv bruker agentløkken i Codex mesteparten av tiden sin i tre hovedfaser: arbeid i API-tjenestene (for å validere og behandle forespørsler), modellinferens og tid på klientsiden (kjøring av verktøy og bygging av modellkontekst). Inferens er stadiet der modellen kjører på GPU-er for å generere nye tokens. Tidligere var kjøring av LLM-inferens på GPU-er den tregeste delen av agentløkken, så overhead fra API-tjenesten var lett å skjule. Etter hvert som inferens blir raskere, blir den kumulative API-overheaden fra en agentbasert utrulling langt mer merkbar.

I dette innlegget forklarer vi hvordan vi gjorde agent-løkkene ved hjelp av API-et 40 % raskere fra start til slutt, slik at brukerne kunne oppleve hoppet i inferenshastigheten fra 65 til nesten 1 000 token per sekund. Vi løste dette gjennom bufring, ved å eliminere unødvendige nettverkshopp, forbedre sikkerhetsstakken vår slik at problemer raskt kan flagges, og – viktigst av alt – ved å bygge en måte å opprette en vedvarende tilkobling til Responses API på, i stedet for å måtte gjøre en serie synkrone API-kall.

I Responses API kjørte tidligere flaggskipmodeller som GPT‑5 og GPT‑5.2 med omtrent 65 token per sekund (TPS). For lanseringen av GPT‑5.3‑Codex‑Spark, en rask modell, var målet vårt å være ti ganger raskere: over 1 000 TPS, muliggjort av spesialisert Cerebras-maskinvare optimalisert for LLM-inferens. For å sikre at brukerne kunne oppleve den faktiske hastigheten til denne nye modell, måtte vi redusere API-overhead. 

Rundt november 2025 lanserte vi en ytelsessprint for Responses API-en, der vi implementerte mange optimaliseringer av latensen i den kritiske banen for en enkelt forespørsel: 

• Bufring av gjengitte tokens og modellkonfigurasjon i minnet for å unngå ressurskrevende tokenisering og nettverkskall for flerturnssvar
• Redusere latens fra nettverkshopp ved å eliminere kall til mellomliggende tjenester (for eksempel oppløsning for bildebehandling) og kalle inferenstjenesten direkte
• Forbedring av sikkerhetsstrukturen vår slik at vi kunne kjøre visse klassifikatorer for å flagge samtaler raskere

Med disse forbedringene så vi nesten 45 % forbedring i tid til første token (TTFT) – noe som gjenspeiler hvor responsiv API-en oppleves – men disse forbedringene var fortsatt ikke raske nok for GPT‑5.3‑Codex‑Spark. Selv med disse forbedringene var overheaden i Responses API-en for stor sammenlignet med modellens hastighet – det vil si at brukerne måtte vente på CPU-ene som kjørte API-et før de kunne bruke GPU-ene som betjente modellen.

Det underliggende problemet var strukturelt: Vi behandlet hver Codex-forespørsel som uavhengig, ved å behandle samtaletilstand og annen gjenbrukbar kontekst i hver oppfølgingsforespørsel. Selv når mesteparten av samtalen ikke hadde endret seg, betalte vi fortsatt for arbeid knyttet til hele historikken. Etter hvert som samtalene ble lengre, ble den gjentatte behandlingen dyrere.

For å stramme opp designet tenkte vi nytt om transportprotokollen: kunne vi beholde en vedvarende tilkobling og bufre tilstand, i stedet for å opprette en ny tilkobling over HTTP og sende hele samtaleloggen for hver oppfølgende forespørsel? Tanken var å bare sende ny informasjon som krevde validering og behandling, og bufre gjenbrukbar tilstand i minnet så lenge tilkoblingen varte. Dette ville redusere belastningen fra unødvendig arbeid.

Vi vurderte noen forskjellige tilnærminger, inkludert WebSockets og toveis gRPC-strømming. Vi landet på WebSockets fordi brukerne, med det som en enkel protokoll for meldingstransport, ikke måtte endre inndata- og utdataformatene sine for Responses API. Det var utviklervennlig og passet godt inn i den eksisterende arkitekturen vår med få forstyrrelser.

Den første WebSocket-prototypen endret hva vi trodde var mulig når det gjelder latens i Responses API-et. En ingeniør i Codex-teamet med dyp ekspertise på tvers av API-stakken satte sammen en prototype ved å kjøre en Codex-agent over natten.

I den prototypen ble agentiske utrullinger modellert som én enkelt langvarig respons. Ved bruk av funksjoner i asyncio ville Responses API blokkere asynkront i samplingsløkken etter at et verktøykall var samplet, og Responses API ville sende en response.done -hendelse tilbake til klienten. Etter å ha utført verktøykallet ville klientene sende tilbake en response.append -hendelse med verktøyresultatet, noe som opphevet blokkeringen av samplingsløkken og lot modellen fortsette.

En analogi her er å behandle det lokale verktøykallet som et driftet verktøykall. Når modell kaller nettsøk, blokkerer inferenssløyfen, kaller en nettsøktjeneste og legger tjenestesvaret inn i modellkonteksten. I vårt design gjorde vi det samme; men i stedet for å kalle en ekstern tjeneste sendte vi modellens verktøykall tilbake til klienten over WebSocket-tilkoblingen. Da klienten svarte, la vi svaret på klientens verktøykall inn i konteksten og fortsatte vi å sample.

Dette designet var svært effektivt fordi det eliminerte gjentatt API-arbeid på tvers av en agentutrulling. Vi kunne gjøre arbeid før inferens én gang, sette på pause for verktøykjøring og gjøre arbeid etter inferens én gang til slutt.

Dessverre skjedde dette på bekostning av en mindre kjent og mer komplisert API-utforming. Vi ønsket at utviklere skulle kunne legge til WebSocket-støtte uten å måtte skrive om API-integrasjonen sin rundt en ny samhandlingsmåte.

For versjonen vi lanserte, gikk vi tilbake til en velkjent form: fortsett å bruke response.create med samme body, og bruk previous_response_id til å videreføre samtalekonteksten fra tilstanden til forrige svar.

I en WebSocket-tilkobling opprettholder serveren en tilkoblingsavgrenset hurtigbuffer i minnet for tidligere svartilstand. Når en oppfølgende response.create inkluderer previous_response_id, henter vi denne tilstanden fra hurtiglageret i stedet for å bygge opp hele samtalen fra bunnen av.

Den bufrede tilstanden inkluderer:

• Det forrige response -objektet
• Tidligere inndata- og utdataelementer
• Verktøydefinisjoner og navnerom
• Gjenbrukbare samplingartefakter, som tidligere genererte tokens

Ved å gjenbruke den forrige svartilstanden i minnet kunne vi gjennomføre flere store optimaliseringer:

• Å la noen av sikkerhetsklassifikatorene og forespørselsvalidatorene våre bare behandle nye inndata, ikke hele historikken hver gang
• Beholder en hurtigbuffer i minnet med gjengitte token som vi legger til i, slik at vi kan hoppe over unødvendig tokenisering
• Gjenbruk av den vellykkede logikken vår for modelloppløsning/-ruting på tvers av forespørsler 
• Overlappende ikke-blokkerende arbeid etter inferens, som fakturering, med påfølgende forespørsler

Målet var å komme så nær som mulig prototypen med minst mulig overhead, men med en API-form som utviklere allerede forsto og bygde rundt.

Etter en to måneder lang sprint med å bygge WebSocket-modus lanserte vi en alfa med ledende oppstartsbedrifter innen agent, slik at de kunne integrere den i infrastrukturen sin og trygt skalere trafikken gradvis. Alfabrukere elsket det og rapporterte forbedringer på opptil 40 %⁠(åpnes i et nytt vindu) i sine agentiske arbeidsflyter. Gitt de positive tilbakemeldingene fra alfaversjonen var vi klare til lansering.

Resultatene av lanseringen kom umiddelbart. Codex flyttet raskt mesteparten av trafikken sin i Responses API over til WebSocket-modus, og oppnådde betydelige forbedringer i latens. For GPT‑5.3‑Codex‑Spark nådde vi målet vårt på 1 000 TPS og så topper på opptil 4 000 TPS, noe som viste at Responses API kunne holde tritt med langt raskere inferens i ekte produksjonstrafikk. Effekten kom raskt også i utviklermiljøet:

• Codex flyttet raskt mesteparten av trafikken sin over til WebSockets. Codex-brukere som kjører de nyeste modellene som GPT‑5.3‑Codex⁠(åpnes i et nytt vindu), GPT‑5.4⁠(åpnes i et nytt vindu), og dra nytte av hastighetsøkningen i WebSocket-modus.
• Vercel integrerte WebSocket-modus i AI SDK og så at responstiden ble redusert med opptil 40 %⁠(åpnes i et nytt vindu).
• Clines arbeidsflyter med flere filer er 39 % raskere⁠(åpnes i et nytt vindu).
• OpenAI-modell i Cursor ble opptil 30 % raskere⁠(åpnes i et nytt vindu).

WebSocket-modus er en av de mest betydningsfulle nye funksjonene i Responses API siden lanseringen i mars 2025. Vi gikk fra idé til produksjon på bare noen få uker gjennom tett samarbeid mellom OpenAIs API- og Codex-team. Det forbedrer ikke bare utrullingslatensen for agenter dramatisk, men støtter også et voksende behov blant utviklere: Når modellinferens blir raskere, må tjenestene og systemene som omgir inferensen også bli raskere for å overføre disse gevinstene til brukerne.