Ubrzavanje agentskih radnih tokova pomoću WebSocket-a u Responses API-ju

Kada zatražite od Codexa da ispravi grešku, on skenira vašu kodnu bazu u potrazi za relevantnim datotekama, čita ih kako bi izgradio kontekst, vrši izmjene i pokreće testove kako bi provjerio da li je ispravka uspjela. Iza kulisa, to znači desetine tamo-amo zahtjeva prema Responses API-ju: odrediti sljedeću radnju modela, pokrenuti alat na svom računaru, poslati izlaz alata nazad API-ju i ponoviti.

Svi ovi zahtjevi mogu se nakupiti do nekoliko minuta koje korisnici provedu čekajući da Codex završi složene zadatke. Iz perspektive latencije, petlja agenta Codex provodi većinu svog vremena u tri glavne faze: radu u API servisima (za validaciju i obradu zahtjeva), inferenciji modela i vremenu na strani klijenta (pokretanje alata i izgradnju konteksta modela). Inferencija je faza u kojoj se model izvršava na GPU-ovima kako bi generirao nove tokene. U prošlosti je pokretanje LLM inferencije na GPU-ovima bilo najsporiji dio petlje agenta, pa je bilo lako prikriti API opterećenje. Kako inferencija postaje brža, kumulativno API opterećenje tokom agentnog procesa postaje mnogo primjetnije.

U ovom postu objasnit ćemo kako smo petlje agenta, koristeći API, učinili 40% bržim od početka do kraja, omogućavajući korisnicima da iskuse skok u brzini inferencije sa 65 na gotovo 1.000 tokena u sekundi. Ovome smo pristupili putem keširanja, eliminacijom nepotrebnih mrežnih skokova, unaprjeđenjem našeg sigurnosnog steka kako bismo brzo označili probleme i — što je najvažnije — izgradnjom načina za uspostavljanje trajne veze s Responses API-jem, umjesto potrebe za nizom sinhronih API poziva.

U Responses API-ju, prethodni glavni modeli poput GPT‑5 i GPT‑5.2 radili su brzinom od približno 65 tokena u sekundi (TPS). Za lansiranje GPT‑5.3‑Codex‑Spark, brzog modela za kodiranje, naš cilj je bio postići deset puta veću brzinu: preko 1.000 TPS, omogućeno specijaliziranim Cerebras hardverom optimiziranim za LLM inferenciju. Da bismo osigurali da korisnici mogu iskusiti stvarnu brzinu ovog novog modela, morali smo smanjiti opterećenje API-ja. 

Oko novembra 2025. godine pokrenuli smo sprint za poboljšanje performansi na Responses API-ju, uvodeći niz optimizacija latencije kritičnog puta za jedan zahtjev: 

• Keširanje renderiranih tokena i konfiguracije modela u memoriji kako bi se izbjegla skupa tokenizacija i mrežni pozivi za višestruke odgovore
• Smanjenje latencije mrežnih skokova uklanjanjem poziva prema posredničkim uslugama (na primjer, rezolucija obrade slike) i direktnim pozivanjem same usluge zaključivanja
• Unapređivanje našeg sigurnosnog sistema kako bismo mogli pokretati određene klasifikatore za brže označavanje razgovora

Uz ova poboljšanja, zabilježili smo poboljšanje od gotovo 45% u vremenu do prvog tokena (TTFT)—što odražava koliko API djeluje responzivno—ali ta poboljšanja i dalje nisu bila dovoljno brza za GPT‑5.3‑Codex‑Spark. Čak i uz ova poboljšanja, režijski trošak Responses API-ja bio je prevelik u odnosu na brzinu modela—to jest, korisnici su morali čekati da CPU-i na kojima se izvršava naš API završe obradu prije nego što bi mogli koristiti GPU-ove koji opslužuju model.

Dublji problem bio je strukturalne prirode: svaki zahtjev za Codex tretirali smo kao nezavisan, obrađujući stanje razgovora i ostali kontekst koji se može ponovo koristiti u svakom narednom zahtjevu. Čak i kada veći dio razgovora nije bio promijenjen, i dalje smo plaćali za rad vezan uz cijelu historiju. Kako su razgovori postajali duži, ta ponovljena obrada postajala je sve skuplja.

Kako bismo unaprijedili dizajn, ponovo smo razmotrili transportni protokol: možemo li zadržati trajnu vezu i keširati stanje, umjesto da za svaki naredni zahtjev uspostavljamo novu vezu preko HTTP-a i šaljemo cijelu historiju razgovora? Ideja je bila da se šalju samo nove informacije koje zahtijevaju provjeru i obradu te da se višekratno upotrebljivo stanje kešira u memoriji tokom trajanja veze. To bi smanjilo režijski trošak uzrokovan suvišnim radom.

Razmotrili smo nekoliko različitih pristupa, uključujući WebSockets i dvosmjerni streaming putem gRPC-a. Odlučili smo se za WebSockets jer, kao jednostavan protokol za prijenos poruka, korisnici ne bi morali mijenjati oblike ulaza i izlaza u Responses API-ju. Bio je prilagođen programerima i uklopio se u našu postojeću arhitekturu uz minimalne poremećaje.

Prvi WebSocket prototip promijenio je ono što smo mislili da je moguće za latenciju API-ja za odgovore. Inženjer iz Codex tima s dubokim stručnim znanjem kroz cijeli API stack napravio je prototip pokretanjem Codex agenta preko noći.

