OpenAI affirme que les correctifs de Codex peuvent augmenter l’utilisation jusqu’à 50 %

OpenAI indique que les utilisateurs de Codex devraient pouvoir aller 10 % à 50 % plus loin après que ses ingénieurs ont corrigé plusieurs bugs qui consommaient inutilement l’allocation d’utilisation. Cette mise à jour, relayée par Google News, incluait également une réinitialisation pour les utilisateurs payants de Codex et de ChatGPT Work. Cette combinaison peut donner l’impression d’une simple hausse de capacité, mais le chiffre mis en avant couvre plusieurs correctifs distincts et des charges de travail très variables.

Cette distinction importe, car OpenAI n’a pas annoncé une augmentation uniforme de 50 % des quotas. L’entreprise a indiqué que l’amélioration dépend de la manière dont chacun utilise Codex. Une personne exécutant des sessions riches en images peut observer un résultat, tandis qu’un utilisateur touché par un objectif qui s’emballe peut constater quelque chose de tout à fait différent.

Cette mise à jour intervient après des mois de plaintes concernant des allocations qui diminuaient plus vite que prévu. Certains signalements concernaient des restrictions isolées sur des comptes, tandis que d’autres faisaient état de boucles de modèles inutiles, d’appels répétés à des outils ou de programmations d’automatisation se déclenchant trop souvent. OpenAI a désormais reconnu plusieurs mécanismes susceptibles de gaspiller l’utilisation, mais n’a pas publié de benchmark reproductible concernant l’amélioration globale.

Le principal conflit n’oppose donc pas OpenAI à un autre assistant de programmation. Il oppose la promesse d’efficacité d’OpenAI à la visibilité limitée dont disposent les utilisateurs sur la mesure d’utilisation de Codex. L’entreprise affirme avoir corrigé des problèmes concrets, mais les clients ne peuvent toujours pas relier indépendamment chaque variation de quota à une réponse de modèle, un appel d’outil, un processus d’arrière-plan ou une automatisation défaillante.

Ce qu’OpenAI affirme avoir corrigé dans Codex

La mise à jour vise l’activité inutile des agents, et non une simple erreur de facturation ou une extension universelle des limites de compte.

Thibault Sottiaux, responsable de l’ingénierie chez OpenAI, a déclaré que l’entreprise avait examiné des milliers de signalements et déployé un ensemble de correctifs. Une republication publique de sa mise à jour sur l’utilisation répertorie des problèmes liés à la compaction du contexte, aux processus de mémoire, aux objectifs, aux automatisations et aux sous-agents.

La compaction du contexte consiste à raccourcir une longue conversation afin que l’agent puisse poursuivre dans sa fenêtre de contexte disponible. Selon Sottiaux, Codex conservait parfois d’anciennes images au cours de ce processus. Ces images pouvaient maintenir le contexte à un volume suffisant pour déclencher un nouveau cycle de compaction.

OpenAI estime que la correction de ce comportement a réduit l’utilisation d’environ 10 % pour les personnes travaillant fréquemment avec des images. Ce groupe peut inclure des développeurs demandant à Codex d’examiner des captures d’écran, des états de navigateur, des références de conception ou des échecs de tests visuels.

Le problème de mémoire était plus limité, mais présentait une longue traîne plus sévère. Les processus de mémoire en arrière-plan pouvaient hériter de hooks d’arrêt, c’est-à-dire des règles exécutées lorsqu’un agent tente de terminer. Un hook empêchant l’achèvement pouvait conduire un processus à vérifier de manière répétée s’il était autorisé à s’arrêter.

OpenAI a indiqué que moins de 1 % des utilisateurs étaient concernés. Toutefois, l’entreprise aurait identifié un fil ayant vérifié 15 000 fois s’il pouvait s’arrêter. Cet exemple montre pourquoi un bug d’orchestration apparemment rare peut consommer une capacité significative.

Les objectifs ont créé un autre mode de défaillance. Un objectif configuré pouvait être terminé, mais l’agent poursuivait parfois au-delà du point d’arrêt prévu. Codex pouvait également continuer à réessayer un outil défaillant au lieu de reconnaître que l’opération n’était plus productive.

