Accelerarea fluxurilor de lucru agentice cu WebSockets în API-ul Responses

Când îi ceri Codex să remedieze o eroare, acesta scanează baza de cod pentru fișiere relevante, le citește pentru a construi context, face modificări și rulează teste pentru a verifica dacă remedierea a funcționat. În culise, acest lucru înseamnă zeci de cereri repetate către și de la API-ul Responses: să se determine următoarea acțiune a modelului, să ruleze un instrument pe calculatorul tău, să trimită rezultatul instrumentului înapoi la API și să repete acțiunile.

Toate aceste solicitări pot contribui la creșterea timpului pe care utilizatorii îl petrec așteptând ca Codex să finalizeze sarcini complexe. Din perspectiva latenței, ciclul agentului Codex își petrece cea mai mare parte a timpului în trei etape principale: lucrul în serviciile API (pentru a valida și procesa cererile), inferența modelului și timpul la nivel de client (rularea instrumentelor și construirea contextului modelului). Inferența este etapa în care modelul rulează pe unități de procesare grafică pentru a genera tokenuri noi. În trecut, rularea inferenței LLM pe unități de procesare grafică era cea mai lentă parte a ciclului agentic, astfel încât costul serviciului API era ușor de mascat. Pe măsură ce procesul de inferență devine mai rapid, costul cumulat al API-ului generat de o rulare agentică devine mult mai evidentă.

În acest articol, vom explica cum am reușit să accelerăm cu 40% ciclul de execuție al agenților de la un capăt la altul prin intermediul API-ului, permițând utilizatorilor să beneficieze de o creștere a vitezei de inferență de la 65 la aproape 1.000 de tokenuri pe secundă. Am abordat această problemă prin utilizarea memoriei cache, eliminarea traversărilor inutile în rețea, îmbunătățirea sistemului nostru de securitate pentru a semnaliza rapid problemele și, cel mai important, prin crearea unei modalități de a stabili o conexiune persistentă la API-ul Responses, în loc să fim nevoiți să efectuăm o serie de apeluri API sincrone.

În API-ul Responses, modelele de vârf anterioare, precum GPT‑5 și GPT‑5.2, rulau la aproximativ 65 de tokenuri pe secundă (TPS). Pentru lansarea GPT‑5.3‑Codex‑Spark, un model rapid pentru programare, obiectivul nostru era o viteză de zece ori mai mare: peste 1.000 TPS, posibil datorită echipamentului specializat Cerebras, optimizat pentru inferența LLM. Pentru a ne asigura că utilizatorii pot experimenta viteza reală a acestui nou model, a trebuit să reducem costul API-ului. 

În jurul lunii noiembrie 2025, am demarat un sprint de performanță pentru API-ul Responses, implementând numeroase optimizări ale latenței pe calea critică pentru o singură cerere: 

• Memorarea în cache a tokenurilor randate și a configurației modelului în memorie pentru a evita tokenizarea costisitoare și apelurile de rețea costisitoare pentru răspunsurile cu mai multe ture
• Reducerea latenței de traversare a rețelei prin eliminarea apelurilor către servicii intermediare (de exemplu, rezoluția procesării imaginilor) și apelarea directă a serviciului de inferență
• Îmbunătățirea sistemului nostru de siguranță pentru a putea rula anumiți clasificatori care să semnaleze mai rapid conversațiile

Cu aceste îmbunătățiri, am observat o îmbunătățire de aproape 45% a timpului până la primul token (TTFT), ceea ce reflectă cât de receptiv pare API-ul, însă aceste îmbunătățiri tot nu au fost suficient de rapide pentru GPT‑5.3‑Codex‑Spark. Chiar și cu aceste îmbunătățiri, costul API-ului Responses era prea mare în raport cu viteza modelului: adică utilizatorii trebuiau să aștepte ca procesoarele să execute API-ul nostru înainte de a putea folosi procesoarele grafice care rulau modelul.

Problema mai profundă era de natură structurală: am tratat fiecare cerere către Codex ca fiind independentă, procesând starea conversației și alt context reutilizabil în fiecare cerere ulterioară. Chiar și atunci când cea mai mare parte a conversației nu se schimbase, plăteam în continuare pentru munca asociată întregului istoric. Pe măsură ce conversațiile deveneau mai lungi, acea procesare repetată devenea mai costisitoare.

Pentru a optimiza arhitectura, am regândit protocolul de transport: am putea menține o conexiune persistentă și starea memoriei cache, în loc să stabilim o nouă conexiune prin HTTP și să trimitem istoricul complet al conversației pentru fiecare cerere ulterioară? Ideea era să se transmită doar informațiile noi care necesitau validare și procesare, iar starea reutilizabilă să fie stocată în memorie pe durata conexiunii. Acest lucru ar reduce costul cauzat de munca redundantă.

Am luat în considerare câteva abordări diferite, printre care WebSockets și transmisiunea în flux bidirecțională gRPC. Am ales WebSockets deoarece, fiind un protocol simplu de transport al mesajelor, utilizatorii nu ar fi trebuit să își schimbe structurile de intrare și de ieșire ale API-ului Responses. Era o soluție ușor de utilizat pentru dezvoltatori și s-a integrat în arhitectura noastră existentă fără a provoca perturbări majore.

Primul prototip WebSocket a schimbat ceea ce credeam că este posibil în privința latenței API-ului Responses. Un inginer din echipa Codex, cu o vastă experiență în domeniul API-urilor, a realizat un prototip rulând un agent Codex peste noapte.

