Pabilisin ang mga agentic na workflow gamit ang WebSockets sa Responses API

Kapag hiniling mo sa Codex na ayusin ang bug, ini-scan nito ang iyong codebase para sa mga kaugnay na file, binabasa ang mga ito para mabuo ang konteksto, gumagawa ng mga pagbabago, at nagra-run ng mga test para matiyak na gumana ang pag-aayos. Sa likod ng mga operasyon, nangangahulugan iyon ng dose-dosenang pabalik-balik na mga request sa Responses API: tukuyin ang susunod na aksyon ng modelo, magpatakbo ng tool sa iyong computer, ipadala pabalik sa API ang output ng tool, at ulitin.

Lahat ng mga kahilingang ito ay maaaring umabot sa ilang minutong ginugugol ng mga user sa paghihintay na makumpleto ng Codex ang mga kumplikadong gawain. Mula sa pananaw ng latency, ginugugol ng Codex agent loop ang karamihan ng oras nito sa tatlong pangunahing yugto: pagtatrabaho sa mga serbisyo ng API (para i-validate at iproseso ang mga request), inference ng modelo, at oras sa panig ng client (pagpapatakbo ng mga tool at pagbuo ng konteksto ng modelo). Ang inference ay ang yugto kung saan tumatakbo ang modelo sa mga GPU para makabuo ng mga bagong token. Noong nakaraan, ang pagpapatakbo ng LLM inference sa mga GPU ang pinakamabagal na bahagi ng agentic loop, kaya madaling itago ang overhead ng serbisyo ng API. Habang mas bumibilis ang inference, mas nagiging kapansin-pansin ang pinagsama-samang API overhead mula sa agentic na rollout.

Sa post na ito, ipapaliwanag namin kung paano namin ginawang 40% na mas mabilis ang mga agent loop gamit ang API mula simula hanggang katapusan, na nagbibigay-daan sa mga user na maranasan ang pagtaas ng bilis ng inference mula 65 hanggang halos 1,000 token bawat segundo. Tinugunan namin ito sa pamamagitan ng pag-cache, pag-aalis ng mga hindi kailangang network hop, pagpapahusay sa aming safety stack para mabilis na matukoy ang mga isyu, at—pinakamahalaga sa lahat—pagbuo ng paraan para makagawa ng tuloy-tuloy na koneksyon sa Responses API, sa halip na kailangang gumawa ng sunod-sunod na synchronous na API call.

Sa Responses API, ang mga naunang pangunahing modelo tulad ng GPT‑5 at GPT‑5.2 ay nag-run sa humigit-kumulang 65 token bawat segundo (TPS). Para sa paglulunsad ng GPT‑5.3‑Codex‑Spark, isang mabilis na modelo para sa pagko-code, ang aming layunin ay maging sampung beses na mas mabilis: mahigit 1,000 TPS, na pinagana ng espesyal na Cerebras hardware na na-optimize para sa LLM inference. Para matiyak na maranasan ng mga user ang tunay na bilis ng bagong modelo na ito, kinailangan naming bawasan ang API overhead. 

Bandang Nobyembre, 2025, naglunsad kami ng performance sprint sa Responses API at nagpatupad ng maraming mga pag-optimize sa latency ng critical-path para sa isang kahilingan: 

• Pag-cache ng mga na-render na token at pag-configure ng modelo sa memorya para maiwasan ang magastos na pag-tokenize at mga tawag sa network para sa mga tugon na multi-turn
• Pagbabawas ng latency ng network hop sa pamamagitan ng pag-aalis ng mga tawag sa mga intermediate na serbisyo (halimbawa, resolusyon ng pagproseso ng image) at direktang pagtawag sa mismong inference service
• Pinapahusay ang aming safety stack para mapatakbo namin ang ilang classifier para mas mabilis na ma-flag ang mga pag-uusap

Sa mga pagpapahusay na ito, nakita namin ang halos 45% na pagbuti sa oras bago ang unang token (TTFT)—na sumasalamin sa kung gaano kabilis tumugon ang API—pero hindi pa rin sapat ang bilis ng mga pagpapahusay na ito para sa GPT‑5.3‑Codex‑Spark. Kahit na may mga pagpapabuting ito, masyado pa ring malaki ang overhead ng Responses API kumpara sa bilis ng modelo—ibig sabihin, kinailangan munang maghintay ng mga user sa mga CPU na nagpapatakbo ng aming API bago nila magamit ang mga GPU na nagseserbisa sa modelo.