OpenAI a indiqué que les exemples observés avaient consommé entre 15 % et 70 % d’une allocation hebdomadaire. Cette fourchette n’est pas une moyenne et ne doit pas être interprétée comme telle. Elle décrit des exemples issus d’une traîne problématique, dans laquelle le système n’a pas correctement cessé de travailler.

Les automatisations personnalisées pouvaient également s’exécuter plus fréquemment que ne le prévoyaient leurs calendriers. Une tâche non surveillée qui se déclenche trop souvent est particulièrement difficile à diagnostiquer, car l’utilisateur peut ne pas assister à la consommation lorsqu’elle se produit.

Le correctif concernant les sous-agents porte sur la sélection de modèles. Les sous-agents sont des agents auxiliaires qui traitent des parties déléguées d’une tâche plus vaste. OpenAI a indiqué que des modèles plus petits, dont Luna, pouvaient parfois sélectionner des assistants plus performants alors même que l’utilisateur ne les avait pas demandés.

Un assistant plus performant peut consommer l’allocation différemment du modèle que l’utilisateur s’attendait à exécuter. Corriger ce comportement devrait rendre l’exécution des tâches plus prévisible, même si OpenAI n’a pas publié d’estimation distincte des économies liées au changement des sous-agents.

Il s’agit de bugs techniquement distincts. L’un augmentait le contexte, un autre empêchait l’arrêt d’un processus, un autre ignorait la limite d’un objectif et un autre accroissait la fréquence des automatisations. Les regrouper sous un titre de 10 % à 50 % rend l’annonce facile à comprendre, mais masque d’importantes variations sous-jacentes.

La réinitialisation associée complique encore l’interprétation. Une réinitialisation renouvelle une allocation, tandis qu’un correctif d’efficacité modifie la vitesse à laquelle les futurs travaux la consomment. Les utilisateurs ayant reçu les deux changements simultanément ne peuvent pas évaluer l’amélioration technique en comparant leur tableau de bord avant et immédiatement après la mise à jour.

Pourquoi le titre de Google News doit être lu avec prudence

« Jusqu’à 50 % plus loin » décrit un résultat favorable pour une charge de travail donnée, et non une augmentation garantie pour chaque compte Codex payant.

Le rapport relayé par Google News reflète fidèlement la limite supérieure de la déclaration publique d’OpenAI. Toutefois, toute formulation du type « jusqu’à » exige un dénominateur. Les lecteurs doivent savoir quelle mesure d’utilisation s’est améliorée, quels modèles ont été testés et quels schémas de tâches ont produit le gain le plus important.

OpenAI n’a pas affirmé que chaque compte recevrait 50 % de capacité hebdomadaire supplémentaire. L’entreprise n’a pas non plus publié un calendrier simple montrant qu’une ancienne allocation était devenue 1,5 fois plus élevée. L’affirmation renvoie plutôt à la distance supplémentaire que devrait permettre l’utilisation existante après l’élimination de plusieurs sources de gaspillage.

Cette différence apparaît plus clairement avec un exemple hypothétique. Si une charge de travail déclenchait auparavant des cycles de compaction inutiles, la correction de ces cycles permet à la même allocation de prendre en charge davantage de travail utile. La limite nominale peut rester inchangée tandis que la capacité effective s’améliore.

Un autre utilisateur peut n’avoir jamais rencontré ce bug. Son gain issu du même correctif serait alors proche de zéro. Il peut toujours bénéficier de changements liés aux objectifs, aux outils, aux sous-agents ou au comportement d’attente, mais uniquement lorsque son flux de travail emprunte ces chemins.

Les propres conseils Codex d’OpenAI indiquent que la consommation dépend du modèle, de la complexité de la tâche, du contexte, du raisonnement, de la vitesse et des outils. Codex, ChatGPT Work et d’autres fonctionnalités d’agent éligibles peuvent également puiser dans une allocation et un pool de crédits partagés.

