Zrychlení agentních pracovních postupů pomocí WebSockets v Responses API

Když požádáš Codex, aby opravil chybu, prohledá tvou kódovou základnu, najde relevantní soubory, přečte je, aby získal kontext, provede úpravy a spustí testy, aby ověřil, že oprava funguje. V podstatě to znamená desítky požadavků rozhraní Responses API mezi sebou: určení další akce modelu, spuštění nástroje na tvém počítači, odeslání výstupu nástroje zpět do rozhraní API a opakování.

Všechny tyto požadavky mohou uživatelům prodlužovat dobu čekání na dokončení složitých úkolů až do minut, které Codex potřebuje ke splnění složitých úkolů. Z hlediska latence tráví smyčka agenta Codex většinu času ve třech hlavních fázích: práce v API službách (ověřování a zpracování požadavků), inference modelu a čas na straně klienta (spouštění nástrojů a vytváření kontextu modelu). Inference je fáze, ve které model běží na GPU a generuje nové tokeny. V minulosti byla inference LLM na GPU nejpomalejší částí smyčky agenta, takže režie služby API se dala snadno skrýt. S tím, jak se interference zrychluje, je kumulativní režie API při agentním běhu mnohem výraznější.

V tomto příspěvku si vysvětlíme, jak jsme pomocí API zrychlili smyčky agentů o 40 % od začátku do konce, což uživatelům umožnilo zažít skok v rychlosti inference z 65 na téměř 1 000 tokenů za sekundu. Přistoupili jsme k tomu pomocí ukládání do mezipaměti, odstranění zbytečných průchodů sítí, vylepšení naší bezpečnostní vrstvy pro rychlé označování problémů a, což je nejdůležitější, vytvoření způsobu, jak navázat trvalé připojení k Responses API, místo nutnosti provádět sérii synchronních volání API.

V rozhraní Responses API běžely předchozí vlajkové modely, jako GPT‑5 a GPT‑5.2, rychlostí přibližně 65 tokenů za sekundu (TPS). Při uvedení modelu GPT‑5.3‑Codex‑Spark, rychlého modelu pro programování, bylo naším cílem dosáhnout desetkrát vyšší rychlosti: více než 1 000 TPS, umožněné specializovaným hardwarem Cerebras optimalizovaným pro inferenci LLM. Abychom zajistili, že uživatelé budou moci využít skutečnou rychlost tohoto nového modelu, museli jsme snížit režii rozhraní API. 

Přibližně v listopadu 2025 jsme v rámci Responses API zahájili výkonnostní sprint, během kterého jsme zavedli řadu optimalizací latence kritické cesty pro jeden požadavek: 

• Ukládání vykreslených tokenů a konfigurace modelu do mezipaměti, aby se předešlo nákladné tokenizaci a síťovým voláním pro vícenásobné odpovědi
• Snížení latence síťových skoků eliminací volání zprostředkujících služeb (např. rozlišení zpracování obrazu) a přímým voláním samotné inferenční služby
• Vylepšili jsme naši bezpečnostní infrastrukturu, abychom mohli spouštět určité klasifikátory a rychleji označovat konverzace

Díky těmto vylepšením jsme zaznamenali téměř 45% zlepšení doby do prvního tokenu (TTFT), což odráží, jak rychle se API chová, ale tato vylepšení stále nebyla dostatečně rychlá pro GPT‑5.3‑Codex‑Spark. I přes tato vylepšení byla režie rozhraní Responses API vzhledem k rychlosti modelu příliš vysoká, uživatelé totiž museli čekat na procesory CPU, na kterých běželo naše API, než mohli využít grafické procesory GPU obsluhující model.

Hlubší problém byl strukturální: s každým požadavkem na Codex jsme zacházeli jako s nezávislým a v každém následném požadavku jsme zpracovávali stav konverzace a další opakovaně použitelný kontext. I když se většina konverzace nezměnila, stále jsme platili za práci spojenou s celou historií. Jak se konverzace prodlužovaly, toto opakované zpracování bylo nákladnější.

Abychom návrh zjednodušili, přehodnotili jsme transportní protokol: mohli bychom udržovat trvalé spojení a ukládat stav do mezipaměti, namísto navazování nového spojení přes HTTP a odesílání celé historie konverzace při každém následném požadavku? Cílem bylo odesílat pouze nové informace vyžadující ověření a zpracování a ukládat do mezipaměti opakovaně použitelný stav po celou dobu trvání připojení. To by snížilo režii způsobenou redundantní prací.

Zvažovali jsme několik různých přístupů, včetně WebSockets a obousměrného streamování pomocí gRPC. Rozhodli jsme se pro WebSockets, protože jako jednoduchý protokol pro přenos zpráv nevyžaduje, aby uživatelé měnili strukturu vstupů a výstupů rozhraní Responses API. Bylo to přátelské k vývojářům a bez větších problémů to zapadalo do naší stávající architektury.

První prototyp WebSocketu změnil to, co jsme považovali za možné v oblasti latence Responses API. Vývojář z týmu Codex s hlubokou odborností napříč API vytvořil prototyp tím, že přes noc spustil agenta Codex.

