Pospeševanje agentskih delovnih tokov z uporabo WebSockets v Responses API

Ko Codexu napišete, naj odpravi napako, pregleda vašo kodno zbirko, poišče ustrezne datoteke, jih prebere za pridobitev konteksta, izvede spremembe in zažene teste za preverjanje odprave napake. V ozadju to pomeni na desetine izmeničnih zahtev za API Responses: določiti naslednje dejanje modela, zagnati orodje na računalniku, poslati rezultat orodja nazaj v API in ponoviti.

Vse te zahteve lahko pomenijo več minut čakanja uporabnikov, da Codex dokonča zahtevne naloge. Z vidika latence zanka agenta Codex večino časa porabi v treh glavnih fazah: delovanje v API storitvah (za preverjanje veljavnosti in obdelavo zahtevkov), sklepanje modela in čas na strani odjemalca (izvajanje orodij in gradnja konteksta modela). Inferenca je faza, ko se model izvaja na grafičnih procesorjih (GPU-jih) za generiranje novih žetonov. V preteklosti je bila inferenca velikega jezikovnega modela na grafičnih procesorjih najpočasnejši del zanke agenta, zato je bilo režijske stroške storitve API preprosto prikriti. Ko inferenca postaja hitrejša, je kumulativna režija API-ja pri uvajanju agenta veliko bolj opazna.

V tej objavi bomo pojasnili, kako smo z uporabo API zanke agenta od začetka do konca pospešili za 40 %, kar uporabnikom omogoča, da izkusijo skok hitrosti sklepanja s 65 na skoraj 1.000 žetonov na sekundo. To smo dosegli z uporabo predpomnjenja, odpravo nepotrebnih omrežnih skokov, izboljšanjem našega varnostnega sklopa za hitro zaznavanje težav in, kar je najpomembneje, vzpostavitvijo načina za ustvarjanje trajne povezave z Responses API, namesto da bi morali izvesti vrsto sinhronih klicev API-ja.

V API-ju za odgovore so prejšnji osrednji modeli, kot sta GPT‑5 in GPT‑5.2, delovali s približno 65 žetoni na sekundo (TPS). Ob predstavitvi GPT‑5.3‑Codex‑Spark, hitrega modela za programiranje, je bil naš cilj doseči za velikostni razred večjo hitrost: več kot 1.000 TPS, kar omogoča specializirana strojna oprema Cerebras, optimizirana za veliki jezikovni model. Da bi zagotovili, da bi uporabniki lahko izkusili dejansko hitrost tega novega modela, smo morali zmanjšati režijo API-ja. 

Novembra 2025 smo začeli sprint za izboljšanje zmogljivosti Responses API in uvedli številne optimizacije zakasnitve na ključni poti za posamezno zahtevo: 

• Predpomnjenje žetonov in konfiguracije modela v pomnilniku omogoča preskok zahtevne tokenizacije in omrežnih klicev pri odgovorih v več korakih
• Zmanjšanje zakasnitve omrežnih skokov z odpravo klicev v vmesne storitve (na primer ločljivosti pri obdelavi slik) in z neposrednim klicanjem same storitve sklepanja
• Izboljšanje našega varnostnega sklopa, da bi lahko izvajali določene klasifikatorje za hitrejše označevanje pogovorov

S temi izboljšavami smo dosegli skoraj 45-odstotno izboljšanje časa do prvega žetona (TTFT), kar odraža, kako odziven je API, vendar te izboljšave še vedno niso bile dovolj hitre za GPT‑5.3‑Codex‑Spark. Tudi s temi izboljšavami so bili režijski stroški Responses API glede na hitrost modela preveliki. To pomeni, da so morali uporabniki čakati na procesorje CPU, ki poganjajo naš API, preden so lahko uporabili procesorje GPU, ki strežejo modelu.

Globlji problem je bil strukturne narave: vsako zahtevo za Codex smo obravnavali kot neodvisno, pri čemer smo pri vsaki nadaljnji zahtevi obdelali stanje pogovora in drug kontekst, ki ga je bilo mogoče ponovno uporabiti. Tudi kadar se večina pogovora ni spremenila, smo še vedno plačevali za delo, povezano s celotno zgodovino. Ko so pogovori postajali daljši, je to ponavljajoče procesiranje postajalo dražje.

Da bi izboljšali zasnovo, smo znova premislili transportni protokol: ali bi lahko ohranili trajno povezavo in stanje shranjevali v predpomnilnik, namesto da bi za vsako nadaljnjo zahtevo vzpostavili novo povezavo prek protokola HTTP in pošiljali celotno zgodovino pogovora? Ideja je bila, da se pošljejo samo nove informacije, ki zahtevajo preverjanje in obdelavo, ter da se ponovno uporabno stanje predpomni v pomnilniku za čas trajanja povezave. To bi zmanjšalo režijo zaradi podvojenega dela.

Preučili smo nekaj različnih pristopov, vključno z WebSockets in dvosmernim pretakanjem prek gRPC. Odločili smo se za WebSockets, ker uporabnikom kot preprost protokol za prenos sporočil ne bi bilo treba spreminjati struktur vhodnih in izhodnih podatkov v Responses API-ju. Bil je prijazen razvijalcem in se je z minimalnimi motnjami prilegal naši obstoječi arhitekturi.

Prvi prototip WebSocketa je spremenil naše predstave o tem, kaj je mogoče glede zakasnitve API-ja za odgovore. Inženir ekipe Codex z bogatim strokovnim znanjem o celotnem API-skladu je pripravil prototip tako, da je čez noč zagnal agenta Codex.