U tom prototipu, agentička izvršavanja su modelirana kao jedan dugotrajan Response. Koristeći mogućnosti asyncio, Responses API bi se asinhrono blokirao u petlji uzorkovanja nakon što bi bio uzorkovan poziv alata, a Responses API bi klijentu poslao nazad događaj response.done. Nakon izvršavanja poziva alata, klijenti bi poslali nazad događaj response.append s rezultatom alata, što je deblokiralo petlju uzorkovanja i omogućilo modelu da nastavi.

Analogija ovdje je tretirati lokalni poziv alata kao hostovani poziv alata. Kada model pozove web pretragu, petlja zaključivanja se blokira, poziva servis za web pretragu i smješta odgovor servisa u kontekst modela. U našem dizajnu učinili smo isto; ali umjesto pozivanja udaljene usluge, vratili smo poziv alata modela klijentu putem WebSocketa. Kada je klijent odgovorio, stavili smo odgovor klijenta na poziv alata u kontekst i nastavili generisanje.

Ovaj dizajn bio je izuzetno efikasan jer je eliminisao ponovljeni rad na API-ju tokom uvođenja agenta. Mogli bismo jednom obaviti rad prije zaključivanja, pauzirati radi izvršavanja alata i jednom obaviti rad nakon zaključivanja na kraju.

Nažalost, došlo je po cijenu manje poznate i složenije strukture API-ja. Željeli smo omogućiti programerima da jednostavno dodaju WebSocket podršku bez potrebe da prepisuju svoju API integraciju oko novog načina interakcije.

Za verziju koju smo pokrenuli, vratili smo se na poznati obrazac: nastavite koristiti response.create s istim tijelom zahtjeva i koristite previous_response_id za nastavak konteksta razgovora iz stanja prethodnog odgovora.

Na WebSocket vezi server održava keš u memoriji vezan za vezu, koji sadrži prethodno stanje odgovora. Kada naknadni response.create uključuje previous_response_id, dohvatamo stanje iz keša umjesto da ponovo gradimo cijeli razgovor od početka.

To keširano stanje uključuje:

• Prethodni objekat response
• Prethodne stavke unosa i izlaza
• Definicije alata i prostori imena
• Artefakti uzorkovanja za višekratnu upotrebu, poput prethodno generisanih tokena

Ponovnim korištenjem stanja prethodnog odgovora u memoriji, uspjeli smo ostvariti nekoliko značajnih optimizacija:

• Omogućavanje da neki od naših sigurnosnih klasifikatora i validatora zahtjeva obrađuju samo novi unos, a ne cijelu povijest svaki put
• Čuvanje keša u memoriji za renderovane tokene kojem dodajemo kako bismo izbjegli nepotrebnu tokenizaciju
• Ponovno korištenje naše uspješne logike za rješavanje i usmjeravanje modela kroz zahtjeve 
• Preklapanje neblokirajućih radnji nakon inferencije, poput naplate, sa narednim zahtjevima

Cilj je bio približiti se prototipu s minimalnim režijskim opterećenjem što je više moguće, ali sa strukturom API-ja koju su programeri već razumjeli i koristili.

Nakon dvomjesečnog sprinta na izgradnji WebSocket moda, pokrenuli smo alfa verziju s ključnim startupima koji razvijaju agente za kodiranje kako bi je mogli integrisati u svoju infrastrukturu i sigurno postepeno povećavati promet. Alpha korisnici su bili oduševljeni, prijavili su poboljšanja do 40%⁠(otvara se u novom prozoru) u svojim agentičkim tokovima rada. S obzirom na pozitivne povratne informacije o alfa verziji, bili smo spremni za pokretanje.

Rezultati lansiranja bili su trenutni. Codex je brzo preusmjerio većinu saobraćaja svog Responses API-ja na WebSocket način rada, uz značajna poboljšanja latencije. Za GPT‑5.3‑Codex‑Spark dostigli smo naš cilj od 1.000 TPS i zabilježili skokove do 4.000 TPS, što pokazuje da Responses API može pratiti znatno brže izvođenje zaključivanja u stvarnom produkcijskom saobraćaju. Uticaj se brzo pokazao i u zajednici programera:

• Codex je brzo prebacio većinu svog prometa na WebSockets. Korisnici Codexa koji koriste najnovije modele kao što je GPT‑5.3‑Codex⁠(otvara se u novom prozoru), GPT‑5.4⁠(otvara se u novom prozoru), i svi imaju koristi od ubrzanja WebSocket režima.
• Vercel je integrirao WebSocket način rada u AI SDK i zabilježio smanjenje latencije do 40%⁠(otvara se u novom prozoru).
• Clineovi radni procesi s više datoteka su 39% brži⁠(otvara se u novom prozoru).
• OpenAI modeli u Cursoru postali su do 30% brži⁠(otvara se u novom prozoru).

WebSocket način rada jedna je od najznačajnijih novih mogućnosti u Responses API-ju od njegovog pokretanja u martu 2025. Od ideje do rada u produkciji stigli smo za samo nekoliko sedmica, kroz blisku saradnju između timova OpenAI API-ja i Codex. Ne samo da dramatično poboljšava latenciju uvođenja agenta, već i podržava rastuću potrebu onih koji grade: kako izvođenje zaključaka modela postaje brže, usluge i sistemi koji okružuju zaključivanje također moraju ubrzati kako bi prenijeli ove dobitke na korisnike.