Ce système partagé rend les comparaisons informelles peu fiables. Une personne peut attribuer une modification du tableau de bord à une session de programmation Codex alors qu’une autre fonctionnalité d’agent a contribué à cette consommation. De même, deux prompts de formulation comparable peuvent consommer différemment lorsque l’un déclenche de nombreuses interactions avec des outils.

La fourchette de 10 % à 50 % doit donc être comprise comme une estimation opérationnelle. Elle indique qu’OpenAI s’attend à moins de gaspillage pour plusieurs types de charges de travail. Elle ne fournit pas de conversion stable entre prompts, tokens, tâches terminées et quota d’abonnement.

Google News est pertinent ici comme canal de découverte, et non comme origine de l’affirmation. La déclaration sous-jacente provenait d’un responsable de l’ingénierie d’OpenAI, tandis qu’un article indépendant l’a présentée à un public plus large. Google n’a pas testé Codex ni vérifié l’amélioration rapportée.

Cette attribution compte, car l’agrégation peut compresser l’incertitude. Un titre concis laisse peu de place pour distinguer une réinitialisation automatique, un processus d’arrière-plan réparé et une estimation d’efficacité. Les lecteurs peuvent facilement interpréter les trois comme une seule augmentation permanente de quota.

L’annonce ne comporte pas non plus de résultats de distribution. OpenAI n’a pas montré publiquement une amélioration médiane, une amélioration à un percentile élevé, ni la part des utilisateurs susceptibles de se situer près de l’une ou l’autre extrémité de la fourchette annoncée.

Sans ces informations, le chiffre de 50 % indique aux utilisateurs ce que certaines charges de travail devraient connaître, mais non la fréquence de ce résultat. La limite inférieure de 10 % peut être plus pertinente pour un groupe, tandis que des valeurs aberrantes auparavant affectées peuvent constater une récupération pratique bien plus importante.

C’est pourquoi la mise à jour ne doit pas être écartée comme un simple argument marketing. Les bugs révélés sont des sources spécifiques et plausibles de travail gaspillé. Toutefois, les éléments publics étayent l’affirmation selon laquelle l’efficacité devrait s’améliorer, et non la conclusion que chaque utilisateur de Codex dispose désormais de 50 % de capacité supplémentaire.

Les limites d’utilisation de Codex sont devenues un problème de fiabilité du produit

La consommation de quota détermine désormais si un agent peut terminer une tâche, faisant du comportement de mesure une composante de la fiabilité du produit.

Un chatbot conventionnel termine la plupart des interactions en une seule réponse. Un système agentique peut inspecter des fichiers, rechercher dans des dépôts, appeler des outils, attendre des processus, déléguer du travail et revenir sur des décisions antérieures. Une seule demande utilisateur peut donc produire de nombreux cycles de modèle sous-jacents.

Chaque cycle inutile compte. Une nouvelle tentative d’outil répétée ne retarde pas seulement une réponse. Elle peut consommer une allocation partagée, augmenter le contexte actif et créer de nouvelles occasions de réessais supplémentaires.

Cela rend un bug d’arrêt plus grave qu’un simple défaut d’interface maladroit. Si un objectif est déjà terminé, chaque action ultérieure représente du travail que l’utilisateur n’a pas demandé. Le système peut sembler actif tout en réduisant discrètement la capacité disponible pour les tâches ultérieures.

Le même problème s’applique à la compaction du contexte. La compaction est nécessaire lors de longues sessions, car un agent ne peut pas transporter un historique illimité dans chaque nouvelle requête au modèle. Toutefois, une stratégie de compaction défaillante peut traiter de manière répétée des informations qui auraient dû être écartées.

Les images sont particulièrement pertinentes, car elles peuvent occuper une part importante du contexte. Un développeur utilisant des captures d’écran pour déboguer une interface peut connaître une croissance du contexte plus agressive qu’une personne travaillant sur un petit dépôt uniquement textuel.

