Urýchlenie agentických pracovných postupov pomocou WebSockets v rozhraní Responses API

Keď požiadaš Codex, aby opravil chybu, prehľadá tvoju kódovú základňu a nájde relevantné súbory, prečíta ich, aby si vytvoril kontext, vykoná úpravy a spustí testy, aby overil, že oprava funguje. V zákulisí to znamená desiatky požiadaviek na Responses API tam a späť: určiť ďalšiu akciu modelu, spustiť nástroj v tvojom počítači, odoslať výstup nástroja späť do API a opakovať.

Všetky tieto požiadavky môžu spolu trvať niekoľko minút, ktoré používatelia strávia čakaním, kým Codex dokončí zložité úlohy. Z hľadiska latencie trávi slučka agenta Codex väčšinu času v troch hlavných fázach: prácou v službách API (na overovanie a spracovanie požiadaviek), inferenciou modelu a časom na strane klienta (spúšťaním nástrojov a vytváraním kontextu modelu). Inferencia je fáza, v ktorej model beží na GPU a generuje nové tokeny. V minulosti bolo vykonávanie inferencie LLM na GPU najpomalšou časťou slučky agenta, takže réžia služby API sa dala ľahko skryť. Keď je inferencia rýchlejšia, kumulatívna režijná záťaž API pri agentickom nasadení je oveľa výraznejšia.

V tomto príspevku vysvetlíme, ako sme pomocou API zrýchlili slučky agenta od začiatku do konca o 40 %, čo používateľom umožňuje pocítiť nárast rýchlosti inferencie z 65 na takmer 1 000 tokenov za sekundu. Dosiahli sme to pomocou ukladania do vyrovnávacej pamäte, odstránenia zbytočných sieťových preskokov, zlepšenia našej bezpečnostnej vrstvy na rýchle označovanie problémov a – čo je najdôležitejšie – vytvorenia spôsobu, ako nadviazať trvalé pripojenie k rozhraniu Responses API, namiesto toho, aby bolo potrebné vykonať sériu synchrónnych volaní API.

V rozhraní Responses API bežal predchádzajúci vlajkový model, ako GPT‑5 a GPT‑5.2, rýchlosťou približne 65 tokenov za sekundu (TPS). Pri uvedení GPT‑5.3‑Codex‑Spark – rýchleho modelu na programovanie – bolo naším cieľom dosiahnuť podstatne vyššiu rýchlosť: viac ako 1 000 TPS, ktorú umožňuje špecializovaný hardvér Cerebras optimalizovaným na inferenciu LLM. Aby sme sa uistili, že používatelia môžu zažiť skutočnú rýchlosť tohto nového modelu, museli sme znížiť režijné náklady API. 

Približne v novembri 2025 sme spustili výkonnostný šprint pre rozhranie API (Application Programming Interface) Responses, v rámci ktorého sme nasadili viacero optimalizácií latencie kritickej cesty pri jednej požiadavke: 

• Ukladanie vykreslených tokenov a konfigurácie modelu do vyrovnávacej pamäte v pamäti s cieľom preskočiť nákladnú tokenizáciu a sieťové volania pri viackolových odpovediach
• Zníženie latencie sieťových preskokov elimináciou volaní na sprostredkovateľské služby (napríklad služby na zmenu rozlíšenia pri spracovaní obrázkov) a priamym volaním samotnej inferenčnej služby
• Zlepšenie nášho bezpečnostného balíka, aby sme mohli spúšťať určité klasifikátory na rýchlejšie označovanie konverzácií

Vďaka týmto vylepšeniam sme zaznamenali takmer 45 % zlepšenie času do prvého tokenu (TTFT), čo odráža, ako responzívne API pôsobí. Tieto zlepšenia však stále neboli pre GPT‑5.3‑Codex‑Spark dostatočne rýchle. Aj napriek týmto vylepšeniam bola réžia Responses API príliš veľká v porovnaní s rýchlosťou modelu. To znamená, že používatelia museli čakať na procesory, na ktorých beží naše API predtým, ako mohli využiť grafické procesory obsluhujúce model.

