OpenAI WebSocket Mode for Responses API

Le mode WebSocket garde une connexion ouverte vers l'API Responses pendant de nombreux tours. Vous le pilotez avec des événements response.create, et le premier démarre un nouveau tour comme une requête normale. Comme le socket reste ouvert, vous évitez la configuration de connexion que l'API de streaming standard paie à chaque tour. Cette surcharge est faible une fois. Sur une longue exécution d'agent, elle ne l'est plus.

Chaque tour de suite n'envoie que les nouveaux éléments d'entrée, plus un previous_response_id qui renvoie au tour précédent. Vous ne réexpédiez pas tout le contexte, et c'est là que se trouve l'essentiel de l'économie dans les longues chaînes. La charge utile du premier tour reprend le corps create standard, moins les champs propres au transport comme stream et background, qui ne s'appliquent pas ici. La requête reste donc légère même quand la conversation grandit.

Le bénéfice phare apparaît dès qu'un workflow implique beaucoup d'allers-retours entre modèle et outil. C'est le monde des workflows d'agents à faible latence, et ce transport a été conçu pour eux. Les recommandations d'OpenAI évoquent un gain de vitesse notable sur les déploiements à nombreux appels d'outils, le gain venant du chemin de continuation et pas seulement du premier token, précisément la partie qui fait perdre le plus de temps quand un agent repasse sans cesse par les mêmes outils. Tous les workflows ne le ressentent pas. Si votre agent appelle à peine des outils, vous ne verrez pas grand-chose. S'il les appelle en permanence, c'est tout l'intérêt.

Le mode WebSocket fonctionne avec store=false et les configurations de rétention zéro des données, ce qui compte si vous ne pouvez pas laisser OpenAI conserver l'état des réponses. Le serveur garde l'état récent de la réponse en mémoire pendant la durée de vie de la connexion, donc vous obtenez des continuations rapides sans persister les tours entre les requêtes, ce qui laisserait sinon des données derrière sur le serveur. Pour les équipes en environnement réglementé ou sensible à la vie privée, cette combinaison est la raison de choisir ce transport.

Les événements du serveur et leur ordre correspondent au modèle de streaming existant de Responses. Si vous gérez déjà des événements de streaming en HTTP, les formes des événements vous sembleront familières, donc vous n'avez pas à réécrire la logique de votre client de zéro. La différence tient au canal de livraison, pas au format du message. Alors pourquoi changer ? Pour la vitesse, dans les cas où elle compte. Cela garde le coût de migration bas.