L’automatisation ajoute une couche de risque supplémentaire. Les utilisateurs créent souvent des travaux programmés précisément parce qu’ils ne veulent pas superviser chaque exécution. Si une programmation s’exécute trop fréquemment, les flux de travail les plus touchés sont également les moins susceptibles de recevoir une intervention humaine immédiate.

OpenAI avait déjà documenté un incident Codex plus limité en juin 2026. Son rapport d’état indiquait que certains comptes étaient incorrectement soumis à une limitation de débit par des systèmes de prévention des abus et de la fraude. L’entreprise a décrit l’impact comme limité et a indiqué ne pas avoir observé de dégradation plus large.

Cet incident et les derniers correctifs ne doivent pas être regroupés sous une même cause. Le problème de juin concernait une limitation de débit incorrecte pour certains comptes. La divulgation plus récente décrit plusieurs façons dont Codex pouvait effectuer du travail interne inutile.

Ensemble, ils expliquent toutefois pourquoi les signalements des utilisateurs ont été difficiles à interpréter. Une allocation diminuant rapidement peut résulter d’une longue tâche, d’un choix de modèle coûteux, d’une utilisation partagée d’agents, d’un contexte excessif, d’un objectif qui s’emballe ou d’une restriction au niveau du compte.

Les utilisateurs ne peuvent pas distinguer fiablement ces possibilités à l’aide d’une seule jauge de pourcentage. Ils peuvent examiner les heures de réinitialisation et les grandes catégories d’allocation, mais ils ne reçoivent pas de registre complet, tour par tour, associant chaque opération interne à la consommation de quota.

Le problème prend de l’ampleur à mesure que Codex dépasse le cadre du développement logiciel. OpenAI a indiqué en juin que Codex comptait plus de 5 millions d’utilisateurs actifs hebdomadaires, soit plus de six fois son audience après le lancement de l’application de bureau en février. L’entreprise a également déclaré que les travailleurs du savoir représentaient environ 20 % des utilisateurs dans son rapport d’adoption.

Ces utilisateurs demandent de plus en plus à Codex de créer des rapports, d’analyser des données, de préparer des présentations et d’automatiser des workflows. Ils peuvent avoir moins d’expérience dans le diagnostic d’une boucle d’agent que les développeurs qui inspectent régulièrement les journaux de processus.

L’échec d’une commande de terminal est visible. Un processus de mémoire en arrière-plan qui vérifie une condition d’arrêt des milliers de fois ne l’est pas. L’adoption plus large renforce donc l’importance d’explications d’usage compréhensibles par des personnes sans connaissance approfondie des systèmes.

Les équipes font face à un problème supplémentaire de planification. Un chef de projet ne peut pas facilement estimer combien de tâches déléguées une allocation hebdomadaire permettra de traiter lorsque la consommation dépend de la forme du contexte, du choix du modèle, du comportement des outils et d’une orchestration cachée.

Les correctifs réduisent plusieurs sources connues de variation. Ils n’éliminent pas le besoin d’une mesure prévisible. Pour que Codex devienne une infrastructure fiable, les utilisateurs doivent pouvoir faire confiance à la fois au travail qu’il accomplit et à la comptabilisation qui l’entoure.

Le véritable adversaire est le déficit de vérification

OpenAI a fourni un mécanisme d’amélioration crédible, mais les utilisateurs ne disposent toujours pas des données nécessaires pour reproduire son résultat phare.

Un ticket ouvert dans le dépôt Codex illustre ce déficit. Son auteur demande à OpenAI de définir ce que mesure l’affirmation selon laquelle « l’usage dure plus longtemps » et de divulguer la charge de travail, les modèles, les niveaux d’effort et la période d’observation qui sous-tendent de telles affirmations.

Le ticket explique également comment des étapes d’agent répétées peuvent multiplier la consommation. Lorsqu’un outil rend le contrôle au modèle, Codex peut retraiter le contexte de conversation avant de décider quoi faire ensuite. Des cycles supplémentaires peuvent ajouter des entrées mises en cache, du raisonnement et d’autres activités pondérées dans le quota.

