OpenAI suma WebSocket mode a la Responses API: menos latencia para agentes con muchas tools

OpenAI agrego WebSocket mode a la Responses API (registrado en el changelog del 23 de febrero de 2026) para un problema muy practico: cuando un agente hace muchas llamadas a herramientas (tool calls), el costo no es solo “pensar con el modelo”, sino tambien el overhead de repetir requests y streaming una y otra vez.

La idea es simple: en lugar de abrir una conexion HTTP por cada response.create, el cliente mantiene una conexion WebSocket y envia requests por el mismo canal. En la guia oficial, OpenAI detalla como iniciar sesion, como enviar response.create, como encadenar turnos con previous_response_id, y que limites/errores debes manejar.

Que cambia para builders (y por que importa)

Si hoy tienes un agente que:

• hace 10–50 llamadas a herramientas (RAG + HTTP + DB + “evals” internas),
• corre en un canal sensible a latencia (WhatsApp/Slack) o en un UI con streaming,
• o sufre “tiempos muertos” por tool calls encadenadas,

WebSocket mode vale la pena porque reduce el costo por turno de “pegarle a la API” y hace que el tiempo total se parezca mas a: modelo + herramientas + IO real, y menos a: modelo + herramientas + overhead repetido.

La consecuencia practica: puedes mover mas logica al agente (sin sentir que cada paso paga una penalizacion fija) o, mejor aun, puedes mantener tu agente igual pero con una experiencia mas fluida para el usuario final.

Lo no obvio: el tradeoff es operacional

WebSocket mode no es magia; es un cambio de “transporte” con reglas nuevas que te obligan a ser mas disciplinado.

En la guia oficial, OpenAI aclara cuatro cosas operativas clave:

1. Eventos y orden: los eventos siguen el mismo modelo de streaming de Responses.
2. Secuencialidad por conexion: una conexion puede recibir multiples response.create, pero corren secuencialmente (no hay multiplexing; solo un response “in-flight”).
3. Limite de duracion: la conexion tiene limite de 60 minutos; hay que reconectar.
4. Recuperacion: al reconectar, puedes continuar con previous_response_id si el response previo esta persistido (store=true), o reiniciar con contexto completo si no puedes encadenar (por ejemplo, ZDR / store=false).

Si vienes de HTTP + SSE, esto cambia como diseñas tu run loop: ahora tienes que pensar en pool de conexiones, reintentos, y en como “re-attach” el estado cuando una conexion muere a la mitad.

Checklist rapido para adoptarlo sin romper tu agente

Usa esta lista como “preflight” antes de migrar:

1. Define el umbral: migra primero flujos con tool calls altos (por ejemplo, >= 20) o donde la latencia duele de verdad.
2. Decide tu politica de estado:
   • Si necesitas continuar turnos con previous_response_id, asume store=true y diseña borrado/retencion.
   • Si estas en un escenario de ZDR o datos altamente sensibles, asume que algunos flujos no podran reanudarse tras reconexion y prepara “fallback” (re-enviar contexto minimo necesario).
3. Modela el concurrency: como no hay multiplexing, para paralelismo real necesitas multiples conexiones (o sharding por usuario/sesion).
4. Maneja errores explicitamente: la guia lista errores como previous_response_not_found (cadena rota) y websocket_connection_limit_reached (se acabo el tiempo). Con eso, diseña:
   • reconexion con backoff,
   • rehidratacion (si aplica),
   • degradacion a HTTP (si tu producto lo soporta) o reinicio controlado del flujo.
5. Observabilidad desde el primer dia: captura p95/p99 end-to-end por “run”, numero de tool calls, y tiempo por herramienta. Si no mides, no sabras si WebSocket mode te ayudo o solo movio el problema.
6. Seguridad: no “abras” herramientas solo porque ahora la latencia baja. Revisa scopes, timeouts por tool, y un allowlist de dominios si tu agente navega o consume URLs.

Un consejo pragmatico para LatAm

Muchos equipos en Latinoamerica operan con infraestructura mixta (Vercel/Cloudflare + un par de workers + un servidor de fondo). WebSocket mode puede ayudarte a que un agente “heavy” se sienta rapido, pero solo si tu arquitectura aguanta conexiones largas y reconexiones sin perder el hilo.

Si estas empezando, te conviene primero tener un agente con herramientas bien acotadas y trazabilidad. Este es un buen punto para repasar el curso gratis de despliegue y operacion: Instala Tu Propio Agente de IA. Y si tu agente llama tools propias, vale la pena complementar con la guia de la casa sobre control de herramientas: Function calling y herramientas: reglas para que un agente no rompa tu negocio.

La idea no es “pasarse a WebSockets porque es nuevo”, sino usarlo cuando tu agente ya esta pagando el impuesto de muchas vueltas. En esos casos, el cambio es muy concreto: menos overhead, mejor UX, y mas espacio para invertir en lo que realmente importa: calidad, seguridad, y evaluaciones.