Accelerant els fluxos de treball amb agents amb WebSockets a l’API de Responses

Quan demanes a Codex que corregeixi un error, escaneja el teu codi font per trobar fitxers rellevants, els llegeix per construir context, fa edicions i executa proves per verificar que la correcció ha funcionat. En segon pla, això vol dir desenes de sol·licituds d’anada i tornada a l’API de Responses: determinar la següent acció del model, executar una eina al teu ordinador, tornar a enviar la sortida de l’eina a l’API i repetir.

Totes aquestes sol·licituds poden sumar minuts d’espera perquè els usuaris vegin Codex completar tasques complexes. Des del punt de vista de la latència, el bucle de l’agent de Codex passa la major part del temps en tres etapes principals: treball als serveis de l’API (per validar i processar sol·licituds), inferència del model i temps al costat del client (executant eines i construint el context del model). La inferència és l’etapa en què el model s’executa sobre GPU per generar nous segments. En el passat, executar la inferència de LLM sobre GPU era la part més lenta del bucle amb agents, així que el cost afegit dels serveis de l’API era fàcil d’amagar. A mesura que la inferència s’accelera, el cost acumulat de l’API en un desplegament amb agents es fa molt més notable.

En aquesta entrada, explicarem com vam aconseguir que els bucles d’agent que utilitzen l’API fossin un 40% més ràpids d’extrem a extrem, permetent als usuaris notar el salt de velocitat d’inferència de 65 a gairebé 1.000 segments per segon. Ho vam abordar amb memòria cau, eliminant salts de xarxa innecessaris, millorant la nostra pila de seguretat per marcar problemes ràpidament i —el més important— construint una manera de crear una connexió persistent amb l’API de Responses, en lloc d’haver de fer una sèrie de crides síncrones a l’API.

A l’API de Responses, models insígnia anteriors com GPT‑5 i GPT‑5.2 funcionaven a aproximadament 65 segments per segon (TPS). Per al llançament de GPT‑5.3‑Codex‑Spark, un model ràpid per a programació, el nostre objectiu era un ordre de magnitud més ràpid: més de 1.000 TPS, gràcies a maquinari especialitzat de Cerebras optimitzat per a la inferència de LLM. Per assegurar-nos que els usuaris poguessin experimentar la velocitat real d’aquest nou model, havíem de reduir el cost afegit de l’API. 

Cap al novembre de 2025, vam iniciar un esprint de rendiment a l’API de Responses i vam aplicar moltes optimitzacions a la latència del camí crític d’una única sol·licitud: 

• Emmagatzemar en memòria cau els segments renderitzats i la configuració del model per ometre la segmentació costosa i les crides de xarxa en respostes de diversos torns
• Reduir la latència dels salts de xarxa eliminant crides a serveis intermedis (per exemple, resolució de processament d’imatges) i cridant directament el mateix servei d’inferència
• Millorar la nostra pila de seguretat perquè poguéssim executar determinats classificadors per marcar converses més ràpidament

Amb aquestes millores, vam veure gairebé un 45% de millora en el temps fins al primer segment (TTFT), que reflecteix com de sensible sembla l’API, però aquestes millores encara no eren prou ràpides per a GPT‑5.3‑Codex‑Spark. Fins i tot amb aquestes millores, el cost afegit de l’API de Responses era massa gran en relació amb la velocitat del model; és a dir, els usuaris havien d’esperar els CPU que executen la nostra API abans de poder fer servir les GPU que serveixen el model.

El problema més profund era estructural: tractàvem cada sol·licitud de Codex com a independent, processant l’estat de la conversa i altre context reutilitzable en cada sol·licitud de seguiment. Fins i tot quan la major part de la conversa no havia canviat, continuàvem assumint el cost d’un treball lligat a tot l’historial. A mesura que les converses s’allargaven, aquest processament repetit es feia més car.

Per ajustar el disseny, vam replantejar el protocol de transport: podíem mantenir una connexió persistent i emmagatzemar l’estat en memòria cau, en lloc d’establir una connexió nova sobre HTTP i enviar tot l’historial de la conversa a cada sol·licitud de seguiment? La idea era enviar només qualsevol informació nova que requerís validació i processament i emmagatzemar en memòria cau l’estat reutilitzable a la memòria durant tota la vida de la connexió. Això reduiria el cost del treball redundant.

Vam considerar diversos enfocaments, com WebSockets i l’streaming bidireccional de gRPC. Ens vam decidir per WebSockets perquè, com a protocol senzill de transport de missatges, els usuaris no haurien de canviar les formes d’entrada i sortida de la seva API de Responses. Era còmode per a desenvolupadors i encaixava amb la nostra arquitectura existent amb poca disrupció.

El primer prototip de WebSocket va canviar el que pensàvem que era possible per a la latència de l’API de Responses. Un enginyer de l’equip de Codex amb una gran experiència a tota la pila de l’API va reunir un prototip fent córrer un agent de Codex durant la nit.