Des tests communautaires cités dans l’analyse d’utilisation ont constaté que le regroupement explicite d’actions réduisait parfois la consommation estimée. Ces expériences sont des signaux utiles pour l’ingénierie, mais elles ne révèlent pas le registre d’abonnement privé d’OpenAI.

Leurs limites comptent. Les échantillons étaient réduits, les tâches tendaient vers des investigations riches en lecture, et certaines comparaisons portaient sur des conditions de contexte ou de raisonnement différentes. Le coût estimé équivalent à l’API n’est pas non plus la même chose qu’une variation réelle du quota Codex.

Le ticket identifie les principales questions sans réponse. OpenAI n’a pas publiquement défini si l’amélioration mesure les tokens bruts, l’usage interne pondéré, le travail achevé, la durée écoulée ou un autre indicateur indirect.

Elle n’a pas non plus fourni de résultats par percentile. Une moyenne unique masquerait encore les échecs de longue traîne décrits dans l’annonce. Les utilisateurs doivent savoir en quoi les charges de travail typiques diffèrent de celles qui déclenchaient auparavant des compactages répétés ou un comportement d’arrêt incontrôlable.

La frontière de déploiement demeure elle aussi floue. Certains correctifs peuvent être entièrement appliqués sur les serveurs d’OpenAI, tandis que d’autres peuvent dépendre d’une mise à jour de l’application Codex ou de la ligne de commande. La déclaration publique n’a pas fourni de version client minimale pour chaque modification.

Cette incertitude ne prouve pas que les améliorations sont fausses. Elle montre que l’affirmation n’est pas testable de manière indépendante à partir de données publiques. Les mécanismes divulgués correspondent aux comportements signalés par les utilisateurs, et chaque correctif devrait logiquement réduire le travail gaspillé.

Pourtant, la capacité effective n’est pas la même chose que la qualité des tâches achevées. Une optimisation qui réduit les cycles du modèle ne paraît efficace que si Codex produit toujours un résultat correct et complet. Un benchmark utile doit mesurer à la fois la consommation et le résultat.

La diversité des tâches compte également. La recherche dans un dépôt, le débogage d’interface, la génération de code, les tests de longue durée, l’automatisation de navigateur et le travail multi-agent sollicitent différentes parties du système. Un chiffre global unique ne peut pas indiquer aux utilisateurs comment chaque catégorie a évolué.

La réinitialisation crée aussi un problème de mesure temporaire. Supposons qu’un utilisateur compare son pourcentage hebdomadaire immédiatement avant et après son actualisation par OpenAI. Cela révèle la réinitialisation, et non la quantité économisée grâce au comportement d’agent réparé.

Un test plus propre commencerait après la réinitialisation et répéterait une tâche contrôlée. Il utiliserait le même état de dépôt, le même prompt, le même modèle, le même niveau de raisonnement, les mêmes autorisations, les mêmes outils et la même version client. Le test comparerait ensuite le travail achevé et les changements réels d’allocation.

Même cette approche a des limites, car les sorties des modèles sont probabilistes. Plusieurs exécutions seraient nécessaires, et leur ordre devrait alterner afin de réduire le biais environnemental. Les utilisateurs n’ont généralement ni le temps ni le quota nécessaires pour mener une telle étude.

OpenAI est mieux placée pour publier ces éléments. L’entreprise peut observer les opérations internes, identifier les cohortes affectées et distinguer les tokens du modèle de la surcharge d’orchestration. Elle peut également comparer les résultats sur des milliers de charges de travail en production sans exposer le contenu des clients.

En attendant, l’interprétation la plus défendable reste limitée. OpenAI a corrigé plusieurs comportements spécifiques qui gaspillaient parfois une part importante de l’allocation. L’entreprise prévoit que différents utilisateurs gagneront entre 10 % et 50 % d’usage effectif, mais le public ne peut pas encore reproduire cette fourchette.

Ce que les correctifs signifient pour les développeurs et les équipes

Le bénéfice pratique est la réduction des échecs invisibles, mais les équipes devraient toujours considérer le tableau de bord d’utilisation comme un outil de diagnostic limité.