Ang mas malalim na isyu ay istruktural: itinuring namin ang bawat request sa Codex na hiwalay, pinoproseso ang estado ng pag-uusap at iba pang magagamit muli na konteksto sa bawat follow-up na request. Kahit na karamihan ng pag-uusap ay hindi naman nagbago, nagbayad pa rin kami para sa trabahong nakatali sa buong kasaysayan. Habang humahaba ang mga pag-uusap, naging mas magastos ang paulit-ulit na pagpoprosesong iyon.

Para higpitan ang disenyo, muli naming pinag-isipan ang transport protocol: puwede ba tayong magpanatili ng persistent connection at mag-cache ng state, sa halip na magtatag ng bagong koneksyon sa HTTP at ipadala ang buong history ng pag-uusap sa bawat follow-up na request? Ang ideya ay ipadala lang ang anumang bagong impormasyong nangangailangan ng pag-validate at pagproseso at i-cache sa memory ang reusable na state habang aktibo ang connection. Makababawas ito sa overhead mula sa paulit-ulit na trabaho.

Isinaalang-alang namin ang ilang magkakaibang pamamaraan, kabilang ang WebSockets at gRPC bidirectional streaming. Pinili namin ang WebSockets dahil bilang isimpleng protokol para sa paghahatid ng mensahe, hindi na kailangang baguhin ng mga user ang mga hugis ng input at output ng kanilang Responses API. Pabor ito sa mga developer at umangkop sa aming umiiral na arkitektura nang may kaunting pagkaantala.

Binago ng unang WebSocket prototype ang inaakala naming posible para sa latency ng Responses API. Isang engineer sa team ng Codex na may malalim na kadalubhasaan sa buong API stack ang nakabuo ng prototype sa pamamagitan ng pagpapatakbo ng Codex agent magdamag.

Sa prototype na iyon, ang mga agentic rollout ay minodelo bilang iisang pangmatagalang Response. Gamit ang mga feature ng asyncio, iba-block nang asynchronous ang Responses API sa sampling loop pagkatapos ma-sample ang tool call, at magpapadala ang Responses API ng response.done event pabalik sa client. Pagkatapos isagawa ang tool call, magpapadala pabalik ang mga client ng event na response.append kasama ang resulta ng tool, na nag-a-unblock sa sampling loop at nagbigay-daan sa modelo na magpatuloy.

Isang analohiya rito ang pagtrato sa lokal na tool call na parang hosted tool call. Kapag tinatawag ng modelo ang web search, bina-block ng inference loop, tinatawag ang serbisyo sa web search, at inilalagay ang tugon ng serbisyo sa konteksto ng modelo. Sa aming disenyo, ginawa rin namin ito; pero sa halip na tumawag sa remote service, ipinadala namin pabalik sa client sa WebSocket ang tool call ng modelo. Nang tumugon ang client, inilagay namin sa konteksto ang tugon sa tool call ng client at ipinagpatuloy ang pag-sample.

Lubhang epektibo ang disenyong ito dahil inalis nito ang paulit-ulit na gawaing may kaugnayan sa API sa kabuuan ng paglulunsad ng agent. Maaari naming gawin ang preinference na gawain nang isang beses, huminto para sa pagpapatupad ng tool, at gawin ang postinference na gawain nang isang beses sa huli.

Sa kasamaang-palad, naging kapalit nito ang isang anyo ng API na hindi gaanong pamilyar at mas kumplikado. Gusto naming mabigyan ang mga developer ng kakayahang madaling magdagdag ng suporta para sa WebSocket nang hindi kinakailangang muling isulat ang kanilang API integration para umangkop sa bagong paraan ng pakikipag-ugnayan.

Para sa bersyong inilunsad namin, bumalik kami sa isang pamilyar na anyo: patuloy na gamitin ang response.create gamit ang parehong body, at gamitin ang previous_response_id para ipagpatuloy ang context ng pag-uusap mula sa state ng nakaraang response.

