Agenti AI più veloci: cosa insegna il caso OpenAI su WebSocket e latenza

OpenAI mostra come l’uso di connessioni persistenti e cache per sessione abbia ridotto l’overhead nei workflow agentici di Codex. Una lettura operativa per progettare agenti AI più reattivi.

La velocità del modello non basta più

OpenAI ha pubblicato un approfondimento tecnico su come ha accelerato i workflow agentici di Codex usando WebSocket e caching legato alla connessione nella Responses API. Il punto interessante, per chi progetta soluzioni AI in azienda, non è solo il dato prestazionale: è il cambio di prospettiva architetturale.

Nel ciclo descritto da OpenAI, quando Codex deve correggere un bug, l’agente analizza il codice, individua file rilevanti, legge contesto, propone modifiche e lancia test. Ogni passaggio può richiedere interazioni ripetute tra client, servizi applicativi, strumenti locali e modello. Secondo OpenAI, in questi flussi il tempo non dipende soltanto dall’inferenza, ma anche dalla validazione delle richieste, dalla gestione dello stato, dai passaggi di rete e dal tempo lato client.

Storicamente l’inferenza sugli LLM era la parte più lenta. Con modelli più rapidi, però, il collo di bottiglia può spostarsi: se il modello genera token più velocemente, l’overhead dei servizi circostanti diventa più visibile. È un tema che riguarda direttamente chi porta agenti AI in produzione: l’esperienza utente dipende dall’intera catena, non dal solo motore generativo.

Cosa ha cambiato OpenAI nel loop di Codex

Nel post, OpenAI spiega che i precedenti modelli flagship citati, come GPT-5 e GPT-5.2, giravano intorno a 65 token al secondo nella Responses API. Per GPT-5.3-Codex-Spark l’obiettivo era superare i 1.000 token al secondo, anche grazie a hardware Cerebras specializzato per inferenza LLM. A quel punto, ridurre il lavoro applicativo ripetuto è diventato necessario per rendere percepibile il salto di velocità.

Prima dell’introduzione del nuovo schema, OpenAI aveva già lavorato su ottimizzazioni del percorso critico: cache in memoria di token renderizzati e configurazione del modello, riduzione di hop di rete verso servizi intermedi, miglioramenti nello stack di sicurezza per segnalare più rapidamente alcuni problemi. Questi interventi hanno portato, secondo la fonte, a un miglioramento vicino al 45% nel time to first token, la metrica che indica quanto rapidamente arriva il primo output.

Il nodo strutturale restava però la gestione di ogni richiesta come se fosse indipendente. Nelle conversazioni lunghe e nei rollout agentici, molto contesto non cambia, ma veniva comunque rielaborato nei passaggi successivi. OpenAI ha quindi introdotto una connessione persistente via WebSocket, mantenendo una cache in memoria valida per la durata della connessione.

Perché WebSocket è rilevante per gli agenti AI

OpenAI dichiara di aver valutato diverse opzioni, tra cui WebSocket e gRPC bidirectional streaming. La scelta è caduta sui WebSocket perché permettevano un trasporto semplice dei messaggi senza imporre agli sviluppatori di cambiare in modo sostanziale formato di input e output.

Il prototipo iniziale modellava un rollout agentico come una singola response di lunga durata: il sistema poteva sospendere il loop quando veniva richiesta una tool call, inviare un evento al client, attendere il risultato dello strumento e poi continuare. La versione lanciata ha però mantenuto una forma più familiare: gli sviluppatori continuano a usare response.create e previous_response_id per proseguire dal contesto precedente.

Sul piano tecnico, la connessione mantiene in memoria elementi come response precedente, input e output già usati, definizioni degli strumenti, namespace e artefatti riutilizzabili di sampling, inclusi token già renderizzati. In questo modo alcune validazioni e classificazioni possono lavorare solo sul nuovo input, la tokenizzazione non deve ripartire sempre da zero e parte della logica di routing del modello può essere riutilizzata.

Risultati dichiarati e lettura per le aziende

OpenAI riporta che, dopo uno sprint di circa due mesi, la modalità WebSocket è stata provata in alpha con startup che costruiscono agenti di coding. La fonte cita miglioramenti fino al 40% nei workflow agentici. In produzione, Codex avrebbe poi spostato la maggioranza del traffico Responses API su questa modalità, con benefici di latenza significativi.

L’articolo cita anche integrazioni esterne: Vercel avrebbe visto una riduzione della latenza fino al 40% nell’AI SDK, Cline workflow multi-file più rapidi del 39% e Cursor miglioramenti fino al 30% con modelli OpenAI. Sono dati attribuiti alla fonte e vanno letti nel contesto specifico di quegli strumenti, non come garanzia automatica per ogni architettura.

Per un’organizzazione che sta introducendo agenti AI, la lezione è concreta: prima di cercare solo un modello più veloce, conviene misurare dove si accumula attesa. Nei progetti di AI benefit e automazione etica, questo significa progettare fin dall’inizio policy, monitoraggio e controllo dello stato, non aggiungerli a valle.

Metriche e rischi da valutare prima di adottare lo stesso approccio

Una connessione persistente può ridurre lavoro ripetuto, ma introduce anche nuove responsabilità operative. Prima di replicare un modello simile, un team dovrebbe osservare almeno alcune metriche chiave:

Ci sono poi rischi architetturali da non sottovalutare. La cache legata alla connessione deve essere coerente con lo stato reale della conversazione. Le riconnessioni vanno gestite senza perdere contesto o ripetere azioni già eseguite. Inoltre, mantenere stato in memoria può complicare bilanciamento del carico, autoscaling e failover.

Qui entra in gioco il lavoro DevOps: osservabilità, tracciamento distribuito e gestione affidabile delle infrastrutture diventano parte del progetto AI. Per questo il tema si collega naturalmente a pratiche di cloud managed services e DevOps, soprattutto quando gli agenti passano da prototipo a produzione.

Un criterio pratico: ottimizzare il ciclo, non il singolo componente

Il caso OpenAI conferma una direzione già visibile nei workflow basati su Codex: gli agenti non sono semplici chiamate isolate a un modello, ma processi iterativi che usano strumenti, memoria temporanea, validazioni e decisioni progressive. Lo stesso principio vale per scenari aziendali con task ricorrenti, come quelli descritti nell’approfondimento Dedaloop su Codex Automations.

La domanda utile non è “quanto è veloce il modello?”, ma “quanto è efficiente l’intero ciclo dell’agente?”. Se ogni passaggio ricostruisce contesto, ripete controlli già completati o moltiplica gli hop di rete, anche un modello molto rapido può produrre un’esperienza lenta.

L’approccio descritto da OpenAI non è una ricetta universale, ma indica una priorità chiara: per rendere gli agenti AI affidabili e reattivi servono architetture incrementali, capaci di riusare stato e calcoli già validati, mantenendo al tempo stesso controllo, sicurezza e osservabilità.

Approfondimenti Dedaloop

Fonti