Påskynda agentbaserade arbetsflöden med WebSockets i Responses APIPP

När du ber Codex att åtgärda en bugg söker den igenom din kodbas efter relevanta filer, läser dem för att skapa kontext, gör ändringar och kör tester för att verifiera att åtgärden lyckades. Bakom kulisserna innebär det dussintals förfrågningar fram och tillbaka till/från Responses API: Fastställ modellens nästa åtgärd, kör ett verktyg på din dator, skicka verktygsutdata tillbaka till API:et och upprepa.

Alla dessa förfrågningar kan tillsammans innebära att användare får vänta i flera minuter på att Codex ska slutföra komplexa uppgifter. Ur ett latensperspektiv tillbringar Codex agentloop större delen av tiden i tre huvudsakliga steg: arbete i API-tjänsterna (för att validera och behandla förfrågningar), modellinferens och tid på klientsidan (för att köra verktyg och bygga modellkontext). Inferens är det steg där modellen körs på GPU:er för att generera nya tokens. Tidigare var inferens för stora LLM:er på GPU:er den långsammaste delen av den agentiska loopen, vilket gjorde att overheaden i API-tjänsterna var lätt att dölja. I takt med att inferensen blir snabbare blir den samlade overheaden i API-tjänsterna under en agentisk körning betydligt mer märkbar.

I det här inlägget förklarar vi hur vi gjorde agentloopar som använder API:et 40 % snabbare från början till slut, vilket gör att användarna faktiskt märker ökningen i inferenshastighet från 65 till nästan 1 000 token per sekund. Vi uppnådde detta genom cachning, genom att eliminera onödiga nätverkshopp, förbättra vår säkerhetsstack så att problem kan flaggas snabbt och – viktigast av allt – genom att bygga ett sätt att skapa en beständig anslutning till Responses API i stället för att behöva göra en serie synkrona API-anrop.

I Responses API körde tidigare flaggskeppsmodeller som GPT‑5 och GPT‑5.2 med ungefär 65 token per sekund (TPS). Vid lanseringen av GPT‑5.3‑Codex‑Spark, en snabb modell för kodning, var vårt mål att vara tio gånger snabbare: över 1 000 TPS, tack vare specialiserad Cerebras-hårdvara optimerad för LLM-inferens. För att säkerställa att användarna kunde uppleva den verkliga hastigheten hos den här nya modellen var vi tvungna att minska API-belastningen. 

Omkring november 2025 inledde vi en prestandasprint för Responses API, där vi genomförde många optimeringar av latensen i den kritiska sökvägen för en enskild begäran. 

• Cacha renderade tokens och modellkonfiguration i minnet för att undvika kostsam tokenisering och nätverksanrop vid fleromgångssvar
• Minskad latens från nätverkshopp genom att eliminera anrop till mellanliggande tjänster (till exempel upplösning vid bildbehandling) och anropa inferenstjänsten direkt
• Förbättra vår säkerhetsstack så att vi kunde köra vissa klassificerare för att flagga samtal snabbare

Med dessa förbättringar såg vi nästan 45 % förbättring i tid till första token (TTFT) – vilket återspeglar hur responsivt API:et känns – men dessa förbättringar var fortfarande inte tillräckligt snabba för GPT‑5.3‑Codex‑Spark. Trots dessa förbättringar var omkostnaderna för Responses API fortfarande för stora i förhållande till modellens hastighet, det vill säga att användarna var tvungna att vänta på de processorer som körde vårt API innan de kunde använda de grafikprocessorer som servade modellen.

Det djupare problemet var strukturellt: Vi behandlade varje Codex-begäran som fristående och bearbetade konversationens tillstånd och annan återanvändbar kontext i varje efterföljande begäran. Även när större delen av konversationen inte hade ändrats betalade vi fortfarande för arbete som var knutet till hela historiken. När samtalen blev längre blev den upprepade bearbetningen dyrare.

För att förbättra designen omvärderade vi transportprotokollet: Kunde vi behålla en beständig anslutning och lagra tillstånd i cache, istället för att skapa en ny anslutning via HTTP och skicka hela konversationshistoriken för varje uppföljningsförfrågan? Tanken var att endast skicka ny information som behövde valideras och bearbetas samt lagra återanvändbart tillstånd i minnet under anslutningens livstid. Detta skulle minska arbetsbördan från överflödigt arbete.

Vi övervägde några olika metoder, inklusive WebSockets och gRPC-dubbelriktad strömning. Vi valde WebSockets eftersom det är ett enkelt protokoll för meddelandeöverföring, vilket innebär att användarna inte behövde ändra sina in- och utdataformat för Responses API. Det var utvecklarvänligt och passade väl in i vår befintliga arkitektur med minimala störningar.

Den första WebSocket-prototypen förändrade vad vi trodde var möjligt för latensen i Responses API. En ingenjör i Codex-teamet med djup expertis inom hela API-stacken tog fram en prototyp genom att köra en Codex-agent över natten.

