Accélérer les workflows agentiques grâce aux WebSockets dans l’API Responses

Lorsque vous demandez à Codex de corriger un bug, il parcourt votre base de code à la recherche des fichiers pertinents, les analyse pour construire le contexte, effectue les modifications nécessaires, puis exécute des tests pour vérifier que le correctif fonctionne. En arrière plan, cela se traduit par des dizaines d’allers-retours avec l’API Responses : déterminer la prochaine action du modèle, exécuter un outil sur votre machine, renvoyer le résultat à l’API, puis recommencer.

Toutes ces requêtes peuvent rapidement s’accumuler et représenter plusieurs minutes d’attente pour les utilisateurs, le temps que Codex termine des tâches complexes. Du point de vue de la latence, la boucle agentique de Codex passe l’essentiel de son temps a effectuer trois grandes étapes : le traitement côté services API (pour valider et traiter les requêtes), l’inférence du modèle, et le temps côté client (exécution des outils et construction du contexte du modèle). L’inférence est l’étape au cours de laquelle le modèle s’exécute sur des GPU pour générer de nouveaux tokens. Par le passé, l’inférence LLM sur GPU constituait la partie la plus lente de la boucle agentique ; il était donc facile de masquer la surcharge du service API. Alors que l’inférence s’accélère, la surcharge cumulée de l’API liée à un déploiement piloté par des agents devient beaucoup plus notable.

Dans cet article, nous expliquerons comment nous avons rendu les boucles de l’agent utilisant l’API 40 % plus rapides de bout en bout, permettant aux utilisateurs de constater le bond de la vitesse d’inférence, passée de 65 à près de 1 000 tokens par seconde. Nous avons abordé ce problème grâce à la mise en cache, en éliminant les sauts réseau inutiles, en améliorant notre dispositif de sécurité pour signaler rapidement les problèmes et—surtout—en créant un moyen d’établir une connexion persistante à l’API Responses, au lieu de devoir effectuer une série d’appels d’API synchrones.

Dans l’API Responses, les précédents modèles phares comme GPT‑5 et GPT‑5.2 fonctionnaient à environ 65 tokens par seconde (TPS). Pour le lancement de GPT‑5.3‑Codex‑Spark, un modèle de code rapide, notre objectif était d’atteindre des performances multipliées par 10 : plus de 1 000 TPS, rendu possible grâce à un matériel spécialisé de Cerebras Systems optimisé pour l’inférence des LLM. Pour nous assurer que les utilisateurs puissent profiter de la véritable vitesse de ce nouveau modèle, nous avons dû réduire la surcharge liée à l’API. 

Vers novembre 2025, nous avons lancé un sprint d’optimisation des performances sur l’API Responses, en déployant de nombreuses améliorations visant à réduire la latence sur le chemin critique pour une requête unique : 

• Mise en cache en mémoire des tokens générés et de la configuration du modèle afin d’éviter des opérations coûteuses de tokenisation et des appels réseau dans les échanges multi-tours
• Réduction de la latence liée aux sauts réseau en supprimant les appels aux services intermédiaires (par exemple pour le traitement d’images) et en appelant directement le service d’inférence lui-même
• Amélioration de notre pile de sécurité afin de pouvoir exécuter certains classificateurs plus rapidement pour détecter les conversations à risque

Grâce à ces améliorations, nous avons observé une réduction d’environ 45 % du temps jusqu’au premier token (TTFT)—un indicateur de la réactivité perçue de l’API—mais cela restait insuffisant pour GPT‑5.3‑Codex‑Spark. Même avec ces améliorations, la surcharge liée à l’API Responses restait trop importante par rapport à la vitesse du modèle : autrement dit, les utilisateurs devaient attendre que les CPU exécutant notre API aient terminé avant de pouvoir tirer parti des GPU qui servent le modèle.

Le problème de fond était structurel : nous traitions chaque requête Codex comme indépendante, en retraitant l’état de la conversation et d’autres éléments de contexte réutilisables à chaque requête de suivi. Même lorsque la majeure partie de la conversation n’avait pas changé, nous continuions à payer le coût du traitement de l’ensemble de l’historique. Alors que les discussions s’allongeaient, ce traitement répété devenait plus coûteux.

Pour optimiser l’architecture, nous avons repensé le protocole de transport : pouvait-on maintenir une connexion persistante et mettre en cache l’état, plutôt que d’établir une nouvelle connexion via HTTP et d’envoyer l’intégralité de l’historique de la conversation à chaque requête de suivi ? L’idée était de n’envoyer que les nouvelles informations nécessitant une validation et un traitement, tout en conservant en mémoire l’état réutilisable pendant toute la durée de la connexion. Cela réduirait la charge liée au travail redondant.

Nous avons envisagé plusieurs approches, notamment les WebSockets et le streaming bidirectionnel via gRPC. Nous avons retenu les WebSockets car, en tant que protocole de transport de messages simple, ils permettent aux utilisateurs de conserver les mêmes formats d’entrée et de sortie de l’API Responses. La solution était adaptée aux développeurs et s’intégrait à notre architecture existante avec très peu de perturbations.

Le premier prototype basé sur les WebSockets a redéfini ce que nous pensions possible en matière de latence pour l’API Responses. Un ingénieur de l’équipe Codex, doté d’une expertise approfondie sur l’ensemble de la pile API, a rapidement assemblé un prototype en faisant tourner un agent Codex pendant la nuit.

