WebSockets boostent Codex : API des réponses accélérée

Codex et l'optimisation des flux de travail avec l'API des réponses

Lorsqu'un utilisateur sollicite Codex pour corriger un bug, le processus implique une série d'étapes complexes. Codex analyse le code, identifie les fichiers pertinents, établit un contexte, effectue les modifications nécessaires et teste les corrections apportées. Ce processus repose sur de nombreuses requêtes à l'API des réponses, chaque étape nécessitant une interaction avec le modèle pour déterminer la prochaine action, exécuter des outils sur l'ordinateur de l'utilisateur, et renvoyer les résultats à l'API.

Ces interactions répétées peuvent entraîner des délais significatifs, obligeant les utilisateurs à patienter pendant que Codex exécute des tâches complexes. En termes de latence, la boucle d'agent de Codex consacre une grande partie de son temps à trois étapes principales : le traitement des requêtes par les services API, l'inférence du modèle, et le temps client pour l'exécution des outils et la construction du contexte. L'inférence, qui s'effectue sur des GPU, était historiquement l'étape la plus lente, masquant ainsi le surcoût des services API. Cependant, à mesure que l'inférence s'accélère, le coût cumulatif de l'API devient plus apparent.

Dans cet article, nous détaillons comment nous avons réussi à rendre les boucles d'agents utilisant l'API 40% plus rapides de bout en bout. Cela a permis aux utilisateurs de profiter d'une augmentation de la vitesse d'inférence, passant de 65 à près de 1 000 tokens par seconde. Nous avons atteint cet objectif grâce à des techniques telles que la mise en cache, l'élimination des sauts réseau inutiles, l'amélioration de notre pile de sécurité pour signaler rapidement les problèmes, et surtout, en établissant une connexion persistante avec l'API des réponses au lieu de multiplier les appels API synchrones.

L'API des réponses, un goulot d'étranglement

Les modèles précédents de l'API des réponses, tels que GPT-5 et GPT-5.2, fonctionnaient à environ 65 tokens par seconde (TPS). Avec le lancement de GPT-5.3-Codex-Spark, un modèle de codage rapide, notre objectif était d'atteindre une vitesse supérieure à 1 000 TPS, grâce à l'utilisation de matériel spécialisé Cerebras optimisé pour l'inférence LLM. Pour que les utilisateurs puissent réellement bénéficier de la rapidité de ce nouveau modèle, il était impératif de réduire le surcoût de l'API.

En novembre 2025, nous avons lancé un sprint de performance sur l'API des réponses, aboutissant à de nombreuses optimisations pour réduire la latence du chemin critique d'une requête unique :

• Mise en cache des tokens et de la configuration du modèle en mémoire pour éviter les appels coûteux de tokenisation et de réseau lors des réponses multi-tours.
• Réduction de la latence des sauts réseau en éliminant les appels à des services intermédiaires et en appelant directement le service d'inférence.
• Amélioration de notre pile de sécurité pour exécuter certains classificateurs et signaler les conversations plus rapidement.

Ces améliorations ont permis une réduction de près de 45% du temps jusqu'au premier token (TTFT), reflétant ainsi la réactivité de l'API. Cependant, même avec ces améliorations, le surcoût de l'API des réponses restait trop important par rapport à la vitesse du modèle, obligeant les utilisateurs à attendre que les CPU exécutent notre API avant de pouvoir utiliser les GPU servant le modèle.

Le problème était structurel : chaque requête Codex était traitée comme indépendante, nécessitant le traitement de l'état de la conversation et d'autres contextes réutilisables dans chaque requête de suivi. Même lorsque la plupart de la conversation restait inchangée, nous devions toujours traiter l'historique complet, ce qui devenait coûteux à mesure que les conversations s'allongeaient.

Vers une connexion persistante

Pour optimiser notre design, nous avons repensé le protocole de transport : pouvions-nous maintenir une connexion persistante et mettre en cache l'état, plutôt que d'établir une nouvelle connexion via HTTP et d'envoyer l'historique complet de la conversation pour chaque requête de suivi ? L'idée était d'envoyer uniquement les nouvelles informations nécessitant validation et traitement, tout en mettant en cache l'état réutilisable en mémoire pendant la durée de la connexion. Cela réduirait le surcoût dû au travail redondant.

Nous avons exploré plusieurs approches, notamment WebSockets et le streaming bidirectionnel gRPC. Nous avons choisi WebSockets car, en tant que protocole de transport de messages simple, il permettait aux utilisateurs de ne pas modifier leurs formes d'entrée et de sortie de l'API des réponses. Cette solution était conviviale pour les développeurs et s'intégrait à notre architecture existante avec peu de perturbations.

Le premier prototype WebSocket a changé notre perception de ce qui était possible en matière de latence de l'API des réponses. Un ingénieur de l'équipe Codex, expert dans l'ensemble de la pile API, a développé un prototype en faisant fonctionner un agent Codex pendant la nuit.

