Accelerare i workflow agentici con WebSockets nell’API Responses

Quando chiedi a Codex di correggere un bug, esamina la codebase per individuare i file rilevanti, li analizza per costruire il contesto, apporta modifiche ed esegue test per verificare che la correzione funzioni Dietro le quinte, questo implica decine di richieste avanti e indietro all’API Responses: determinare l’azione successiva del modello, eseguire uno strumento sul tuo computer, inviarne l’output all’API e ripetere

Tutte queste richieste possono tradursi in minuti di attesa per gli utenti, mentre Codex completa attività complesse Dal punto di vista della latenza, il ciclo dell’agente Codex trascorre la maggior parte del tempo in tre fasi principali: elaborazione nei servizi API (per validare ed elaborare le richieste), inferenza del modello e attività lato client (esecuzione degli strumenti e costruzione del contesto) L’inferenza è la fase in cui il modello viene eseguito sulle GPU per generare nuovi token In passato, l’inferenza degli LLM sulle GPU era la parte più lenta del ciclo agentico, quindi l’overhead dei servizi API passava inosservato Con l’aumentare della velocità di inferenza, l’overhead cumulativo dell’API in un rollout agentico diventa molto più evidente

In questo articolo spieghiamo come abbiamo reso i cicli agentici basati su API più veloci del 40% end-to-end, permettendo agli utenti di sfruttare l’aumento della velocità di inferenza da 65 a quasi 1.000 token al secondo Abbiamo agito su più fronti: caching, eliminazione dei passaggi di rete non necessari, miglioramento dello stack di sicurezza per individuare rapidamente i problemi e, soprattutto, introduzione di una connessione persistente all’API Responses al posto di una sequenza di chiamate sincrone

Nella Responses API, i modelli di punta precedenti, come GPT‑5 e GPT‑5.2, operavano a circa 65 token al secondo (TPS) Per il lancio di GPT‑5.3‑Codex‑Spark, un modello di coding ad alte prestazioni, l’obiettivo era aumentare la velocità di un ordine di grandezza: oltre 1.000 TPS, grazie a hardware Cerebras specializzato e ottimizzato per l’inferenza degli LLM Per consentire agli utenti di sfruttare appieno la velocità reale di questo nuovo modello, è stato necessario ridurre l’overhead dell’API 

Intorno a novembre 2025 abbiamo avviato uno sprint sulle prestazioni della Responses API, introducendo numerose ottimizzazioni alla latenza nel percorso critico di una singola richiesta: 

• Caching in memoria dei token già renderizzati e della configurazione del modello per evitare costose operazioni di tokenizzazione e chiamate di rete nelle risposte multi-turno
• Riduzione della latenza dei passaggi di rete eliminando le chiamate ai servizi intermedi (ad esempio per la risoluzione dell’elaborazione immagini) e invocando direttamente il servizio di inferenza
• Ottimizzazione dello stack di sicurezza per eseguire alcuni classificatori e segnalare le conversazioni più rapidamente

Con questi miglioramenti abbiamo registrato una riduzione di quasi il 45% del tempo al primo token (TTFT), che riflette la reattività percepita dell’API, ma non era ancora sufficiente per GPT‑5.3‑Codex‑Spark Nonostante questi progressi, l’overhead della Responses API restava troppo elevato rispetto alla velocità del modello: in pratica, gli utenti dovevano attendere le CPU dell’API prima di poter sfruttare le GPU che eseguono il modello

Il problema più profondo era strutturale: trattavamo ogni richiesta a Codex come indipendente, rielaborando lo stato della conversazione e il contesto riutilizzabile a ogni richiesta successiva Anche quando la conversazione cambiava poco, continuavamo a sostenere il costo dell’elaborazione sull’intera cronologia Con l’allungarsi delle conversazioni, questo lavoro ripetuto diventava sempre più oneroso

Per ottimizzare l’architettura, abbiamo ripensato il protocollo di trasporto: mantenere una connessione persistente e memorizzare lo stato nella cache, invece di aprire ogni volta una nuova connessione HTTP e inviare l’intera cronologia della conversazione a ogni richiesta L’idea era inviare solo le nuove informazioni da validare ed elaborare, mantenendo in memoria lo stato riutilizzabile per tutta la durata della connessione In questo modo si riduceva l’overhead dovuto al lavoro ridondante

Abbiamo valutato diversi approcci, tra cui WebSockets e lo streaming bidirezionale gRPC Abbiamo scelto WebSockets perché, essendo un semplice protocollo di trasporto dei messaggi, non richiede agli utenti di modificare le strutture di input e output dell’API Responses È una soluzione intuitiva per gli sviluppatori e si integra con l’architettura esistente con modifiche minime

Il primo prototipo basato su WebSocket ha ridefinito ciò che ritenevamo possibile in termini di latenza per la Responses API Un ingegnere del team Codex, con esperienza approfondita su tutto lo stack API, ha realizzato un prototipo eseguendo un agente Codex durante la notte