V tem prototipu so bila agentska izvajanja modelirana kot en sam dolgotrajen odziv. Z uporabo funkcij asyncio bi se API Responses po vzorčenju klica orodja asinhrono blokiral v zanki vzorčenja, nato pa bi API Responses odjemalcu poslal dogodek response.done. Po izvedbi priklica orodja bi odjemalci poslali dogodek response.append z rezultatom orodja, kar je deblokiralo zanko vzorčenja in modelu omogočilo nadaljevanje.

Analogija tukaj je, da lokalni klic orodja obravnavamo kot klic orodja v gostovanju. Ko model prikliče spletno iskanje, se zanka sklepanja blokira, pokliče storitev spletnega iskanja in odziv storitve vstavi v kontekst modela. V naši zasnovi smo storili enako; vendar smo namesto klica oddaljene storitve priklic orodja modela poslali nazaj odjemalcu prek povezave WebSocket. Ko se je odjemalec odzval, smo odziv odjemalca na klic orodja vključili v kontekst in nadaljevali z vzorčenjem.

Ta zasnova je bila izjemno učinkovita, ker je med uvajanjem agenta odpravila ponavljajoče se delo z API-jem. Predhodno inferenco bi lahko opravili enkrat, se začasno ustavili za izvajanje orodja in poinferenčno delo opravili enkrat na koncu.

Žal je to pomenilo manj znano in bolj zapleteno obliko API-ja. Želeli smo, da bi razvijalci lahko preprosto dodali podporo za WebSocket, ne da bi morali zaradi novega načina interakcije na novo napisati svojo API-integracijo.

Za različico, ki smo jo zagnali, smo se vrnili k znani obliki: še naprej uporabljajte response.create z istim telesom in uporabite previous_response_id za nadaljevanje konteksta pogovora iz stanja prejšnjega odgovora.

Pri povezavi WebSocket strežnik ohranja predpomnilnik v pomnilniku, vezan na povezavo, za prejšnje stanje odziva. Ko nadaljnji response.create vključuje previous_response_id, to stanje pridobimo iz predpomnilnika, namesto da bi celoten pogovor sestavili znova od začetka.

To predpomnjeno stanje vključuje:

• Prejšnji objekt response
• Prejšnji vhodni in izhodni elementi
• Definicije orodij in imenski prostori
• Vzorčni artefakti za večkratno uporabo, kot so predhodno upodobljeni žetoni

S ponovno uporabo stanja prejšnjega odgovora v pomnilniku nam je uspelo uvesti več pomembnih optimizacij:

• Nekateri naši varnostni klasifikatorji in validatorji zahtevkov obdelujejo samo nove vnose namesto celotne zgodovine pri vsakem iskanju
• Vzdrževanje predpomnilnika v pomnilniku za upodobljene žetone, ki ga sproti dopolnjujemo, da lahko preskočimo nepotrebno tokenizacijo
• Ponovna uporaba naše uspešne logike za razreševanje in usmerjanje modelov v različnih zahtevah 
• Prekrivanje neblokirajočega dela po sklepanju, kot je obračunavanje, z nadaljnjimi zahtevami

Cilj je bil čim bolj približati se prototipu z minimalnimi stroški, hkrati pa ohraniti zasnovo API-ja, ki so jo razvijalci že razumeli in uporabljali pri svojem delu.

Po dvomesečnem sprintu za izdelavo načina WebSocket smo lansirali različico alfa s ključnimi zagonskimi podjetji, ki razvijajo kodirne agente, da bi jo lahko integrirali v svojo infrastrukturo in varno postopno povečevali promet. Uporabniki alfa različice so bili navdušeni in so poročali o do 40 % izboljšavah⁠(odpre se v novem oknu) v svojih agentskih delovnih tokovih. Glede na pozitivne povratne informacije iz alfa faze smo bili pripravljeni na zagon.

Rezultati so bili vidni takoj zatem. Codex je hitro preusmeril večino prometa API Responses v način WebSocket in opazil znatne izboljšave zakasnitve. Za GPT‑5.3‑Codex‑Spark smo dosegli ciljno vrednost 1 000 TPS in zabeležili sunke do 4 000 TPS, kar kaže, da je API Responses lahko sledil precej hitrejšemu izvajanju inferenc v dejanskem produkcijskem prometu. Učinek se je hitro pokazal tudi v skupnosti razvijalcev:

• Codex je večino svojega prometa hitro preusmeril na povezave WebSocket. Uporabniki okolja Codex, ki uporabljajo najnovejše modele, kot je GPT‑5.3‑Codex⁠(odpre se v novem oknu), GPT‑5.4⁠(odpre se v novem oknu), in druge, lahko izkoristi pospešitev, ki jo prinaša način WebSocket.
• Vercel je integriral način WebSocket v AI SDK in dosegel zmanjšanje zakasnitve za do 40 %⁠(odpre se v novem oknu).
• Clineovi delovni tokovi z več datotekami so za 39 % hitrejši⁠(odpre se v novem oknu).
• Modeli OpenAI v Cursorju so postali do 30 % hitrejši⁠(odpre se v novem oknu).

Način WebSocket je ena najpomembnejših novih zmogljivosti v Responses API od njene uvedbe marca 2025. Od ideje do delovanja v produkciji smo prišli v le nekaj tednih s tesnim sodelovanjem med ekipama za OpenAI API in Codex. Ne le da dramatično izboljša zakasnitev pri uvajanju agentov, temveč podpira tudi vse večjo potrebo razvijalcev: ko inferenca modela postaja hitrejša, se morajo pospešiti tudi storitve in sistemi, ki inferenco obdajajo, da se te izboljšave prenesejo na uporabnike.