I den prototypen modellerades agentiska körningar som ett enda långvarigt Response-objekt. Med hjälp av funktioner i asyncio blockerade Responses API asynkront i samplingsloopen efter att ett verktygsanrop hade genererats, och skickade sedan tillbaka en response.done-händelse till klienten. När verktygsanropet hade körts skickade klienten tillbaka en response.append-händelse med verktygsresultatet, vilket avblockerade samplingsloopen och gjorde att modellen kunde fortsätta.

En liknelse här är att se det lokala verktygsanropet som ett värdbaserat verktygsanrop. När modellen anropar webbsökning blockeras inferensloopen, en webbsökningstjänst anropas och tjänstens svar placeras i modellens kontext. I vår design gjorde vi samma sak, men i stället för att anropa en fjärrtjänst skickade vi modellens verktygsanrop tillbaka till klienten via WebSocket-anslutningen. När klienten svarade lade vi klientens verktygsanropssvar i kontexten och fortsatte att generera.

Den här designen var mycket effektiv eftersom den eliminerade upprepat API-arbete vid en agents utrullning. Vi kunde utföra arbete före inferens en gång, pausa för verktygskörning och sedan utföra arbete efter inferens en gång i slutet.

Tyvärr skedde detta på bekostnad av en mindre välbekant och mer komplicerad API-utformning. Vi ville göra det möjligt för utvecklare att lägga till stöd för WebSocket utan att behöva skriva om sin API-integration kring ett nytt interaktionssätt.

För den version vi lanserade gick vi tillbaka till ett välbekant upplägg: Att fortsätta använda response.create med samma brödtext, och använda previous_response_id för att fortsätta konversationens kontext utifrån den föregående responsens tillstånd.

På en WebSocket-anslutning håller servern en anslutningsspecifik cache i minnet för tidigare svarstillstånd. När en efterföljande response.create innehåller previous_response_id hämtar vi tillståndet från cachen istället för att bygga upp hela konversationen från grunden.

Det cachelagrade tillståndet inkluderar:

• Det föregående response-objektet
• Tidigare indata- och utdataobjekt
• Verktygsdefinitioner och namnrymder
• Återanvändbara artefakter för sampling, som tidigare renderade tokens

Genom att återanvända det tidigare svarstillståndet i minnet kunde vi genomföra flera större optimeringar:

• Låta vissa av våra säkerhetsklassificerare och begärandevalidatorer bara bearbeta nya indata, inte hela historiken varje gång
• Behålla en cache i minnet med renderade token som vi successivt lägger till i, så att vi kan hoppa över onödig tokenisering.
• Återanvända vår framgångsrika logik för modellupplösning och dirigering mellan förfrågningar 
• Överlappande icke-blockerande arbete efter inferens, såsom fakturering, med efterföljande förfrågningar

Målet var att komma så nära som möjligt en prototyp med minimal overhead, men med en API-struktur som utvecklare redan förstod och hade byggt kring.

Efter en två månader lång sprint för att bygga WebSocket-läget lanserade vi en alfaversion tillsammans med ledande startups inom kodagenter, så att de kunde integrera lösningen i sin infrastruktur och successivt skala upp trafiken på ett säkert sätt. Alfaanvändarna gillade detta skarpt och rapporterade förbättringar på upp till 40 %⁠(öppnas i ett nytt fönster) i sina agentiska arbetsflöden. Med tanke på den positiva feedbacken från alfaversionen var vi redo att lansera.

Resultaten av lanseringen kom omedelbart. Codex styrde snabbt över merparten av sin trafik för Responses API till WebSocket-läge och såg betydande latensförbättringar. För GPT‑5.3‑Codex‑Spark nådde vi vårt mål på 1 000 TPS och såg toppar på upp till 4 000 TPS, vilket visade att Responses API kunde hålla jämna steg med betydligt snabbare inferens i verklig produktionstrafik. Effekten visade sig snabbt också i utvecklarcommunityt:

• Codex överförde snabbt majoriteten av sin trafik till WebSockets. Codex-användare som kör de senaste modellerna som GPT‑5.3‑Codex⁠(öppnas i ett nytt fönster), GPT‑5.4⁠(öppnas i ett nytt fönster) och senare drar alla nytta av WebSocket-lägets snabbare konfiguration.
• Vercel integrerade WebSocket-läge i AI SDK och upplevde en minskad latens med upp till 40 %⁠(öppnas i ett nytt fönster).
• Clines arbetsflöden för flera filer är 39 % snabbare⁠(öppnas i ett nytt fönster).
• OpenAI-modeller i Cursor blev upp till 30 % snabbare⁠(öppnas i ett nytt fönster).

WebSocket-läget är en av de mest betydelsefulla nya funktionerna i Responses API sedan lanseringen i mars 2025. Vi gick från idé till drift i produktion på bara några veckor genom ett nära samarbete mellan OpenAI:s API- och Codex-team. Det förbättrar inte bara latensen för agentutrullning dramatiskt, utan stöder också ett växande behov hos utvecklare: i takt med att modellinferens blir snabbare måste även de tjänster och system som omger inferensen snabbas upp för att föra vidare dessa förbättringar till användarna.