OpenAI WebSocket Mode for Responses API

El modo WebSocket mantiene una conexión abierta a la API Responses durante muchos turnos. Lo controlas con eventos response.create, y el primero arranca un turno nuevo igual que una petición normal. Como el socket sigue abierto, te saltas la configuración de conexión que la API de streaming estándar paga en cada turno. Ese sobrecoste es pequeño una vez. En una ejecución larga de agente, ya no lo es.

Cada turno de seguimiento envía solo los elementos de entrada nuevos, más un previous_response_id que enlaza con el turno anterior. No reenvías todo el contexto, y ahí está la mayor parte del ahorro en cadenas largas. El payload del primer turno replica el cuerpo estándar de create, menos los campos exclusivos del transporte como stream y background, que aquí no aplican. Así la petición se mantiene ligera aunque la conversación crezca.

El beneficio estrella aparece cuando un flujo implica muchos viajes de ida y vuelta entre modelo y herramienta. Ese es el mundo de los flujos de agentes de baja latencia, y este transporte se construyó para ellos. La guía de OpenAI apunta a una mejora de velocidad notable en despliegues con muchas llamadas a herramientas, con la ganancia viniendo del camino de continuación y no solo del primer token, que es justo la parte que más tiempo pierde cuando un agente recorre las mismas herramientas una y otra vez. No todos los flujos lo notan. Si tu agente apenas llama a herramientas, no vas a notar gran cosa. Si las llama sin parar, ahí está todo el sentido.

El modo WebSocket funciona con store=false y con configuraciones de retención cero de datos, algo que importa si no puedes permitir que OpenAI guarde el estado de las respuestas. El servidor mantiene el estado reciente de la respuesta en memoria durante la vida de la conexión, así que sigues teniendo continuaciones rápidas sin persistir los turnos entre peticiones, que de otro modo dejarían datos atrás en el servidor. Para equipos en entornos regulados o sensibles a la privacidad, esa combinación es la razón para elegir este transporte.

Los eventos del servidor y su orden coinciden con el modelo de streaming actual de Responses. Si ya gestionas eventos de streaming por HTTP, las formas de los eventos te resultarán familiares, así que no tienes que reescribir la lógica de tu cliente desde cero. La diferencia está en el canal de entrega, no en el formato del mensaje. Entonces, ¿por qué cambiar? Por velocidad, en los casos donde cuenta. Eso mantiene bajo el coste de migración.