Les développeurs qui s’appuient sur Codex pour de longues tâches de dépôt ont la raison la plus évidente de s’y intéresser. Un objectif qui continue après son achèvement peut gaspiller le budget restant nécessaire aux tests, à la revue ou à une correction de suivi.

Cette évolution peut améliorer la continuité du workflow même si les limites nominales restent fixes. Une plus grande part de l’allocation devrait être consacrée au travail demandé plutôt qu’à des vérifications d’arrêt répétées, des images obsolètes, des outils défaillants ou des modèles auxiliaires inattendus.

Le développement intensif en images peut bénéficier directement du correctif de compactage. Parmi les exemples courants figurent la revue de captures d’écran d’interface, la comparaison de pages rendues, l’examen de diagrammes ou le débogage de tests d’acceptation basés sur un navigateur.

Les utilisateurs ne devraient pas supposer que chaque tâche visuelle devient 10 % moins coûteuse. OpenAI a associé cette estimation aux personnes qui utilisent beaucoup les images, sans publier la définition de l’échantillon. La longueur du contexte et la structure de la tâche peuvent toujours modifier le résultat.

Les responsables de l’automatisation devraient examiner attentivement les tâches planifiées. OpenAI affirme avoir corrigé des planifications personnalisées qui pouvaient s’exécuter trop fréquemment, mais l’historique d’utilisation ne révèle pas automatiquement quelles exécutions étaient involontaires.

Une équipe peut comparer les horodatages d’automatisation avec son calendrier attendu. Des exécutions passées imprévues peuvent expliquer une consommation inhabituelle, même si elles ne peuvent pas prouver que le bug nouvellement divulgué a causé chaque écart.

Les workflows guidés par un objectif méritent une attention similaire. Les équipes devraient définir une condition d’achèvement observable et vérifier si la sortie finale y correspond. Le correctif devrait réduire la poursuite de l’exécution, mais des critères d’acceptation clairs restent utiles.

Les outils défaillants constituent un autre signal d’alerte. Si un service externe est indisponible ou si une commande ne peut pas réussir, les tentatives répétées peuvent devenir coûteuses. Un workflow bien conçu devrait définir des limites de relance et conserver suffisamment d’informations pour une tentative ultérieure.

Les utilisateurs de sous-agents devraient également examiner quels modèles participent au travail délégué lorsque cette information est disponible. Le correctif d’OpenAI devrait empêcher des modèles plus petits de sélectionner sans demande des assistants plus capables, améliorant l’alignement entre l’intention de l’utilisateur et le coût d’exécution.

Pour les organisations, ces changements renforcent la nécessité de disposer d’un historique consultable des prompts, décisions, journaux et sorties finales. Une base de connaissances d’ingénierie locale peut aider les équipes à relier un résultat inattendu aux fichiers et instructions qui l’entourent.

Cet historique ne remplace pas la télémétrie d’utilisation d’OpenAI. Il donne à une équipe ses propres éléments sur le périmètre des tâches, les défaillances d’outils et l’achèvement. Lorsqu’une allocation baisse de manière inattendue, ces détails rendent un rapport au support plus exploitable.

Les équipes devraient éviter de comparer de simples nombres de prompts. Une requête Codex peut répondre à partir d’un contexte existant, tandis qu’une autre lance des tests, recherche des fichiers, attend des processus et délègue du travail. Les unités de tâches achevées offrent une mesure opérationnelle plus utile.

Une métrique interne pratique pourrait suivre les modifications acceptées, les documents relus ou les analyses terminées par fenêtre d’allocation. Elle devrait également enregistrer les exécutions échouées, car un agent qui consomme moins mais produit un travail inutilisable n’a pas amélioré la productivité.

Les développeurs devraient distinguer les réinitialisations temporaires de l’efficacité récurrente. Un tableau de bord actualisé crée immédiatement une marge de manœuvre, mais la valeur durable dépend de la vitesse à laquelle des tâches équivalentes consomment ensuite cette marge.

