L’App Server de Codex constitue un autre élément architectural confirmé. OpenAI le décrit comme une API bidirectionnelle fondée sur JSON-RPC, qui relie la logique d’agent commune de Codex à plusieurs interfaces : application web, ligne de commande, extension pour IDE et application macOS . Le Codex CLI est par ailleurs présenté comme une implémentation de référence open source. Les développeurs peuvent utiliser directement le modèle via l’API ou s’appuyer sur le SDK Codex pour simplifier l’intégration .

Le tableau qui se dégage est donc celui d’un environnement d’exécution autour du modèle, combinant outils, état, retours et interfaces pour accomplir un travail en plusieurs étapes. Ces éléments ne suffisent pas à confirmer la mise à disposition, le 20 août, d’un produit nouvellement baptisé « Harness » sous licence Apache 2.0.

Ce que les éléments disponibles ne permettent pas d’affirmer

Les informations fournies ne démontrent pas :

• qu’une sortie a effectivement eu lieu le 20 août ;
• que cette sortie portait officiellement le nom « Harness » ;
• qu’elle était distribuée sous licence Apache 2.0 ;
• quels composants précis auraient été inclus dans le package annoncé ;
• quelles entreprises l’auraient adopté, ni quels résultats elles auraient obtenus.

La rumeur provient d’un article secondaire qui cite notamment codex exec, le SDK Codex et app-server comme éléments de cette prétendue sortie . Or les sources officielles fournies présentent ces fonctionnalités et composants à des dates différentes et dans des contextes distincts. Sans annonce officielle correspondante ni trace dans un dépôt de code, ils ne doivent pas être considérés comme la confirmation d’une nouvelle publication regroupée sous le nom de « Harness ».

Sur ARC-AGI-3, la mémoire d’exécution a compté autant que le modèle

Une expérience distincte d’OpenAI fournit le résultat le plus solide du dossier. Sur le jeu de tâches public d’ARC-AGI-3, GPT-5.6 Sol a obtenu 13,3 % avec le framework standard. Après activation du raisonnement conservé et de la compression du contexte via l’API Responses, son score est monté à 38,3 %, soit environ trois fois plus, tandis que la consommation de jetons de sortie a diminué d’un facteur d’environ six .

Les poids du modèle n’ont pas changé dans cette comparaison. La différence porte sur la manière dont l’environnement d’exécution transmet l’état d’un tour au suivant :

• Raisonnement conservé : une partie du travail intermédiaire utile peut persister d’une action à l’autre, au lieu d’obliger le modèle à reconstruire son approche à chaque étape.
• Compression du contexte : l’historique ancien est condensé lorsque la conversation s’allonge, plutôt que de disparaître purement et simplement.

Les recommandations d’OpenAI pour les développeurs présentent ces mécanismes comme des moyens de réutiliser le travail déjà effectué et de préserver la cohérence sur des tâches longues . Le résultat doit donc être interprété comme une mesure du système complet — modèle et environnement d’exécution — et non comme la preuve que le modèle seul serait devenu trois fois plus performant.

Il faut également garder en tête la limite de cette expérience : elle compare deux configurations d’exécution sur un jeu d’évaluation public. Elle ne garantit pas qu’un gain identique apparaîtra avec tous les agents, tous les modèles, toutes les charges de travail ou tous les environnements de production.

Les options concrètement disponibles pour les développeurs

La conclusion la mieux étayée n’est pas l’annonce Apache 2.0 non vérifiée, mais l’existence de plusieurs voies pour construire des applications autour du comportement agentique de Codex :

• Accès direct à l’API : le guide de prompting de Codex présente cette option comme la plus personnalisable .
• SDK Codex : il propose une intégration plus simple pour les équipes qui ne souhaitent pas assembler elles-mêmes toutes les interfaces .
• CLI open source : OpenAI le décrit comme une implémentation de référence que les développeurs peuvent examiner et adapter .
• Boucle d’exécution agentique : le cycle planifier–implémenter–valider–réparer constitue le modèle de fonctionnement des tâches de développement de longue durée .
• Exécution dans le cloud : Codex peut travailler sur des dépôts, exécuter du code et prendre en charge des tâches en arrière-plan, en parallèle .

