Acelerar los flujos de trabajo de agentes con WebSockets en la API de respuestas

Cuando le pides a Codex que corrija un error, busca en tu base de código los archivos relevantes, los lee para obtener contexto, realiza cambios y ejecuta pruebas para verificar que la corrección ha funcionado. En la práctica, eso implica decenas de solicitudes de ida y vuelta a la API de respuestas: determinar la siguiente acción del modelo, ejecutar una herramienta en tu ordenador, enviar el resultado de la herramienta a la API y repetir el proceso.

Todas estas solicitudes pueden traducirse en minutos que los usuarios pasan esperando a que Codex complete tareas complejas. Desde el punto de vista de la latencia, el ciclo del agente de Codex dedica la mayor parte del tiempo a tres etapas principales: el trabajo en los servicios de API (para validar y procesar las solicitudes), la inferencia del modelo y el tiempo del lado del cliente (ejecutar herramientas y crear el contexto del modelo). La inferencia es la etapa en la que el modelo se ejecuta en las GPU para generar nuevos tokens. Antes, ejecutar la inferencia de LLM en las GPU era la parte más lenta del ciclo del agente, por lo que era fácil ocultar la sobrecarga del servicio de API. A medida que la inferencia se vuelve más rápida, la sobrecarga acumulada de la API por el despliegue de agente se nota mucho más.

En esta publicación, te explicaremos cómo conseguimos que los ciclos de los agentes que usan la API fueran un 40 % más rápidos de principio a fin, lo que permite a los usuarios experimentar un salto en la velocidad de inferencia de 65 a casi 1000 tokens por segundo. Para ello, optamos por el almacenamiento en caché, eliminamos saltos de red innecesarios, mejoramos nuestra pila de seguridad para detectar rápidamente los problemas y, lo más importante, creamos una forma de establecer una conexión persistente con la API de respuestas, en lugar de tener que realizar una serie de llamadas síncronas a la API.

En la API de respuestas, los modelos insignia anteriores, como GPT‑5 y GPT‑5.2, funcionaban a aproximadamente 65 tokens por segundo (TPS). Para el lanzamiento de GPT‑5.3‑Codex‑Spark, un modelo rápido para programación, nuestro objetivo era multiplicar por diez la velocidad: más de 1000 TPS, gracias a hardware especializado de Cerebras optimizado para la inferencia del LLM. Para asegurarnos de que los usuarios pudieran experimentar la verdadera velocidad de este nuevo modelo, tuvimos que reducir la sobrecarga de la API. 

Hacia noviembre de 2025, lanzamos un sprint de rendimiento en la API de respuestas, en el que implementamos numerosas optimizaciones en la latencia de la ruta crítica para una sola solicitud: 

• Almacenamiento en la memoria caché de los tokens renderizados y de la configuración del modelo para evitar la costosa tokenización y las llamadas de red en respuestas de varios turnos
• Reducción de la latencia del salto de red al eliminar las llamadas a servicios intermedios (por ejemplo, la resolución del procesamiento de imágenes) y llamar directamente al propio servicio de inferencia
• Mejora de nuestra pila de seguridad para poder ejecutar ciertos clasificadores y marcar conversaciones más rápido

Con estas mejoras, observamos una reducción de casi el 45 % en el tiempo hasta el primer token (TTFT), lo que refleja la sensación de rapidez de la API, pero estas mejoras seguían sin ser lo bastante rápidas para GPT‑5.3‑Codex‑Spark. Incluso con estas mejoras, la sobrecarga de la API de respuestas seguía siendo demasiado grande en relación con la velocidad del modelo; es decir, los usuarios tenían que esperar a que las CPU que ejecutaban nuestra API terminaran antes de poder usar las GPU que ejecutaban el modelo.

El problema más profundo era de carácter estructural: tratábamos cada solicitud a Codex como independiente, procesando el estado de la conversación y otro contexto reutilizable en cada solicitud de seguimiento. Incluso cuando la mayor parte de la conversación no había cambiado, seguíamos pagando por el trabajo asociado al historial completo. A medida que las conversaciones se hacían más largas, ese procesamiento repetido se volvió más costoso.

Para optimizar el diseño, replanteamos el protocolo de transporte: ¿podíamos mantener una conexión persistente y almacenar en caché el estado, en lugar de establecer una nueva conexión a través de HTTP y enviar todo el historial de la conversación en cada solicitud posterior? La idea era enviar únicamente cualquier información nueva que requiriera validación y procesamiento, y almacenar en la memoria caché el estado reutilizable durante toda la vida útil de la conexión. Esto reduciría la sobrecarga operativa del trabajo redundante.

Consideramos varios enfoques diferentes, incluidos WebSockets y gRPC de streaming bidireccional. Nos decidimos por WebSockets porque, como protocolo sencillo de transporte de mensajes, los usuarios no tendrían que cambiar los formatos de entrada y salida de su API de respuestas. Era fácil de usar para los desarrolladores y se adaptaba bien a nuestra arquitectura existente, con pocas interrupciones.

El primer prototipo de WebSocket cambió lo que creíamos posible en cuanto a la latencia de la API de respuestas. Un ingeniero del equipo de Codex, con amplia experiencia en toda la pila de la API, creó un prototipo tras ejecutar un agente de Codex durante toda la noche.

