Убрзавање агентских токова рада уз WebSockets у Responses API-ју

Kada zatražite od Codex-а da ispravi grešku, on pretražuje vaš kodni repozitorijum u potrazi za relevantnim datotekama, čita ih da bi izgradio kontekst, unosi izmene i pokreće testove da proveri da li je ispravka uspela. U pozadini, to znači na desetine naizmeničnih zahteva ka Responses API-ju: odrediti sledeću radnju modela, pokrenuti alat na vašem računaru, poslati izlaz alata nazad API-ju i ponoviti.

Svi ovi zahtevi mogu da se nagomilaju u minute koje korisnici provedu čekajući da Codex završi složene zadatke. Iz perspektive latencije, petlja Codex агента najveći deo vremena provodi u tri glavne faze: radu u API servisima (radi validacije i obrade zahteva), izvođenju modela i vremenu na strani klijenta (pokretanje alata i izgradnja konteksta modela). Izvođenje je faza u kojoj se model izvršava na GPU-ovima da bi generisao nove tokene. Ranije je pokretanje izvođenja velikih jezičkih modela (LLM) na GPU-ovima bilo najsporiji deo agentске petlje, pa je režiju API servisa bilo lako sakriti. Kako izvođenje postaje brže, kumulativna API režija u okviru agentског izvršavanja postaje mnogo uočljivija.

U ovom tekstu objasnićemo kako smo petlje agenata koje koriste API učinili 40% bržim od početka do kraja, omogućivši korisnicima da osete skok u brzini izvođenja sa 65 na skoro 1.000 tokena u sekundi. To smo postigli keširanjem, uklanjanjem nepotrebnih mrežnih skokova, unapređenjem našeg bezbednosnog sloja radi bržeg označavanja problema i — što je najvažnije — izgradnjom načina za uspostavljanje trajne veze sa Responses API-jem, umesto da moramo da pravimo niz sinhronih API poziva.

U Responses API-ju, prethodni најпознатији modeli kao što su GPT‑5 i GPT‑5.2 radili su približno 65 tokena u sekundi (TPS). Za lansiranje GPT‑5.3‑Codex‑Spark‑a, brzog modela za programiranje, naš cilj je bio za ceo red veličine brže: preko 1.000 TPS, zahvaljujući specijalizovanom Cerebras hardveru optimizovanom za izvođenje velikih jezičkih modela (LLM). Da bismo bili sigurni da korisnici mogu da iskuse stvarnu brzinu ovog novog modela, morali smo da smanjimo API režiju.

Oko novembra 2025. pokrenuli smo sprint za performanse na Responses API-ju, uvodeći mnoga optimizovanja latencije na kritičnoj putanji za jedan zahtev:

• Keširanje renderovanih tokena i konfiguracije modela u memoriji kako bismo preskočili skupu tokenizaciju i mrežne pozive za višekružne odgovore
• Smanjenje latencije mrežnih skokova uklanjanjem poziva ka posrednim servisima (na primer, za rezoluciju obrade slike) i direktnim pozivanjem samog servisa za izvođenje
• Unapređenje našeg bezbednosnog sloja kako bismo određene klasifikatore mogli da pokrećemo brže radi označavanja razgovora

Sa ovim poboljšanjima videli smo skoro 45% poboljšanja vremena do prvog tokena (TTFT) — što odražava koliko API deluje odzivno — ali ova poboljšanja i dalje nisu bila dovoljno brza za GPT‑5.3‑Codex‑Spark. Čak i uz ova poboljšanja, režija Responses API-ja bila je prevelika u odnosu na brzinu modela — to jest, korisnici su morali da čekaju CPU-ove koji pokreću naš API pre nego što mogu da koriste GPU-ove koji opslužuju model.

Dublji problem bio je strukturne prirode: svaki Codex zahtev tretirali smo kao nezavisan, obrađujući stanje razgovora i drugi ponovo upotrebljiv kontekst u svakom naknadnom zahtevu. Čak i kada se veći deo razgovora nije promenio, i dalje smo plaćali cenu rada vezanog za celu istoriju. Kako su razgovori postajali duži, ta ponovljena obrada postajala je skuplja.

Da bismo unapredili dizajn, preispitali smo transportni protokol: možemo li da zadržimo trajnu vezu i keširamo stanje, umesto da za svaki naknadni zahtev uspostavljamo novu vezu preko HTTP-a i šaljemo celu istoriju razgovora? Ideja je bila da šaljemo samo nove informacije koje zahtevaju validaciju i obradu, a da ponovo upotrebljivo stanje keširamo u memoriji tokom trajanja veze. Time bi se smanjila režija od redundantnog rada.

Razmotrili smo nekoliko različitih pristupa, uključujući WebSockets i gRPC dvosmerni streaming. Odlučili smo se za WebSockets jer, kao jednostavan protokol za prenos poruka, korisnici ne bi morali da menjaju oblike ulaza i izlaza svog Responses API-ja. Bio je prilagođen programerima i uklapao se u našu postojeću arhitekturu uz malo poremećaja.

Prvi WebSocket prototip promenio je ono što smo mislili da je moguće za latenciju Responses API-ja. Inženjer u Codex timu, sa dubokim stručnim znanjem kroz ceo API stek, sastavio je prototip tako što je preko noći pokretao Codex agentа.