Dans ce prototype, les exécutions agentiques étaient modélisées comme une seule réponse de longue durée. En s’appuyant sur les fonctionnalités de asyncio, l’API Responses se mettait en attente de manière asynchrone dans la boucle d’échantillonnage suite à la sélection d’un appel d’outil, puis envoyait un événement response.done au client. Après avoir exécuté l’appel d’outil, les clients renvoyaient un événement response.append contenant le résultat, ce qui débloquait la boucle d’échantillonnage et permettait au modèle de poursuivre.

Une analogie consiste ici à traiter l’appel d’outil local comme un appel d’outil hébergé. Lorsque le modèle appelle une recherche web, la boucle d’inférence se met en attente, appelle un service de recherche, puis injecte la réponse du service dans le contexte du modèle. Dans notre conception, nous avons procédé de la même manière ; mais au lieu d’appeler un service distant, nous avons renvoyé l’appel d’outil du modèle au client via le WebSocket. Lorsque le client répondait, nous intégrions le résultat de l’appel d’outil dans le contexte, puis poursuivions l’échantillonnage.

Cette approche s’est révélée extrêmement efficace, car elle éliminait le travail répétitif côté API tout au long de l’exécution agentique. Nous pouvions effectuer les opérations de pré-inférence une seule fois, mettre en pause pour l’exécution des outils, puis effectuer les opérations de post-inférence une seule fois à la fin.

Malheureusement, cela s’est fait au prix d’une structure d’API moins familière et plus complexe. Nous voulions permettre aux développeurs d’ajouter la prise en charge des WebSockets sans avoir à réécrire leur intégration API autour d’un nouveau mode d’interaction.

Pour la version que nous avons lancée, nous sommes revenus à une structure familière : continuer à utiliser response.create avec le même corps de requête, et utiliser previous_response_id pour prolonger le contexte de la conversation à partir de l’état de la réponse précédente.

Sur une connexion WebSocket, le serveur conserve en mémoire, à l’échelle de la connexion, un cache de l’état des réponses précédentes. Lorsqu’un response.create de suivi inclut previous_response_id, nous récupérons cet état depuis le cache au lieu de reconstruire l’intégralité de la conversation depuis zéro.

Cet état mis en cache inclut :

• L’objet response précédent
• Éléments d’entrée et de sortie précédents
• Définitions d’outils et espaces de noms
• Artefacts d’échantillonnage réutilisables, comme des tokens précédemment générés

En réutilisant l’état en mémoire de la réponse précédente, nous avons pu mettre en place plusieurs optimisations majeures :

• Faire en sorte que certains de nos classificateurs de sécurité et validateurs de requêtes ne traitent que les nouvelles entrées, plutôt que l’historique complet à chaque fois
• Conserver en mémoire un cache des tokens générés, auquel nous ajoutons les nouveaux éléments, afin d’éviter des opérations de tokenisation inutiles
• Conserver en mémoire un cache des tokens générés, auquel nous ajoutons les nouveaux éléments, afin d’éviter des opérations de tokenisation inutiles 
• Superposer des opérations de post-inférence non bloquantes, comme la facturation, avec les requêtes suivantes

L’objectif était de se rapprocher autant que possible du prototype à surcharge minimale, tout en conservant une structure d’API déjà familière pour les développeurs et autour de laquelle ils ont construit leurs intégrations.

Après un sprint de deux mois consacré au développement du mode WebSocket, nous avons lancé une version alpha avec plusieurs startups clés spécialisées dans les agents de code, afin qu’elles puissent l’intégrer à leur infrastructure et augmenter progressivement le trafic en toute sécurité. Les utilisateurs de la version alpha ont été conquis, rapportant des gains pouvant atteindre 40 %⁠(ouverture dans une nouvelle fenêtre) dans leurs workflows agentiques. Au vu des retours positifs de la phase alpha, nous étions prêts à lancer la solution.

Les résultats du lancement ont été immédiats. Codex a rapidement basculé la majorité de son trafic sur l’API Responses vers le mode WebSocket, constatant des améliorations significatives de latence. Pour GPT‑5.3‑Codex‑Spark, nous avons atteint notre objectif de 1 000 TPS, avec des pics allant jusqu’à 4 000 TPS, démontrant que l’API Responses pouvait suivre des vitesses d’inférence nettement plus élevées en conditions réelles de production. L’impact n’a pas tardé à se faire sentir dans la communauté des développeurs  :

• Codex a rapidement basculé la majeure partie de son trafic vers WebSockets. Les utilisateurs de Codex qui utilisent les derniers modèles tels que GPT‑5.3‑Codex⁠(ouverture dans une nouvelle fenêtre), GPT‑5.4⁠(ouverture dans une nouvelle fenêtre), et ultérieurs bénéficient de la rapidité accrue du mode WebSocket.
• Vercel a intégré le mode WebSocket dans son AI SDK et a constaté une réduction de la latence pouvant atteindre 40 %⁠(ouverture dans une nouvelle fenêtre).
• Les workflows à plusieurs fichiers de Cline sont 39 % plus rapides⁠(ouverture dans une nouvelle fenêtre).
• Les modèles OpenAI dans Cursor sont devenus jusqu’à 30 % plus rapides⁠(ouverture dans une nouvelle fenêtre).

Le mode WebSocket compte parmi les nouvelles fonctionnalités les plus importantes de l’API Responses depuis son lancement en mars 2025. Nous sommes passés de l’idée à une mise en production en quelques semaines seulement, grâce à une étroite collaboration entre les équipes API d’OpenAI et Codex. Cela améliore non seulement de manière significative la latence des exécutions agentiques, mais répond aussi à un besoin croissant des développeurs : alors que l’inférence des modèles s’accélère, les services et systèmes qui l’entourent doivent eux aussi gagner en vitesse afin de répercuter ces gains auprès des utilisateurs.