En ese prototipo, los despliegues de agentes se modelaron como una única respuesta de larga duración. Al usar las funciones de asyncio, la API de respuestas se bloquearía de forma asíncrona en el ciclo de muestreo después de que se muestreara una llamada a la herramienta, y la API de respuestas enviaría un evento response.done de vuelta al cliente. Después de ejecutar la llamada a la herramienta, los clientes devolverían un evento response.append con el resultado de la herramienta, lo que desbloquearía el ciclo de muestreo y permitiría que el modelo continuara.

Una analogía aquí es tratar la llamada a la herramienta local como una llamada a la herramienta alojada. Cuando el modelo llama a la búsqueda en la web, el ciclo de inferencia se bloquea, llama a un servicio de búsqueda en la web e incorpora la respuesta del servicio al contexto del modelo. En nuestro diseño, hicimos lo mismo; sin embargo, en lugar de llamar a un servicio remoto, enviamos la llamada a la herramienta del modelo de vuelta al cliente a través del WebSocket. Cuando el cliente respondió, incorporamos al contexto la respuesta del cliente a la llamada a la herramienta y seguimos realizando el muestreo.

Este diseño fue extremadamente eficaz porque eliminó el trabajo repetido de la API durante el despliegue de un agente. Podríamos hacer el trabajo previo a la inferencia una vez, pausar para ejecutar la herramienta y hacer el trabajo posterior a la inferencia una vez al final.

Por desgracia, esto supuso tener que lidiar con una estructura de API menos familiar y más complicada. Queríamos que los desarrolladores pudieran incorporar la compatibilidad con WebSocket sin tener que reescribir la integración de su API para adaptarla a un nuevo modo de interacción.

En la versión que lanzamos, volvimos a una estructura que ya nos era familiar: seguimos usando response.create con el mismo cuerpo y utilizamos previous_response_id para retomar el contexto de la conversación desde el estado de la respuesta anterior.

En una conexión WebSocket, el servidor mantiene una caché en la memoria, válida para toda la conexión, del estado de las respuestas anteriores. Cuando una respuesta response.create de seguimiento incluye previous_response_id, recuperamos ese estado de la caché en lugar de reconstruir toda la conversación desde cero.

Ese estado en caché incluye lo siguiente:

• El objeto response anterior
• Elementos previos de entrada y salida
• Definiciones de herramientas y espacios de nombres
• Artefactos de muestreo reutilizables, como los tokens renderizados previamente

Al reutilizar el estado de la respuesta anterior en la memoria, pudimos implementar varias optimizaciones importantes:

• Hacer que algunos de nuestros clasificadores de seguridad y validadores de solicitudes procesen solo las entradas nuevas, y no todo el historial cada vez
• Mantener una caché en la memoria de tokens renderizados a la que vamos añadiendo para evitar la tokenización innecesaria
• Reutilizar nuestra exitosa lógica de resolución/derivación del modelo en todas las solicitudes 
• Superponer tareas posteriores a la inferencia que no bloquean el sistema, como la facturación, con las solicitudes posteriores

El objetivo era acercarse lo máximo posible al prototipo con una sobrecarga mínima, pero con una estructura de API que los desarrolladores ya conocieran y con la que ya hubieran trabajado.

Tras de dos meses de trabajo intensivo desarrollando el modo WebSocket, lanzamos una versión alfa con las principales startups de agentes de programación para que pudieran integrarlo en su infraestructura y redirigir el tráfico de forma segura. Los usuarios alfa quedaron encantados e informaron mejoras de hasta un 40 %⁠(se abre en una nueva ventana) en sus flujos de trabajo de agentes. Dada la buena retroalimentación de la fase alfa, ya estaba todo listo para el lanzamiento.

Los resultados del lanzamiento fueron inmediatos. Codex redirigió rápidamente la mayor parte de su tráfico de la API de respuestas al modo WebSocket, observando mejoras significativas en la latencia. Para GPT‑5.3‑Codex‑Spark, alcanzamos nuestro objetivo de 1000 TPS y vimos picos de hasta 4000 TPS, lo que demuestra que la API de respuestas podía seguir el ritmo de una inferencia mucho más rápida en condiciones reales del tráfico de producción. El impacto también se hizo patente muy pronto en la comunidad de desarrolladores:

• Codex redirigió rápidamente la mayor parte de su tráfico a WebSockets. Todos los usuarios de Codex que ejecutan los modelos más recientes (como GPT‑5.3‑Codex⁠(se abre en una nueva ventana), GPT‑5.4⁠(se abre en una nueva ventana), y posteriores), se benefician del aumento de velocidad del modo WebSocket.
• Vercel integró el modo WebSocket en el AI SDK y vio cómo la latencia se reducía hasta un 40 %⁠(se abre en una nueva ventana).
• Los flujos de trabajo con varios archivos de Cline son un 39 % más rápidos⁠(se abre en una nueva ventana).
• Los modelos de OpenAI en Cursor pasaron a ser hasta un 30 % más rápidos⁠(se abre en una nueva ventana).

El modo WebSocket es una de las capacidades más significativas de la API de respuestas desde su lanzamiento en marzo de 2025. Pasamos de la idea a la producción en solo unas semanas gracias a la estrecha colaboración entre los equipos de la API de OpenAI y Codex. No solo mejora drásticamente la latencia de despliegue del agente, sino que también responde a una necesidad creciente de los desarrolladores: a medida que la inferencia del modelo se acelera, los servicios y sistemas que rodean la inferencia también deben acelerarse para trasladar estas mejoras a los usuarios.