La même prudence s’applique aux résumés Google News et aux publications sur les réseaux sociaux. Ce sont des outils de découverte utiles, mais les décisions opérationnelles devraient s’appuyer sur la déclaration d’origine et des preuves directes du produit. Un titre ne peut pas révéler si un workflow particulier a emprunté un chemin de code corrigé.

Les documents d’aide publiés par OpenAI renvoient les utilisateurs vers le tableau de bord d’utilisation et la commande /status pour les informations de compte. Ces outils montrent une disponibilité générale, mais ils ne fournissent pas une attribution complète par opération.

Si l’utilisation semble toujours incohérente, les utilisateurs devraient consigner le modèle, le niveau d’effort, la version client, l’heure de début de la tâche, les outils, les caractéristiques du contexte et la variation de quota observée. Cet ensemble donne à OpenAI une voie plus claire pour distinguer une consommation attendue d’un autre défaut.

Ce qu’il faut surveiller après le pic Google News

Le prochain test consiste à déterminer si OpenAI transforme une mise à jour corrective ponctuelle en efficacité Codex systématiquement mesurable.

Le premier signal est la stabilité de l’utilisation une fois l’effet de réinitialisation disparu. Sur plusieurs fenêtres d’allocation, des tâches comparables devraient consommer moins, ou au moins devenir plus prévisibles. Si les signalements de baisses inexpliquées continuent, les correctifs actuels n’ont traité qu’une partie du problème.

Cette observation doit tenir compte des changements de charge de travail. Un utilisateur qui change de modèle, active davantage de raisonnement, ajoute des outils ou élargit le contexte du dépôt ne peut pas effectuer une comparaison propre avant-après.

Le deuxième signal est une meilleure attribution. OpenAI expose déjà des informations générales d’utilisation, mais les utilisateurs ont besoin d’un lien plus clair entre les variations de quota et les tours de modèle, les boucles d’outils, les automatisations, les sous-agents et le travail en arrière-plan.

Un rapport par tâche faciliterait l’identification de futures régressions. Il réduirait également les spéculations lorsqu’un pourcentage visible change plus vite qu’un utilisateur ne l’attendait.

Le troisième signal est une méthodologie publiée pour la fourchette de 10 % à 50 %. OpenAI pourrait définir la métrique, décrire les charges de travail testées, indiquer les versions client concernées et présenter les résultats médians ainsi que ceux de longue traîne.

Cette divulgation renforcerait l’affirmation de l’entreprise même si certaines catégories obtenaient moins que le maximum mis en avant. Une amélioration transparente de 10 % sur une charge de travail définie est plus utile qu’un chiffre plus élevé que les utilisateurs ne peuvent pas relier à leur propre travail.

Le comportement des concurrents apportera un contexte complémentaire. Les autres fournisseurs d’agents font face à la même tension fondamentale entre de longues exécutions autonomes et des allocations prévisibles. Une comptabilisation d’utilisation plus claire peut devenir un avantage produit à mesure que les agents de codage prennent en charge des projets plus importants.

Pour l’instant, les développeurs devraient considérer cette mise à jour comme une maintenance importante assortie d’un problème de mesure non résolu. OpenAI a nommé plusieurs défauts concrets, décrit un comportement sévère pour certains cas atypiques, réinitialisé les utilisateurs payants et prévoit que l’allocation existante permettra d’accomplir davantage de travail.

L’incertitude restante porte sur l’ampleur, la distribution et la durabilité. Google News a largement mis en visibilité le plafond de 50 %, mais seuls des résultats répétés après réinitialisation peuvent montrer où se situent réellement les utilisateurs typiques.

Surveillez vos prochaines tâches comparables, consignez ce que fait Codex et distinguez le travail achevé du mouvement du tableau de bord. Si la même allocation produit désormais davantage de résultats acceptés, les correctifs fonctionnent là où cela compte. Si une consommation inexpliquée persiste, OpenAI devra mener une nouvelle phase d’ingénierie et fournir des preuves bien plus claires.