V tomto prototypu byly agentské implementace modelovány jako jedna dlouhodobá reakce. Při použití funkcí asyncio by se rozhraní Responses API po navzorkování volání nástroje asynchronně zablokovalo ve smyčce vzorkování a rozhraní Responses API by klientovi odeslalo událost response.done. Po provedení volání nástroje klienti poslali zpět událost response.append s výsledkem nástroje, která odblokovala smyčku vzorkování a umožnila modelu pokračovat.

Obdobou zde je přistupovat k lokálnímu volání nástroje jako k hostovanému volání nástroje. Když model zavolá webové vyhledávání, inferenční smyčka se zablokuje, zavolá službu webového vyhledávání a vloží odpověď služby do kontextu modelu. V našem návrhu jsme udělali totéž, ale místo volání vzdálené služby jsme poslali volání nástroje modelu zpět klientovi přes WebSocket. Když klient odpověděl, vložili jsme odpověď klienta na volání nástroje do kontextu a pokračovali ve vzorkování.

Tento návrh byl velmi efektivní, protože eliminoval opakovanou práci s API při běhu agenta. Práci před inferencí bychom mohli provést jednou, pozastavit se kvůli spuštění nástroje a práci po inferencí provést jednou na konci.

To však bohužel bylo vykoupeno méně známou a složitější podobou rozhraní API. Chtěli jsme, aby vývojáři mohli snadno přidat podporu WebSocketu, aniž by museli přepisovat integraci svého API kvůli novému způsobu interakce.

Pro verzi, kterou jsme spustili, jsme se vrátili ke známému formátu: pokračujte v používání response.create se stejným tělem a použijte previous_response_id k pokračování kontextu konverzace ze stavu předchozí odpovědi.

V rámci připojení WebSocket uchovává server mezipaměť předchozího stavu odpovědi v rozsahu připojení. Když následné response.create obsahuje previous_response_id, načteme tento stav z mezipaměti místo opětovného sestavování celé konverzace od nuly.

Tento stav uložený v mezipaměti zahrnuje:

• Předchozí objekt response
• Předchozí položky vstupu a výstupu
• Definice nástrojů a jmenné prostory
• Opakovaně použitelné vzorkovací artefakty, jako například dříve vykreslené tokeny

Díky opětovnému využití stavu předchozí odpovědi v paměti se nám podařilo dosáhnout několika významných optimalizací:

• Zajištění toho, aby některé z našich bezpečnostních klasifikátorů a validátorů požadavků zpracovávaly pouze nový vstup, a ne pokaždé celou historii
• Uchovávání mezipaměti vykreslených tokenů, ke které se připojujeme, abychom se vyhnuli zbytečné tokenizaci
• Opětovné využití naší úspěšné logiky pro řešení/směrování modelu napříč požadavky 
• Překrývající se neblokující postinferenční práce, jako je fakturace s následnými požadavky

Cílem bylo co nejvíce se přiblížit prototypu s minimální režijní zátěží, ale s podobou API, kterou vývojáři už znali a na níž stavěli.

Po dvouměsíčním sprintu budování WebSocket módu jsme spustili alfa verzi s klíčovými startupy agentů, které se zabývají kódováním, aby jej mohly integrovat do své infrastruktury a bezpečně navýšit provoz. Uživatelé alfa verze si ji oblíbili a hlásili zlepšení až o 40 %⁠(otevře se v novém okně) ve svých pracovních postupech agentů. Vzhledem k pozitivní zpětné vazbě z alfa verze jsme byli připraveni na spuštění.

Výsledky spuštění se dostavily okamžitě. Codex rychle převedl většinu provozu Responses API do režimu WebSocket a zaznamenal výrazné zlepšení latence. U GPT‑5.3‑Codex‑Spark jsme dosáhli cílové hodnoty 1 000 TPS a zaznamenali jsme špičky až 4 000 TPS, což ukázalo, že rozhraní Responses API dokázalo držet krok s výrazně rychlejší inferencí v reálném produkčním provozu. Dopad se rychle projevil i v komunitě vývojářů:

• Codex rychle převedl většinu svého provozu na WebSockety. Uživatelé Codex, kteří používají nejnovější modely, jako je GPT‑5.3‑Codex⁠(otevře se v novém okně), GPT‑5.4⁠(otevře se v novém okně), a všichni ostatní navíc těží ze zrychlení režimu WebSocketu.
• Společnost Vercel integrovala režim WebSocket do AI SDK a zaznamenala snížení latence až o 40 %⁠(otevře se v novém okně).
• Pracovní postupy Cline s více soubory jsou o 39 % rychlejší⁠(otevře se v novém okně).
• Modely OpenAI v Cursoru se staly až o 30 % rychlejšími⁠(otevře se v novém okně).

Režim WebSocket je jednou z nejvýznamnějších nových funkcí v rozhraní Responses API od jeho spuštění v březnu 2025. Od nápadu k nasazení do produkce jsme se dostali během několika týdnů díky úzké spolupráci týmů OpenAI API a Codex. Nejenže dramaticky zlepšuje latenci při běhu agentů, ale také podporuje rostoucí potřebu vývojářů: s tím, jak se zrychluje inference modelu, se musí zrychlovat i služby a systémy, které inference obklopují, aby bylo možné tyto přínosy přenést na uživatele.