Ubrzavanje agentskih radnih tijekova uz WebSockets u Responses API-ju

Kada od Codexa zatražiš da ispravi pogrešku, on pretražuje tvoju bazu koda kako bi pronašao relevantne datoteke, čita ih kako bi stekao kontekst, unosi izmjene i pokreće testove kako bi provjerio je li ispravak uspio. Iza kulisa, to znači desetke uzastopnih zahtjeva prema Responses API-ju: odrediti sljedeću radnju modela, pokrenuti alat na vašem računalu, poslati izlaz alata natrag API-ju te ponavljanje.

Svi ti zahtjevi mogu se zbrojiti u minute koje korisnici provedu čekajući da Codex dovrši složene zadatke. Iz perspektive latencije, petlja agenta Codex većinu vremena provodi u trima glavnim fazama: radu u API servisima (za provjeru i obradu zahtjeva), inferenciji modela i vremenu na strani klijenta (pokretanje alata i izgradnja konteksta modela). Inferencija je faza u kojoj se model izvršava na GPU-ovima kako bi generirao nove tokene. U prošlosti je izvođenje LLM inferencije na GPU-ovima bilo najsporiji dio petlje agenta, pa je bilo lako prikriti režijski trošak API usluge. Kako izvođenje zaključivanja postaje brže, kumulativno API opterećenje pri agentskom izvođenju postaje mnogo primjetnije.

U ovoj ćemo objavi objasniti kako smo petlje agenta učinili 40 % bržima tako što smo od početka do kraja upotrebljavali API, čime smo korisnicima omogućili da iskuse povećanje brzine izvođenja zaključivanja sa 65 na gotovo 1 000 tokena u sekundi. Tome smo pristupili predmemoriranjem, uklanjanjem nepotrebnih mrežnih skokova, poboljšanjem našeg sigurnosnog skupa alata za brzo označavanje problema i – što je najvažnije – izgradnjom načina za uspostavu trajne veze s Responses API-jem, umjesto izvođenja niza sinkronih API poziva.

U Responses API-ju, prethodni vodeći modeli poput GPT‑5 i GPT‑5.2 radili su brzinom od otprilike 65 tokena u sekundi (TPS). Za lansiranje GPT‑5.3‑Codex‑Sparka, brzog modela za programiranje, naš je cilj bio postići deseterostruko veću brzinu: više od 1 000 TPS, zahvaljujući specijaliziranom hardveru Cerebras optimiziranom za LLM zaključivanje. Kako bismo bili sigurni da korisnici mogu iskusiti stvarnu brzinu tog novog modela, morali smo smanjiti režijske troškove API-ja. 

U studenom 2025. pokrenuli smo sprint za poboljšanje performansi za Responses API, tako što smo uveli brojne optimizacije latencije kritičnog puta za jedan zahtjev: 

• predmemoriranje renderiranih tokena i konfiguracije modela u memoriji radi preskakanja skupe tokenizacije i mrežnih poziva za višekružne odgovore
• smanjenje latencije mrežnih skokova uklanjanjem poziva posredničkim servisima (primjerice, za obradu razlučivosti slika) i izravnim pozivanjem usluge zaključivanja.
• Poboljšavamo naš sigurnosni sustav kako bismo mogli pokretati određene klasifikatore i brže označavati razgovore.

Uz ta poboljšanja zabilježili smo gotovo 45 % poboljšanja vremena do prvog tokena (TTFT) — što odražava koliko API djeluje responzivno – no ta poboljšanja još uvijek nisu bila dovoljno brza za GPT‑5.3‑Codex‑Spark. Čak i uz ta poboljšanja, režijski trošak Responses API-ja bio je prevelik u odnosu na brzinu modela – odnosno, korisnici su morali čekati CPU-ove na kojima se izvršavao naš API prije nego što su mogli koristiti GPU-ove koji su posluživali model.

Dublji problem bio je strukturne prirode: svaki zahtjev za Codex tretirali smo kao neovisan, tako što smo obrađivali stanje razgovora i drugi ponovno upotrebljiv kontekst u svakom naknadnom zahtjevu. Čak i kada je većina razgovora ostala ista, i dalje smo plaćali rad povezan s cijelom poviješću. Kako su razgovori postajali dulji, ta je ponovljena obrada postajala sve skuplja.

Kako bismo dodatno unaprijedili dizajn, preispitali smo transportni protokol: možemo li zadržati trajnu vezu i pohraniti stanje u predmemoriju, umjesto da za svaki sljedeći zahtjev uspostavljamo novu vezu putem HTTP-a i šaljemo cijelu povijest razgovora? Ideja je bila slati samo nove informacije koje zahtijevaju provjeru i obradu te stanje koje se može ponovno upotrijebiti pohraniti u predmemoriju u memoriji tijekom trajanja veze. To bi smanjilo režijske troškove uzrokovane 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 korisnici, kao kod jednostavnog protokola za prijenos poruka, ne bi morali mijenjati strukturu ulaznih i izlaznih podataka u API-ju za odgovore. Bio je prilagođen razvojnim inženjerima i uklopio se u našu postojeću arhitekturu uz minimalne poremećaje.

Prvi prototip WebSocketa promijenio je naše shvaćanje mogućeg u vezi s latencijom Responses API-ja. Inženjer iz Codex tima, s dubokim stručnim znanjem o cijelom API skupu, izradio je prototip pokretanjem Codex agenta tijekom noći.