Sa WebSocket na koneksyon, nagpapanatili ang server ng cache sa memory na nakatalaga sa koneksyon para sa nakaraang estado ng tugon. Kapag ang kasunod na response.create ay may kasamang previous_response_id, kinukuha namin ang estadong iyon mula sa cache sa halip na muling buuin ang buong pag-uusap mula sa simula.

Kabilang sa naka-cache na estado ang:

• Ang nakaraang response object
• Mga naunang input at output na item
• Mga depinisyon ng tool at namespace
• Mga artifact ng sampling na magagamit muli, gaya ng mga dati nang na-render na token

Sa muling paggamit ng in-memory na nakaraang state ng tugon, nagawa naming maipatupad ang ilang malalaking pag-optimize:

• Pagpaproseso ng ilan sa aming mga safety classifier at request validator ng bagong input lang, hindi ng buong history sa bawat pagkakataon
• Pagpapanatili ng in-memory cache ng mga na-render na token na dinaragdagan namin para malaktawan ang hindi kinakailangang pag-tokenize
• Muling paggamit ng aming matagumpay na lohika ng pagresolba/pagruta ng modelo sa iba’t ibang kahilingan 
• Nagpapatong-patong na gawaing postinference na hindi humaharang tulad ng pagsingil sa mga kasunod na kahilingan

Ang layunin ay maging mas malapit hangga’t maaari sa prototype na may pinakamababang overhead pero may anyo ng API na nauunawaan na ng mga developer at ginagamit na nila sa pagbuo.

Pagkatapos ng dalawang buwang sprint sa pagbuo ng WebSocket mode, naglunsad kami ng alpha kasama ang mahahalagang startup ng coding agent para maisama nila ito sa kanilang imprastraktura at ligtas na mapataas ang traffic. Nagustuhan ito ng mga alpha user, na nag-ulat ng hanggang 40% na mga pagpapahusay⁠(magbubukas sa bagong window) sa kanilang mga agentic na workflow. Dahil sa positibong feedback sa alpha, handa na kaming ilunsad.

Agarang nakita ang mga resulta ng paglulunsad. Mabilis na inilipat ng Codex ang karamihan ng kanilang trapiko sa Responses API sa WebSocket mode, at nakakita ng makabuluhang mga pagpapabuti sa pagkaantala. Para sa GPT‑5.3‑Codex‑Spark, naabot namin ang aming target na 1,000 TPS at nakakita kami ng mga biglaang pagtaas hanggang 4,000 TPS, na nagpapakita na kayang sumabay ng Responses API sa mas mabilis na inference sa aktuwal na trapiko sa produksyon. Mabilis ding nakita ang epekto sa komunidad ng mga developer:

• Mabilis na inilipat ng Codex ang karamihan ng trapiko nito sa WebSockets. Mga gumagamit ng Codex na nagpapatakbo ng mga pinakabagong modelo gaya ng GPT‑5.3‑Codex⁠(magbubukas sa bagong window), GPT‑5.4⁠(magbubukas sa bagong window), at higit pa, makinabang sa pagpapabilis ng WebSocket mode.
• Isinama ng Vercel ang WebSocket mode sa AI SDK at nakitang bumaba ang latency nang hanggang 40%⁠(magbubukas sa bagong window).
• 39% mas mabilis⁠(magbubukas sa bagong window) ang mga multi-file na workflow ng Cline.
• Naging hanggang 30% na mas mabilis⁠(magbubukas sa bagong window) ang mga modelo ng OpenAI sa Cursor.

Isa sa pinakamahalagang bagong kakayahan sa Responses API ang WebSocket mode mula nang ilunsad ito noong Marso 2025. Mula sa ideya hanggang sa pagpapatakbo sa produksyon sa loob lang ng ilang linggo sa pamamagitan ng malapit na pakikipagtulungan sa pagitan ng mga API team ng OpenAI at Codex. Hindi lang nito lubos na pinapahusay ang latency ng rollout ng agent, kundi sinusuportahan din nito ang lumalaking pangangailangan ng mga builder: habang bumibilis ang inference ng modelo, kailangan ding bumilis ang mga serbisyo at system na nakapalibot sa inference para maipasa ang mga pakinabang na ito sa mga user.