U tom prototipu, agentска izvršavanja modelovana su kao jedan dugačko-pokrenuti Response. Koristeći mogućnosti asyncio, Responses API bi asinhrono blokirao u petlji uzorkovanja nakon što se uzorkuje poziv alata, a zatim bi Responses API poslao događaj response.done nazad klijentu. Nakon izvršavanja poziva alata, klijenti bi slali nazad događaj response.append sa rezultatom alata, što bi deblokiralo petlju uzorkovanja i omogućilo modelu da nastavi.

Analogija ovde je tretiranje lokalnog poziva alata kao hostovanog poziva alata. Kada model pozove veb pretragu, petlja izvođenja se blokira, poziva servis veb pretrage i stavlja odgovor servisa u kontekst modela. U našem dizajnu radili smo isto; ali umesto pozivanja udaljenog servisa, slali smo poziv alata modela nazad klijentu preko WebSocket veze. Kada bi klijent odgovorio, stavljali bismo odgovor klijenta na poziv alata u kontekst i nastavljali uzorkovanje.

Ovaj dizajn bio je izuzetno efikasan jer je eliminisao ponovljeni API rad kroz jedno agentско izvršavanje. Posao pre izvođenja mogli smo da obavimo jednom, pauziramo radi izvršavanja alata i posao posle izvođenja obavimo jednom na kraju.

Nažalost, to je dolazilo po cenu manje poznatog i složenijeg API oblika. Želeli smo da programeri mogu jednostavno da uvedu WebSocket podršku bez potrebe da prepisuju svoju API integraciju oko novog načina interakcije.

Za verziju koju smo lansirali vratili smo se poznatom obliku: nastavite da koristite response.create sa istim telom i koristite previous_response_id da biste nastavili kontekst razgovora iz stanja prethodnog odgovora.

Na WebSocket vezi server održava u memoriji keš prethodnog stanja odgovora vezan za tu vezu. Kada naknadni response.create uključuje previous_response_id, to stanje dohvatamo iz keša umesto da ponovo gradimo ceo razgovor od nule.

Taj keširani status uključuje:

• Prethodni objekat response
• Prethodne ulazne i izlazne stavke
• Definicije alata i imenske prostore
• Artefakte uzorkovanja za ponovnu upotrebu, kao što su prethodno renderovani tokeni

Ponovnom upotrebom prethodnog stanja odgovora u memoriji uspeli smo da uvedemo nekoliko velikih optimizacija:

• Omogućavanje da neki naši bezbednosni klasifikatori i validatori zahteva obrađuju samo novi ulaz, a ne celu istoriju svaki put
• Održavanje keša renderovanih tokena u memoriji kojem dodajemo nove, kako bismo preskočili nepotrebnu tokenizaciju
• Ponovnu upotrebu naše uspešne logike za rezoluciju/usmeravanje modela kroz zahteve
• Preklapanje neblokirajućeg posla posle izvođenja, kao što je naplata, sa narednim zahtevima

Cilj je bio da se što više približimo prototipu sa minimalnom režijom, ali uz API oblik koji su programeri već razumeli i oko kojeg su već gradili.

Posle dvomesečnog sprinta izgradnje WebSocket režima, lansirali smo alfa verziju sa ključnim startupima za agentsko programiranje kako bi je integrisali u svoju infrastrukturu i bezbedno postepeno povećavali saobraćaj. Alfa korisnici su je obožavali i prijavljivali su poboljšanja do 40%⁠(отвара се у новом прозору) u svojim agentским tokovima rada. S obzirom na pozitivne povratne informacije iz alfe, bili smo spremni za lansiranje.

Rezultati lansiranja bili su trenutni. Codex je brzo prebacio većinu svog saobraćaja Responses API-ja na WebSocket režim i video značajna poboljšanja latencije. Za GPT‑5.3‑Codex‑Spark dostigli smo cilj od 1.000 TPS i videli skokove do 4.000 TPS, što je pokazalo da Responses API može da isprati mnogo brže izvođenje u stvarnom produkcionom saobraćaju. Uticaj se brzo pokazao i u zajednici programera:

• Codex je brzo prebacio većinu svog saobraćaja na WebSockets. Codex korisnici koji pokreću najnovije modele kao što su GPT‑5.3‑Codex⁠(отвара се у новом прозору), GPT‑5.4⁠(отвара се у новом прозору) i novije, svi imaju koristi od ubrzanja koje donosi WebSocket režim.
• Vercel je integrisao WebSocket režim u AI SDK i video smanjenje latencije za do 40%⁠(отвара се у новом прозору).
• Cline-ovi tokovi rada sa više datoteka su 39% brži⁠(отвара се у новом прозору).
• OpenAI modeli u Cursor-u postali su do 30% brži⁠(отвара се у новом прозору).

WebSocket režim je jedna od najznačajnijih novih mogućnosti u Responses API-ju od njegovog lansiranja u martu 2025. Od ideje do rada u produkciji stigli smo za samo nekoliko nedelja zahvaljujući tesnoj saradnji između OpenAI API i Codex timova. On ne samo da dramatično poboljšava latenciju agentског izvršavanja, već podržava i rastuću potrebu graditelja: kako izvođenje modela postaje brže, servisi i sistemi koji ga okružuju takođe moraju da se ubrzaju kako bi se ti dobici preneli korisnicima.