En aquest prototip, els desplegaments amb agents es modelaven com una sola Response de llarga durada. Utilitzant funcionalitats d’asyncio, l’API de Responses es bloquejava de manera asíncrona al bucle de mostreig després de mostrejar una crida d’eina, i l’API de Responses enviava un esdeveniment response.done de tornada al client. Després d’executar la crida d’eina, els clients tornaven a enviar un esdeveniment response.append amb el resultat de l’eina, que desbloquejava el bucle de mostreig i permetia al model continuar.

Una analogia aquí és tractar la crida d’eina local com una crida d’eina allotjada. Quan el model crida la cerca web, el bucle d’inferència es bloqueja, crida un servei de cerca web i posa la resposta del servei en el context del model. En el nostre disseny, fèiem el mateix; però en lloc de cridar un servei remot, enviàvem la crida d’eina del model al client de tornada a través del WebSocket. Quan el client responia, posàvem la resposta de la crida d’eina del client en el context i continuàvem mostrejant.

Aquest disseny va ser extremadament eficaç perquè eliminava el treball repetit de l’API al llarg d’un desplegament amb agents. Podíem fer el treball previ a la inferència una vegada, pausar per a l’execució de l’eina i fer el treball posterior a la inferència una sola vegada al final.

Malauradament, això tenia el cost d’una forma d’API menys familiar i més complicada. Volíem que els desenvolupadors poguessin afegir suport de WebSocket sense haver de reescriure la seva integració de l’API al voltant d’un mode d’interacció nou.

Per a la versió que vam llançar, vam tornar a una forma familiar: continuar fent servir response.create amb el mateix cos i utilitzar previous_response_id per continuar el context de la conversa a partir de l’estat de la resposta anterior.

En una connexió WebSocket, el servidor manté una memòria cau en memòria de l’estat de respostes anteriors, acotada a la connexió. Quan una response.create de seguiment inclou previous_response_id, recuperem aquest estat de la memòria cau en lloc de reconstruir tota la conversa des de zero.

Aquest estat emmagatzemat a la memòria cau inclou:

• L’objecte response anterior
• Elements d’entrada i sortida previs
• Definicions d’eines i espais de noms
• Artefactes de mostreig reutilitzables, com ara segments renderitzats prèviament

Reutilitzant l’estat en memòria de la resposta anterior, vam poder aplicar diverses optimitzacions importants:

• Fer que alguns dels nostres classificadors de seguretat i validadors de sol·licituds processessin només l’entrada nova, i no tot l’historial cada vegada
• Mantenir una memòria cau en memòria de segments renderitzats a la qual anem afegint contingut per poder ometre segmentació innecessària
• Reutilitzar la nostra lògica satisfactòria de resolució/encaminament del model entre sol·licituds 
• Solapar treball posterior a la inferència que no bloqueja, com la facturació, amb sol·licituds posteriors

L’objectiu era apropar-nos tant com fos possible al prototip de cost mínim, però amb una forma d’API que els desenvolupadors ja entenien i al voltant de la qual ja havien construït.

Després d’un esprint de dos mesos construint el mode WebSocket, vam llançar una alfa amb startups clau d’agents de programació perquè el poguessin integrar a la seva infraestructura i augmentar el trànsit amb seguretat. Als usuaris alfa els va encantar i van informar de millores de fins al 40%⁠(s'obre en una finestra nova) en els seus fluxos de treball amb agents. Tenint en compte els comentaris positius de l’alfa, estàvem a punt per al llançament.

Els resultats del llançament van ser immediats. Codex va traslladar ràpidament la major part del seu trànsit de l’API de Responses al mode WebSocket, amb millores significatives de latència. Per a GPT‑5.3‑Codex‑Spark, vam assolir el nostre objectiu de 1.000 TPS i vam veure pics de fins a 4.000 TPS, demostrant que l’API de Responses podia seguir el ritme d’una inferència molt més ràpida en trànsit real de producció. L’impacte també es va veure ràpidament a la comunitat de desenvolupadors:

• Codex va traslladar ràpidament la major part del seu trànsit a WebSockets. Els usuaris de Codex que executen els models més recents com GPT‑5.3‑Codex⁠(s'obre en una finestra nova), GPT‑5.4⁠(s'obre en una finestra nova) i posteriors es beneficien de l’acceleració del mode WebSocket.
• Vercel va integrar el mode WebSocket a l’AI SDK i va veure com la latència disminuïa fins a un 40%⁠(s'obre en una finestra nova).
• Els fluxos de treball multifitxer de Cline són un 39% més ràpids⁠(s'obre en una finestra nova).
• Els models d’OpenAI a Cursor van arribar a ser fins a un 30% més ràpids⁠(s'obre en una finestra nova).

El mode WebSocket és una de les capacitats noves més significatives de l’API de Responses des del seu llançament el març de 2025. Vam passar de la idea a executar-ho en producció en només unes setmanes gràcies a una col·laboració estreta entre els equips d’API i de Codex d’OpenAI. No només millora dràsticament la latència dels desplegaments d’agents, sinó que també dona suport a una necessitat creixent per als creadors: a mesura que la inferència del model s’accelera, els serveis i sistemes que envolten la inferència també s’han d’accelerar per traslladar aquests guanys als usuaris.