Ces briques permettent d’intégrer un agent dans un produit ou un processus d’ingénierie, au lieu de le cantonner à une interface conversationnelle généraliste. Une équipe peut lui fournir des instructions propres à son domaine, des outils, des permissions, des étapes de validation et une stratégie de gestion de l’état. Cette orientation d’intégration est documentée ; en revanche, l’affirmation selon laquelle une unique sortie Apache 2.0 baptisée « Harness » formaliserait l’ensemble reste non confirmée par les sources officielles disponibles.

Les indices d’adoption sont plus limités que ne le laisse entendre la rumeur

Aucune source fournie n’identifie d’entreprise ayant adopté le framework Apache 2.0 présenté dans l’article secondaire. Aucune ne fournit non plus de résultats par entreprise pour des usages juridiques, opérationnels, scientifiques ou autres qui ne relèvent pas du développement logiciel.

OpenAI a toutefois publié un indicateur plus général sur l’usage de Codex par ses clients professionnels : en juin, Codex représentait 64 % des jetons de sortie combinés de Codex et de ChatGPT chez les clients entreprises . Ce chiffre suggère une activité importante autour de Codex dans les organisations, mais il ne prouve ni l’adoption du package « Harness », ni l’implication d’entreprises précises, ni un impact commercial déterminé.

Le véritable enjeu : passer de l’assistance à l’exécution déléguée

Le schéma vérifié pointe vers une évolution allant au-delà du chatbot. Codex associe un modèle à des outils, une boucle de retours, un état persistant ou compressé et des environnements capables d’exécuter une tâche sur plusieurs étapes .

Pour les équipes produit, cette architecture peut servir à créer des agents spécialisés pour des dépôts logiciels, des opérations internes, des travaux de recherche ou d’autres processus contrôlés. Leur qualité dépendra autant du choix du modèle que de la conception de l’accès aux outils, de la conservation de l’état, des limites de contexte, de la validation et de la récupération après une erreur.

C’est la leçon la plus durable de l’expérience ARC-AGI-3 : modifier le « harness », c’est-à-dire l’environnement qui encadre le modèle, peut modifier à la fois ses capacités observées et son efficacité. Mais au vu des preuves disponibles, il est plus exact de parler du runtime Codex documenté par OpenAI et de ses composants d’API que de présenter comme un fait établi la sortie, le 20 août, d’un « Harness » Apache 2.0.

L’App Server de Codex constitue un autre élément architectural confirmé. OpenAI le décrit comme une API bidirectionnelle fondée sur JSON-RPC, qui relie la logique d’agent commune de Codex à plusieurs interfaces : application web, ligne de commande, extension pour IDE et application macOS . Le Codex CLI est par ailleurs présenté comme une implémentation de référence open source. Les développeurs peuvent utiliser directement le modèle via l’API ou s’appuyer sur le SDK Codex pour simplifier l’intégration .

Le tableau qui se dégage est donc celui d’un environnement d’exécution autour du modèle, combinant outils, état, retours et interfaces pour accomplir un travail en plusieurs étapes. Ces éléments ne suffisent pas à confirmer la mise à disposition, le 20 août, d’un produit nouvellement baptisé « Harness » sous licence Apache 2.0.

Ce que les éléments disponibles ne permettent pas d’affirmer

Les informations fournies ne démontrent pas :

• qu’une sortie a effectivement eu lieu le 20 août ;
• que cette sortie portait officiellement le nom « Harness » ;
• qu’elle était distribuée sous licence Apache 2.0 ;
• quels composants précis auraient été inclus dans le package annoncé ;
• quelles entreprises l’auraient adopté, ni quels résultats elles auraient obtenus.

La rumeur provient d’un article secondaire qui cite notamment codex exec, le SDK Codex et app-server comme éléments de cette prétendue sortie . Or les sources officielles fournies présentent ces fonctionnalités et composants à des dates différentes et dans des contextes distincts. Sans annonce officielle correspondante ni trace dans un dépôt de code, ils ne doivent pas être considérés comme la confirmation d’une nouvelle publication regroupée sous le nom de « Harness ».

Sur ARC-AGI-3, la mémoire d’exécution a compté autant que le modèle

Une expérience distincte d’OpenAI fournit le résultat le plus solide du dossier. Sur le jeu de tâches public d’ARC-AGI-3, GPT-5.6 Sol a obtenu 13,3 % avec le framework standard. Après activation du raisonnement conservé et de la compression du contexte via l’API Responses, son score est monté à 38,3 %, soit environ trois fois plus, tandis que la consommation de jetons de sortie a diminué d’un facteur d’environ six .