Hlbší problém bol štrukturálny: každú požiadavku na Codex sme považovali za nezávislú, pričom pri každej následnej požiadavke sme spracúvali stav konverzácie a ďalší opakovane použiteľný kontext. Aj keď sa väčšina konverzácie nezmenila, stále sme platili za prácu spojenú s celou históriou. Keď sa konverzácie predlžovali, opakované spracovanie bolo nákladnejšie.

Aby sme zjednodušili návrh, prehodnotili sme transportný protokol: mohli by sme udržiavať trvalé spojenie a ukladať stav do vyrovnávacej pamäte namiesto nadväzovania nového spojenia cez HTTP a odosielania celej histórie konverzácie pri každej následnej požiadavke? Zámerom bolo odosielať iba nové informácie vyžadujúce validáciu a spracovanie a ukladať opätovne použiteľný stav do pamäte počas trvania spojenia. To by znížilo režijné náklady spôsobené redundantnou prácou.

Zvažovali sme niekoľko rôznych prístupov vrátane WebSockets a obojsmerného streamovania gRPC. Rozhodli sme sa pre WebSockets, pretože pri jednoduchom protokole na prenos správ by používatelia nemuseli meniť štruktúru vstupov a výstupov rozhrania Responses API. Bolo to ústretové k vývojárom a zapadlo to do našej existujúcej architektúry s minimálnym narušením.

Prvý prototyp WebSocket zmenil naše predstavy o tom, čo je možné z hľadiska latencie rozhrania API pre odpovede. Inžinier z tímu Codex s hlbokými odbornými znalosťami v celom API stacku vytvoril prototyp spustením agenta Codex cez noc.

V tomto prototype boli agentické rollouty modelované ako jedna dlhodobo bežiaca odpoveď. Pri použití funkcií asyncio by sa Responses API po vybratí volania nástroja počas vzorkovania asynchrónne zablokovalo v slučke vzorkovania a Responses API by odoslalo klientovi udalosť response.done. Po vykonaní volania nástroja by klienti poslali späť udalosť response.append s výsledkom nástroja, čím by odblokovali slučku vzorkovania a umožnili modelu pokračovať.

Analógiou je tu zaobchádzať s lokálnym volaním nástroja ako s hostovaným volaním nástroja. Keď model zavolá vyhľadávanie na webe, inferenčná slučka sa zablokuje, zavolá službu vyhľadávania na webe a vloží odpoveď služby do kontextu modelu. V našom návrhu sme urobili to isté, no namiesto volania vzdialenej služby sme volanie nástroja modelu odoslali späť klientovi cez WebSocket. Keď klient odpovedal, vložili sme odpoveď klienta na volanie nástroja do kontextu a pokračovali sme vo vzorkovaní.

Tento návrh bol mimoriadne efektívny, pretože eliminoval opakovanú prácu s API pri zavádzaní agenta. Mohli by sme vykonať prácu pred inferenciou, pozastaviť sa na vykonanie nástroja a na konci vykonať prácu po inferencii.

Žiaľ, vyžiadalo si to menej známu a zložitejšiu podobou rozhrania API. Chceli sme, aby vývojári mohli jednoducho pridať podporu pre WebSocket bez toho, aby museli prepisovať svoju integráciu API kvôli novému spôsobu interakcie.

Vo verzii, ktorú sme spustili, sme sa vrátili k známej podobe: naďalej používaj response.create s rovnakým telom a na pokračovanie kontextu konverzácie z predchádzajúceho stavu odpovede použi previous_response_id.

Pri pripojení WebSocket server uchováva vyrovnávaciu pamäť v pamäti, viazanú na pripojenie, pre predchádzajúci stav odpovede. Keď následné response.create obsahuje previous_response_id, načítame tento stav z vyrovnávacej pamäte namiesto opätovného zostavovania celej konverzácie od začiatku.