U tom prototipu agentički rolloutovi bili su modelirani kao jedan dugotrajni odgovor. Upotrebom značajke asyncio, API za odgovore asinkrono bi blokirao u petlji uzorkovanja nakon što je uzorkovan poziv alata, a API za odgovore poslao bi događaj response.done natrag klijentu. Nakon izvršavanja poziva alata, klijenti bi poslali natrag događaj response.append s rezultatom alata, čime bi se deblokirala petlja uzorkovanja i omogućio nastavak modelu.

Tu se može povući analogija da se lokalni poziv alata tretira kao hostirani poziv alata. Kada model pozove pretraživanje weba, petlja zaključivanja blokira se, poziva uslugu pretraživanja weba i stavlja odgovor usluge u kontekst modela. U našem dizajnu učinili smo isto, no umjesto pozivanja udaljene usluge, poslali smo poziv alata modela natrag klijentu putem WebSocketa. Kada je klijent odgovorio, stavili smo odgovor klijenta na poziv alata u kontekst i nastavili s uzorkovanjem.

Taj je dizajn bio iznimno učinkovit jer je uklonio ponovljeni rad na API-ju tijekom uvođenja agenta. Mogli bismo jednom obaviti rad prije izvođenja zaključivanja, pauzirati radi izvršavanja alata i jednom na kraju obaviti rad nakon izvođenja zaključivanja.

Nažalost, to je došlo nauštrb manje poznate i složenije strukture API-ja. Željeli smo razvojnim inženjerima omogućiti da jednostavno dodaju podršku za WebSocket bez da iznova moraju pisati svoju API integraciju zbog novog načina interakcije.

U verziji koju smo objavili vratili smo se poznatom obliku: ponovno koristimo response.create s istim tijelom i upotrebljavamo previous_response_id za nastavak konteksta razgovora iz stanja prethodnog odgovora.

Na WebSocket vezi, poslužitelj održava predmemoriju u memoriji s ograničenjem veze za prethodno stanje odgovora. Kada naknadni response.create uključuje previous_response_id, to stanje dohvaćamo iz predmemorije umjesto da cijeli razgovor ponovno gradimo od nule.

To predmemorirano stanje uključuje:

• prethodni odgovor objekt
• prethodne stavke ulaza i izlaza
• definicije alata i prostori imena.
• Artefakti uzorkovanja za višekratnu uporabu, kao što su prethodno generirani tokeni

Ponovnom upotrebom stanja prethodnog odgovora u memoriji, uspjeli smo uvesti nekoliko velikih optimizacija:

• mogućnost da neki naši sigurnosni klasifikatori i validatori zahtjeva obrađuju samo novi unos, a ne svaki put cijelu povijest
• održavanje predmemorije u memoriji renderiranih tokena u koju dodajemo kako bismo mogli preskočiti nepotrebnu tokenizaciju
• ponovnu upotrebu naše uspješne logike rješavanja/usmjeravanja modela u svim zahtjevima 
• preklapanje neblokirajućeg rada nakon izvođenja zaključivanja, kao što je naplata, sa sljedećim zahtjevima.

Cilj je bio približiti se prototipu s minimalnim režijskim opterećenjem, ali s oblikom API-ja koji su razvojni inženjeri već razumjeli i na kojem su već radili.

Nakon dvomjesečnog sprinta na izgradnji WebSocket moda, lansirali smo alfa verziju s ključnim startupovima koji razvijaju agente za programiranje kako bi je mogli integrirati u svoju infrastrukturu i sigurno postupno povećavati promet. Alfa korisnici bili su oduševljeni te su prijavili poboljšanja do 40 %⁠(otvara se u novom prozoru) u svojim agentskim tijekovima rada. S obzirom na pozitivne alfa povratne informacije, bili smo spremni za lansiranje.

Rezultati lansiranja bili su trenutačni. Codex je brzo prebacio većinu svojeg prometa Responses API-ja na način WebSocket, pritom ostvarivši znatna poboljšanja latencije. Za GPT‑5.3‑Codex‑Spark dosegnuli smo 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 prometu. Učinak se brzo pokazao i u zajednici razvojnih programera:

• Codex je brzo prebacio većinu svojeg prometa na WebSocketove. Korisnici Codexa koji upotrebljavaju 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 koje donosi način rada WebSocket.
• Vercel je integrirao način rada WebSocket u AI SDK i zabilježio smanjenje latencije za do 40 %⁠(otvara se u novom prozoru).
• Clineovi tijekovi rada s više datoteka 39 % su brži⁠(otvara se u novom prozoru).
• OpenAI modeli u Cursoru postali su do 30 % brži⁠(otvara se u novom prozoru).

Način rada WebSocket jedna je od najznačajnijih novih mogućnosti u sučelju Responses API od njegova lansiranja u ožujku 2025. godine. Od ideje do rada u produkciji stigli smo u samo nekoliko tjedana, zahvaljujući bliskoj suradnji timova za OpenAI API i Codex. Ne samo da dramatično poboljšava latenciju implementacije agenta, nego i podržava rastuću potrebu razvojnih inženjera: kako zaključivanje modela postaje brže, usluge i sustavi koji okružuju zaključivanje također se moraju ubrzati kako bi te dobitke prenijeli korisnicima.