In quel prototipo, i rollout agentici erano modellati come un’unica Response a esecuzione prolungata Utilizzando le funzionalità di asyncio, la Responses API si bloccherebbe in modo asincrono nel ciclo di campionamento dopo che era stata campionata una chiamata a uno strumento, e la Responses API invierebbe al client un evento response.done. Dopo aver eseguito la chiamata allo strumento, i client avrebbero rinviato un evento response.append con il risultato dello strumento, che sbloccava il ciclo di campionamento e consentiva al modello di continuare.

Un’analogia utile è trattare la chiamata a uno strumento locale come se fosse una chiamata a uno strumento ospitato Quando il modello esegue una ricerca web, il ciclo di inferenza si blocca, invoca un servizio di ricerca e inserisce la risposta nel contesto del modello Nel nostro design abbiamo adottato lo stesso approccio, ma invece di chiamare un servizio remoto abbiamo inoltrato la chiamata allo strumento del modello al client tramite WebSocket Quando il client rispondeva, inserivamo il risultato della chiamata allo strumento nel contesto e riprendevamo il campionamento

Questo approccio si è rivelato estremamente efficace perché ha eliminato il lavoro API ripetuto lungo l’intero rollout agentico È possibile eseguire il lavoro di pre-inferenza una sola volta, sospendere per l’esecuzione degli strumenti e completare il lavoro di post-inferenza una sola volta al termine

Questo vantaggio, tuttavia, comportava una struttura dell’API meno familiare e più complessa Volevamo permettere agli sviluppatori di integrare il supporto WebSocket senza dover riprogettare l’integrazione API attorno a un nuovo modello di interazione

Per la versione che abbiamo rilasciato, siamo tornati a una struttura familiare: continuate a usare response.create con lo stesso body e usate previous_response_id per continuare il contesto della conversazione a partire dallo stato della risposta precedente.

In una connessione WebSocket, il server mantiene una cache in memoria, associata alla connessione, dello stato delle risposte precedenti Quando una response.create successiva include previous_response_id, recuperiamo quello stato dalla cache invece di ricostruire l’intera conversazione da zero.

Questo stato memorizzato nella cache include:

• L'oggetto response precedente
• Elementi di input e output precedenti
• Definizioni degli strumenti e spazi dei nomi
• Artefatti di campionamento riutilizzabili, come i token già renderizzati

Riutilizzando lo stato della risposta precedente in memoria, siamo riusciti a ottenere diverse ottimizzazioni significative:

• Far sì che alcuni classificatori di sicurezza e validatori delle richieste elaborino solo i nuovi input, invece dell’intera cronologia a ogni richiesta
• Mantenere una cache in memoria dei token già renderizzati, a cui aggiungere nuovi elementi per evitare tokenizzazioni non necessarie
• Riutilizzare la logica consolidata di risoluzione e instradamento del modello tra le richieste 
• Sovrapporre attività di post-inferenza non bloccanti, come la fatturazione, alle richieste successive

L’obiettivo era avvicinarsi il più possibile al prototipo a overhead minimo, mantenendo però una struttura dell’API familiare per gli sviluppatori

Dopo uno sprint di due mesi dedicato allo sviluppo della modalità WebSocket, abbiamo lanciato una versione alpha con alcune startup chiave nel campo degli agenti di coding, così da permettere loro di integrarla nelle proprie infrastrutture e aumentare il traffico in modo sicuro Gli utenti alpha l’hanno apprezzato, riportando miglioramenti fino al 40%⁠(si apre in una nuova finestra) nei loro flussi di lavoro agentici. Alla luce del feedback positivo della fase alpha, eravamo pronti per il lancio

I risultati del lancio sono stati immediati Codex ha rapidamente spostato la maggior parte del traffico della Responses API sulla modalità WebSocket, ottenendo miglioramenti significativi nella latenza Per GPT‑5.3‑Codex‑Spark abbiamo raggiunto l’obiettivo di 1.000 TPS, con picchi fino a 4.000 TPS, dimostrando che la Responses API è in grado di sostenere velocità di inferenza molto più elevate in ambienti di produzione reali L’impatto si è manifestato rapidamente anche nella comunità degli sviluppatori:

• Codex ha trasferito rapidamente la maggior parte del proprio traffico su WebSockets. Gli utenti di Codex che eseguono i modelli più recenti come GPT‑5.3‑Codex⁠(si apre in una nuova finestra), GPT‑5.4⁠(si apre in una nuova finestra), e oltre a tutto ciò traggono vantaggio dall’accelerazione della modalità WebSocket.
• Vercel ha integrato la modalità WebSocket nell'AI SDK e ha registrato una riduzione della latenza fino al 40%⁠(si apre in una nuova finestra).
• I workflow multi-file di Cline sono più rapidi del 39%⁠(si apre in una nuova finestra).
• I modelli OpenAI in Cursor sono diventati fino al 30% più veloci⁠(si apre in una nuova finestra).

La modalità WebSocket è una delle novità più rilevanti introdotte nella Responses API dal lancio del marzo 2025 Siamo passati dall’idea alla produzione in poche settimane grazie alla stretta collaborazione tra i team API e Codex di OpenAI Non solo migliora drasticamente la latenza dei rollout agentici, ma risponde anche a un’esigenza crescente degli sviluppatori: con l’aumento della velocità di inferenza, anche i servizi e i sistemi circostanti devono evolvere per trasferire questi benefici agli utenti