Tento stav vo vyrovnávacej pamäti zahŕňa:

• Predchádzajúci objekt response
• Predchádzajúce vstupy a výstupy
• Definície nástrojov a menné priestory
• Opakovane použiteľné artefakty vzorkovania, ako napríklad predtým vykreslené tokeny

Opätovným použitím stavu predchádzajúcej odpovede v pamäti sa nám podarilo zaviesť niekoľko významných optimalizácií:

• Zabezpečenie, aby niektoré z našich klasifikátorov bezpečnosti a validátorov požiadaviek spracúvali iba nový vstup, nie zakaždým celú históriu
• Udržiavanie vyrovnávacej pamäte v pamäti pre vykreslené tokeny, do ktorej pridávame, aby sme mohli preskočiť zbytočnú tokenizáciu
• Opätovné používanie našej úspešnej logiky riešenia/smerovania modelu pri požiadavkách 
• Prekrývanie neblokujúcej práce po inferencii, ako je fakturácia, s následnými požiadavkami

Cieľom bolo čo najviac sa priblížiť k prototypu s minimálnou režijnou záťažou, ale s podobou API, ktorú vývojári už poznali a na ktorej stavali.

Po intenzívnom dvojmesačnom vývoji režimu WebSocketu sme spustili alfa verziu s kľúčovými startupmi vyvíjajúcimi programovacích agentov, aby ju mohli integrovať do svojej infraštruktúry a bezpečne postupne zvyšovať prevádzku. Používatelia alfa verzie si to obľúbili a hlásili zlepšenie svojich agentných pracovných postupov až o 40 %⁠(otvorí sa v novom okne) . Vzhľadom na pozitívnu spätnú väzbu z alfa verzie sme boli pripravení na spustenie.

Výsledky uvedenia na trh sa dostavili okamžite. Codex rýchlo presmeroval väčšinu prevádzky rozhrania Responses API do režimu WebSocket, čím dosiahol výrazné zlepšenie latencie. Pri modeli GPT‑5.3‑Codex‑Spark sme dosiahli náš cieľ 1 000 TPS a zaznamenali špičky až do 4 000 TPS, čo ukázalo, že rozhranie Responses API dokázalo držať krok s oveľa rýchlejšou inferenciou v reálnej produkčnej prevádzke. Dopad sa rýchlo prejavil aj v komunite vývojárov:

• Codex rýchlo presmeroval väčšinu svojej návštevnosti na WebSocket. Používatelia Codexu používajúci najnovšie modely, ako napríklad GPT‑5.3‑Codex⁠(otvorí sa v novom okne), GPT‑5.4⁠(otvorí sa v novom okne), a ďalší ťažia zo zrýchlenia režimu WebSocket.
• Spoločnosť Vercel integrovala režim WebSocket do AI SDK a zaznamenala zníženie latencie až o 40 %⁠(otvorí sa v novom okne).
• Pracovné postupy Cline s viacerými súbormi sú o 39 % rýchlejšie⁠(otvorí sa v novom okne).
• Modely OpenAI v Cursore sú až o 30 % rýchlejšie⁠(otvorí sa v novom okne).

Režim WebSocket je jednou z najvýznamnejších nových funkcií v Responses API od svojho spustenia v marci 2025. Od nápadu po nasadenie do produkcie sme sa dostali už za niekoľko týždňov vďaka úzkej spolupráci medzi tímami OpenAI API a Codex. Nielenže dramaticky zlepšuje latenciu nasadenia agenta, ale podporuje aj rastúcu potrebu vývojárov: keď sa inferencia modelu zrýchľuje, musia sa zrýchľovať aj služby a systémy, ktoré inferenciu obklopujú, aby sa tieto zlepšenia preniesli na používateľov.