Por qué importan los bucles de agentes más rápidos
OpenAI dice que ha rehecho la infraestructura detrás de su Responses API para acelerar de forma notable los flujos de trabajo tipo agente, un cambio orientado a reducir el tiempo que los usuarios pasan esperando mientras herramientas, modelos y llamadas a la API van y vienen durante tareas complejas.
En una publicación técnica del 22 de abril, la empresa describió cómo sistemas como Codex pueden requerir decenas de solicitudes secuenciales para completar una sola tarea: el modelo decide qué hacer a continuación, una herramienta se ejecuta en el lado del cliente, el resultado se envía de vuelta a la API y el ciclo se repite. Ese patrón hace que incluso pequeñas cantidades de sobrecarga se acumulen con rapidez.
Según OpenAI, el problema de rendimiento se volvió más visible a medida que la inferencia en sí se aceleró. La empresa dijo que los modelos insignia anteriores en la Responses API funcionaban a unas 65 tokens por segundo. Para GPT-5.3-Codex-Spark, OpenAI apuntó a más de 1.000 tokens por segundo usando hardware de Cerebras. Una vez que la generación del modelo se volvió tan rápida, las partes más lentas del bucle dejaron de ser fáciles de ocultar.
Del cuello de botella de inferencia al cuello de botella de la API
OpenAI divide la latencia de los agentes en tres etapas amplias: trabajo del servicio de API, inferencia del modelo y tiempo del lado del cliente. El lado del cliente sigue importando porque las herramientas necesitan ejecutarse y el contexto debe ensamblarse, pero la empresa dijo que la capa de API se había convertido en un cuello de botella importante.
Ese cambio obligó a una estrategia de optimización diferente. En lugar de centrarse solo en el rendimiento de las GPU, OpenAI dice que empezó a eliminar fricciones a lo largo de la ruta de la solicitud. Hacia noviembre de 2025, la empresa lanzó lo que llamó un sprint de rendimiento en la Responses API. El trabajo incluyó cachear en memoria los tokens renderizados y la configuración del modelo, reducir saltos de red innecesarios llamando a los servicios de inferencia de forma más directa y acelerar partes de la pila de seguridad para que algunas conversaciones pudieran clasificarse más rápido.
Esos cambios mejoraron el tiempo hasta el primer token en casi un 45%, según la empresa. Pero OpenAI dice que eso todavía no era suficiente para exponer por completo las ganancias de velocidad de su pila de inferencia más reciente.
El cambio a WebSocket
El cambio mayor fue arquitectónico: sustituir una serie de llamadas API síncronas separadas por una conexión persistente a la Responses API mediante WebSockets. En términos prácticos, eso significa que el cliente y la API pueden mantenerse conectados durante todo el bucle del agente en lugar de desmontar y reconstruir constantemente el estado de la solicitud.
OpenAI dice que las sesiones persistentes le permitieron mantener información útil asociada a la propia conexión. Eso redujo el trabajo repetido de configuración y ayudó al sistema a reutilizar el contexto de forma más eficiente entre turnos. El resultado, según la empresa, fue una mejora de alrededor del 40% en la velocidad del bucle de agentes de extremo a extremo.
Para los usuarios, la importancia es clara. Si un agente de programación o investigación necesita muchas llamadas a herramientas para terminar un trabajo, recortar la sobrecarga de cada ciclo puede tener un efecto mayor que acelerar solo una etapa. Un flujo de trabajo que antes se sentía detenido entre acciones puede empezar a parecerse más a una interacción en vivo.
Qué optimizó OpenAI
- Caché asociada a la conexión para evitar repetir trabajo de configuración costoso.
- Menos saltos de red innecesarios entre servicios de API y servicios de inferencia.
- Comprobaciones de seguridad más rápidas en partes de la canalización de moderación y clasificación.
- Un canal WebSocket persistente para reducir el coste del uso de herramientas en múltiples turnos.
OpenAI enmarcó el trabajo como respuesta a un cambio más amplio en la industria: la inferencia está alcanzando una velocidad suficiente como para que los sistemas que la rodean determinen cada vez más la calidad percibida del producto. En ese entorno, un modelo puede pensar rápido, pero la experiencia aún puede sentirse lenta si las capas de orquestación se quedan atrás.
Por qué importa más allá de Codex
Aunque OpenAI ilustró el problema con Codex, las implicaciones se extienden a cualquier agente que use herramientas. Los asistentes empresariales, los sistemas de atención al cliente, los copilotos de investigación y los agentes de software dependen de muchas interacciones pequeñas en lugar de una única generación larga del modelo. Por tanto, las sesiones persistentes y una menor sobrecarga de orquestación podrían importar tanto como el rendimiento bruto en benchmarks.
La publicación también ofrece una mirada a un panorama competitivo en cambio. Durante años, los proveedores de modelos han enfatizado un mejor razonamiento y ventanas de contexto más grandes. Sin embargo, cada vez compiten también en ingeniería de sistemas: rendimiento, capacidad de respuesta, latencia de seguridad y con qué eficiencia un modelo puede mantenerse en el circuito con herramientas externas.
El mensaje de OpenAI es que la infraestructura alrededor del modelo es ahora una característica del producto en sí misma. Si las velocidades de inferencia siguen subiendo, eso probablemente será todavía más cierto.
La señal más grande
La conclusión más profunda no es solo que WebSockets sean más rápidos que las llamadas síncronas repetidas. Es que los productos de agentes están madurando hasta convertirse en sistemas de software en tiempo real cuyo rendimiento depende de la coordinación entre APIs, cachés, capas de seguridad y tiempos de ejecución de herramientas.
Eso convierte esta actualización en algo más que una nota de ingeniería. Es una señal de que las próximas mejoras en la utilidad de la IA pueden venir de reducir la fricción entre pasos del modelo, no solo de hacer que cada paso individual sea más inteligente. A medida que los sistemas agénticos asumen tareas más largas y complicadas, esa distinción podría determinar si se perciben como experimentales o como operativos.
Este artículo se basa en la cobertura de OpenAI. Leer el artículo original.
Originally published on openai.com