Dans ce prototype, les déploiements agentiques étaient modélisés comme une seule réponse longue. En utilisant les fonctionnalités d'asyncio, l'API des réponses bloquait de manière asynchrone dans la boucle d'échantillonnage après qu'un appel d'outil ait été échantillonné, et l'API des réponses renvoyait un événement response.done au client. Après l'exécution de l'appel d'outil, les clients renvoyaient un événement response.append avec le résultat de l'outil, ce qui débloquait la boucle d'échantillonnage et permettait au modèle de continuer.

Une analogie ici est de traiter l'appel d'outil local comme un appel d'outil hébergé. Lorsque le modèle appelle la recherche web, la boucle d'inférence se bloque, appelle un service de recherche web, et place la réponse du service dans le contexte du modèle. Dans notre conception, nous avons fait la même chose ; 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 a répondu, nous avons intégré la réponse de l'appel d'outil du client dans le contexte et continué à échantillonner.

Ce design était extrêmement efficace car il éliminait le travail API répété à travers un déploiement agentique. Nous pouvions effectuer le travail de pré-inférence une fois, faire une pause pour l'exécution de l'outil, et effectuer le travail de post-inférence une fois à la fin.

Malheureusement, cela a eu pour coût une forme d'API moins familière et plus compliquée. Nous voulions que les développeurs puissent intégrer le support WebSocket sans avoir à réécrire leur intégration API autour d'un nouveau mode d'interaction.

Maintenir la familiarité de l'API tout en rendant la pile incrémentale

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

Sur une connexion WebSocket, le serveur maintient un cache en mémoire de l'état de la réponse précédente, spécifique à la connexion. Lorsqu'une réponse de suivi response.create inclut previous_response_id, nous récupérons cet état du cache au lieu de reconstruire la conversation complète depuis le début.

Cet état mis en cache comprend :

• L'objet de réponse précédent
• Les éléments d'entrée et de sortie précédents
• Les définitions et espaces de noms des outils
• Les artefacts d'échantillonnage réutilisables, comme les tokens précédemment rendus

En réutilisant l'état de réponse précédent en mémoire, nous avons pu réaliser plusieurs optimisations majeures :

• Faire en sorte que certains de nos classificateurs de sécurité et validateurs de requêtes traitent uniquement les nouvelles entrées, et non l'historique complet à chaque fois.
• Maintenir un cache en mémoire des tokens rendus que nous complétons afin de pouvoir éviter une tokenisation inutile.
• Réutiliser notre logique de résolution/routage de modèle réussie à travers les requêtes.
• Superposer le travail de post-inférence non-bloquant comme la facturation avec les requêtes suivantes.

L'objectif était de se rapprocher le plus possible du prototype à faible surcoût mais avec une forme d'API que les développeurs comprenaient déjà et autour de laquelle ils avaient construit.

Établir une nouvelle référence pour la vitesse

Après un sprint de deux mois à construire le mode WebSocket, nous avons lancé une version alpha avec des startups clés d'agents de codage afin qu'elles puissent l'intégrer dans leur infrastructure et augmenter progressivement le trafic en toute sécurité. Les utilisateurs alpha l'ont adoré, signalant jusqu'à 40% d'améliorations dans leurs flux de travail agentiques. Étant donné les retours positifs de l'alpha, nous étions prêts à lancer.

Les résultats du lancement ont été immédiats. Codex a rapidement transféré la majorité de son trafic de l'API des réponses 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 et avons observé des pics allant jusqu'à 4 000 TPS, montrant que l'API des réponses pouvait suivre une inférence beaucoup plus rapide dans un trafic de production réel. L'impact s'est également rapidement manifesté dans la communauté des développeurs :

• Codex a rapidement transféré la majorité de son trafic vers les WebSockets.
• Les utilisateurs de Codex utilisant les derniers modèles tels que GPT-5.3-Codex, GPT-5.4, et au-delà bénéficient tous de l'accélération du mode WebSocket.
• Vercel a intégré le mode WebSocket dans le SDK AI et a constaté une diminution de latence allant jusqu'à 40%.
• Les flux de travail multi-fichiers de Cline sont 39% plus rapides.
• Les modèles OpenAI dans Cursor sont devenus jusqu'à 30% plus rapides.

Le mode WebSocket est l'une des capacités nouvelles les plus significatives de l'API des réponses depuis son lancement en mars 2025. Nous sommes passés de l'idée à la production en seulement quelques semaines grâce à une collaboration étroite entre les équipes API d'OpenAI et Codex. Cela améliore non seulement de manière spectaculaire la latence des déploiements d'agents, mais soutient également un besoin croissant pour les créateurs : à mesure que l'inférence des modèles devient plus rapide, les services et systèmes qui entourent l'inférence doivent également s'accélérer pour transférer ces gains aux utilisateurs.