Les poids du modèle n’ont pas changé dans cette comparaison. La différence porte sur la manière dont l’environnement d’exécution transmet l’état d’un tour au suivant :

• Raisonnement conservé : une partie du travail intermédiaire utile peut persister d’une action à l’autre, au lieu d’obliger le modèle à reconstruire son approche à chaque étape.
• Compression du contexte : l’historique ancien est condensé lorsque la conversation s’allonge, plutôt que de disparaître purement et simplement.

Les recommandations d’OpenAI pour les développeurs présentent ces mécanismes comme des moyens de réutiliser le travail déjà effectué et de préserver la cohérence sur des tâches longues . Le résultat doit donc être interprété comme une mesure du système complet — modèle et environnement d’exécution — et non comme la preuve que le modèle seul serait devenu trois fois plus performant.

Il faut également garder en tête la limite de cette expérience : elle compare deux configurations d’exécution sur un jeu d’évaluation public. Elle ne garantit pas qu’un gain identique apparaîtra avec tous les agents, tous les modèles, toutes les charges de travail ou tous les environnements de production.

Les options concrètement disponibles pour les développeurs

La conclusion la mieux étayée n’est pas l’annonce Apache 2.0 non vérifiée, mais l’existence de plusieurs voies pour construire des applications autour du comportement agentique de Codex :

• Accès direct à l’API : le guide de prompting de Codex présente cette option comme la plus personnalisable .
• SDK Codex : il propose une intégration plus simple pour les équipes qui ne souhaitent pas assembler elles-mêmes toutes les interfaces .
• CLI open source : OpenAI le décrit comme une implémentation de référence que les développeurs peuvent examiner et adapter .
• Boucle d’exécution agentique : le cycle planifier–implémenter–valider–réparer constitue le modèle de fonctionnement des tâches de développement de longue durée .
• Exécution dans le cloud : Codex peut travailler sur des dépôts, exécuter du code et prendre en charge des tâches en arrière-plan, en parallèle .

Ces briques permettent d’intégrer un agent dans un produit ou un processus d’ingénierie, au lieu de le cantonner à une interface conversationnelle généraliste. Une équipe peut lui fournir des instructions propres à son domaine, des outils, des permissions, des étapes de validation et une stratégie de gestion de l’état. Cette orientation d’intégration est documentée ; en revanche, l’affirmation selon laquelle une unique sortie Apache 2.0 baptisée « Harness » formaliserait l’ensemble reste non confirmée par les sources officielles disponibles.

Les indices d’adoption sont plus limités que ne le laisse entendre la rumeur

Aucune source fournie n’identifie d’entreprise ayant adopté le framework Apache 2.0 présenté dans l’article secondaire. Aucune ne fournit non plus de résultats par entreprise pour des usages juridiques, opérationnels, scientifiques ou autres qui ne relèvent pas du développement logiciel.

OpenAI a toutefois publié un indicateur plus général sur l’usage de Codex par ses clients professionnels : en juin, Codex représentait 64 % des jetons de sortie combinés de Codex et de ChatGPT chez les clients entreprises . Ce chiffre suggère une activité importante autour de Codex dans les organisations, mais il ne prouve ni l’adoption du package « Harness », ni l’implication d’entreprises précises, ni un impact commercial déterminé.

Le véritable enjeu : passer de l’assistance à l’exécution déléguée

Le schéma vérifié pointe vers une évolution allant au-delà du chatbot. Codex associe un modèle à des outils, une boucle de retours, un état persistant ou compressé et des environnements capables d’exécuter une tâche sur plusieurs étapes .

Pour les équipes produit, cette architecture peut servir à créer des agents spécialisés pour des dépôts logiciels, des opérations internes, des travaux de recherche ou d’autres processus contrôlés. Leur qualité dépendra autant du choix du modèle que de la conception de l’accès aux outils, de la conservation de l’état, des limites de contexte, de la validation et de la récupération après une erreur.

C’est la leçon la plus durable de l’expérience ARC-AGI-3 : modifier le « harness », c’est-à-dire l’environnement qui encadre le modèle, peut modifier à la fois ses capacités observées et son efficacité. Mais au vu des preuves disponibles, il est plus exact de parler du runtime Codex documenté par OpenAI et de ses composants d’API que de présenter comme un fait établi la sortie, le 20 août, d’un « Harness » Apache 2.0.