În acel prototip, execuțiile agentice au fost modelate ca un singur răspuns de lungă durată. Folosind funcțiile asyncio, API-ul Responses se bloca asincron în bucla de eșantionare după ce a fost eșantionată o apelare a instrumentului, iar API-ul Responses trimitea un eveniment response.done înapoi către client. După executarea apelului instrumentului, clienții trimiteau înapoi un eveniment response.append cu rezultatul instrumentului, ceea ce a deblocat bucla de eșantionare și a permis modelului să continue.

O analogie aici ar fi să tratăm apelul local de instrument ca pe un apel de instrument găzduit. Când modelul apelează căutarea pe web, ciclul de inferență se blochează, apelează un serviciu de căutare pe web și introduce răspunsul serviciului în contextul modelului. În proiectul nostru, am procedat la fel; însă, în loc să apelăm un serviciu la distanță, am retransmis clientului apelul către instrumentul modelului prin WebSocket. Când clientul a răspuns, am introdus în context răspunsul clientului la apelul de instrument și am continuat să eșantionăm.

Acest concept s-a dovedit extrem de eficient, deoarece a eliminat repetarea operațiunilor legate de API pe parcursul implementării agenților. Am putea efectua o singură dată operațiunile de preinferență, aștepta execuția instrumentului, apoi efectua o singură dată operațiunile de postinferență la final.

Din păcate, acest lucru s-a realizat în detrimentul unei structuri API mai puțin familiare și mai complicate. Ne-am dorit ca dezvoltatorii să poată integra compatibilitatea pentru WebSocket fără a fi nevoiți să-și rescrie integrarea API-ului în funcție de un nou mod de interacțiune.

Pentru versiunea pe care am lansat-o, am revenit la o structură familiară: continuăm să folosim response.create cu același conținut și utilizăm previous_response_id pentru a prelua contextul conversației din starea răspunsului anterior.

Într-o conexiune WebSocket, serverul păstrează în memorie un cache, valabil pe durata conexiunii, care conține starea răspunsurilor anterioare. Când o solicitare ulterioară response.create include previous_response_id, preluăm acea stare din memoria cache în loc să reconstruim întreaga conversație de la zero.

Acea stare memorată în cache include:

• Obiectul anterior response
• Elemente de intrare și ieșire anterioare
• Definiții ale uneltelor și ale spațiilor de nume
• Artefacte reutilizabile de eșantionare, cum ar fi tokenurile randate anterior

Reutilizând starea anterioară a răspunsului din memorie, am reușit să obținem câteva optimizări majore:

• Unele dintre clasificatoarele noastre de siguranță și validatoarele de solicitări procesează doar datele de intrare noi, nu întregul istoric de fiecare dată
• Menținerea unui cache în memorie cu tokenuri redate, la care adăugăm elemente, astfel încât să putem evita tokenizarea inutilă
• Reutilizarea logicii noastre de rezolvare/direcționare, care s-a dovedit eficientă, pentru toate solicitările 
• Suprapunerea operațiunilor postinferență care nu blochează sistemul, cum ar fi facturarea, cu cererile ulterioare

Scopul era acela de a ne apropia cât mai mult de prototipul cu un nivel minim de costuri, dar cu o structură a API-ului pe care dezvoltatorii o înțelegeau deja și pe care se bazau deja.

După un sprint de două luni pentru dezvoltarea modului WebSocket, am lansat o versiune alfa împreună cu companii incipiente cheie specializate în agenți de programare, astfel încât să îl poată integra în infrastructura lor și să crească traficul în siguranță. Utilizatorii alfa au fost încântați, raportând îmbunătățiri de până la 40%⁠(se deschide într-o fereastră nouă) în fluxurile lor de lucru bazate pe agenți. Având în vedere opiniile pozitive din versiunea alfa, eram pregătiți pentru lansare.

Rezultatele lansării au fost imediate. Codex a migrat rapid majoritatea traficului său din API-ul Responses către modul WebSocket, observând îmbunătățiri semnificative ale latenței. Pentru GPT‑5.3‑Codex‑Spark, ne-am atins obiectivul de 1.000 TPS și am observat vârfuri de până la 4.000 TPS, ceea ce arată că API-ul Responses putea ține pasul cu o inferență mult mai rapidă în trafic de producție real. Efectul s-a observat rapid și în comunitatea dezvoltatorilor:

• Codex a direcționat rapid majoritatea traficului său către WebSocket-uri. Utilizatorii Codex care rulează cele mai recente modele, cum ar fi GPT‑5.3‑Codex⁠(se deschide într-o fereastră nouă), GPT‑5.4⁠(se deschide într-o fereastră nouă), și versiuni ulterioare beneficiază cu toții de viteza sporită oferită de modul WebSocket.
• Vercel a integrat modul WebSocket în SDK-ul AI și a observat o scădere a latenței cu până la 40%⁠(se deschide într-o fereastră nouă).
• Fluxurile de lucru cu mai multe fișiere ale Cline sunt cu 39% mai rapide⁠(se deschide într-o fereastră nouă).
• Modelele OpenAI din Cursor au devenit cu până la 30% mai rapide⁠(se deschide într-o fereastră nouă).

Modul WebSocket este una dintre cele mai importante capabilități noi din API-ul Responses de la lansarea sa în martie 2025. Am trecut de la idee la lansarea în producție în doar câteva săptămâni, prin colaborarea strânsă dintre echipele API și Codex de la OpenAI. Nu numai că îmbunătățește semnificativ latența de implementare a agenților, dar răspunde și unei nevoi tot mai mari a dezvoltatorilor: pe măsură ce inferența modelelor devine mai rapidă, serviciile și sistemele care o însoțesc trebuie, la rândul lor, să accelereze pentru a transfera aceste îmbunătățiri către utilizatori.