GPT-6 Astra dans Codex : notes inter-fenêtres, niveaux d’effort et la facture réelle

GPT-6 Astra est un modèle du 2026-09-03, et cette page n'est pas une couverture de lancement — c'est la référence pour diriger votre agent de codage vers lui maintenant qu'il est largement disponible. La raison pour laquelle un développeur opterait pour ce modèle tient à un mécanisme précis, et il vaut la peine de le comprendre avant d'y dépenser quoi que ce soit : au lieu de compacter une longue session en un seul résumé avec perte à chaque fois que la fenêtre se remplit, Codex avec GPT-6 Astra conserve des notes d'une fenêtre de contexte à l'autre et laisse les fenêtres de contexte antérieures consultables, ainsi une exigence que vous avez énoncée il y a quarante tours et la sortie de test qui a échoué il y a dix tours sont toutes deux encore récupérables plutôt que d'être effacées par un résumé. OpenAI qualifie la fonctionnalité d'expérimentale, l'active avec une ligne dans votre config.toml de Codex, et indique qu'elle deviendra la valeur par défaut pour Astra. Tout ce qui suit — la configuration exacte, les niveaux d'effort, les résultats mesurés et une facture de session détaillée qui nomme la ligne d'entrée mise en cache — a été lu sur les propres pages d'OpenAI le 2026-09-16, et chaque chiffre provenant de tiers est signalé comme tel.

Deux choses se sont produites cette semaine qui modifient l'arithmétique de son adoption. Le 2026-09-12, le responsable de Codex chez OpeAI a publié un post-mortem confirmant que l'expérience de gestion du contexte elle-même comportait un bug — elle provoquait des arrêts prématurés et des réponses à des messages obsolètes, et a été désactivée pour les quelque 4 000 à 5 000 utilisateurs concernés — et OpeAI a procédé à une réinitialisation complète de l'usage pour les utilisateurs de Codex et d'Astra à minuit, du 09-12 au 09-13. La même semaine, les espaces de travail d'entreprise qui avaient Astra désactivé par défaut au lancement sont devenus administrables selon leur propre grille tarifaire. Donc, la position honnête est la suivante : le mécanisme mérite d'être adopté, la version continue de bouger sous vos pieds, et vous devriez l'essayer sur une branche plutôt que sur une échéance.

Qu'est-ce qui est réellement nouveau dans Co​dex avec GPT-6 Astra ?

Demandez à n’importe quel agent de codage de travailler pendant six heures et vous vous heurtez au même mur. La fenêtre de contexte se remplit, le harnais résume la transcription en un bloc dense pour faire de la place, et le résumé est lossy exactement de la manière qui fait mal — la raison pour laquelle un correctif antérieur a échoué, la forme exacte d’un test en échec, une contrainte que l’utilisateur a mentionnée en passant au troisième tour. Le détail récupéré, et non le détail résumé, est ce que vous vouliez réellement.

L'intégration de Co​dex à Astra modifie cet état de fait. La documentation Co​dex d'Ope​nAI l'énonce sans détour : « Astra conserve des notes d'une fenêtre de contexte à l'autre et peut rechercher les messages et les résultats d'outils antérieurs d'une même tâche. » Les notes sont durables et inscriptibles ; l'historique qui les sous-tend reste lisible, de sorte qu'une fenêtre antérieure peut encore être parcourue pour retrouver la preuve d'origine, même après la rédaction de la note correspondante. Les exigences et les résultats de test issus des messages antérieurs et de la sortie des outils restent trouvables.

Ope​nAI est explicite : ce n'est pas un travail terminé. Sa référence de configuration décrit l'indicateur comme « Enable experimental context management (off by default) » et indique que la fonctionnalité « uses notes and searchable history to preserve accumulated details ». La documentation précise également qu'elle « isn't available with Business, Enterprise, or API-key sign-in at launch ». Il ne s'agit pas non plus d'un contexte infini — le modèle raisonne toujours à l'intérieur d'une fenêtre finie, et chaque relecture d'une note antérieure consomme le budget d'entrée de ce tour. La fenêtre est de 1 050 000 tokens, avec un maximum de 922 000 tokens d'entrée, selon la documentation des modèles d'Ope​nAI ; le mécanisme des notes vient se greffer par-dessus, il ne le remplace pas.

La config, exactement telle qu'OpenAI la documente

Le paramètre est un enfant de la table [features] dans votre fichier config.toml de Co​dex — le fichier se trouve dans ~/.codex/ sauf si vous avez redéfini CODEX_HOME. Le chemin de clé documenté est features.context_management.experimental_mode, un booléen, et la valeur est true :

[features.context_management]
experimental_mode = true

Si vous avez déjà une table [features] dans le fichier, ajoutez la clé relative à l'intérieur de celle-ci plutôt que de déclarer la table deux fois :

[features]
context_management.experimental_mode = true

Utilisez l’une ou l’autre forme. Les retours de la communauté concernant ce flag indiquent que déclarer le chemin en notation pointée à la racine puis ouvrir une table [features] plus loin dans le même fichier peut faire échouer l’analyse, car la table est alors considérée comme redéclarée, ce qui est une règle TOML et non une règle d’Ope​nAI — mais cela piège les utilisateurs, alors choisissez une forme et tenez-vous-y. Après modification, démarrez une nouvelle tâche : le réglage ne s’applique pas rétroactivement à une session déjà en cours.

La partie modèle du même fichier est sans particularité, et la documentation de référence d’OpenAI décrit directement ces clés — model correspond à « Modèle à utiliser », model_provider a pour valeur par défaut openai :

model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

Une mise en garde à propos de la lecture des versions de la documentation. La référence de configuration Codex indique que model_reasoning_effort accepte minimal, low, medium, high et xhigh, en précisant que xhigh dépend du modèle — tandis que la page de modèle d'API d'OpenAI pour gpt-6-astra documente reasoning.effort comme acceptant low, medium, high, xhigh et max. Le curseur du client et l'API ne décrivent pas le même ensemble, donc définissez effort explicitement et vérifiez ce que votre client a accepté plutôt que de le supposer.

Choisir le modèle — et la règle d’accès qui prend les gens au dépourvu

La documentation du modèle Codex d’OpenAI donne directement la forme CLI : codex -m gpt-6-astra. Dans une session interactive, /model change le modèle et ajuste l’effort de raisonnement ; lors d’une exécution ponctuelle, codex exec -m gpt-6-astra "Review the current changes" fonctionne de la même manière. Dans l’application de bureau et l’extension IDE, le sélecteur de modèle se trouve sous la zone de saisie.

C’est sur la règle d’accès que les gens se trompent, et il vaut la peine de la lire deux fois, car les deux fonctionnalités ont des conditions d’accès différentes :

• Le modèle — disponible sur ChatGPT Work, Co​dex et l'API, et également servi sur Microsoft Azure et AWS Bedrock. La page de lancement d'Ope​nAI indique qu'Astra « est en cours de déploiement aujourd'hui auprès d'un ensemble limité d'organisations et, au cours des prochains jours, deviendra disponible pour tous les utilisateurs de ChatGPT Plus, Pro, Business et Enterprise ».

• La gestion expérimentale du contexte — plus limitée. La documentation d’Ope​nAI indique qu’elle « nécessite une connexion à ChatGPT sur Plus, Pro ou Pro Lite » et qu’elle « n’est pas disponible avec une connexion Business, Enterprise ou par clé API au lancement ».

C’est la deuxième ligne qu’il faut assimiler. Vous pouvez appeler gpt-6-astra avec une clé API, et vous pouvez le payer via un forfait Business — mais la fonctionnalité de notes inter-fenêtres ne sera pas là. Si le mécanisme de notes est la raison pour laquelle vous changez, il vous faut une connexion ChatGPT Plus, Pro ou Pro Lite dans le client Co​dex, pas une clé API. Ope​nAI le présente comme une disponibilité dépendant du « déploiement, de votre méthode de connexion et de votre client », ce qui est la version polie de la même chose.

Deux autres réserves, présentées comme rapportées plutôt que documentées par le fournisseur. La couverture du déploiement indique que la version 0.153.0 ou ultérieure de Codex CLI est requise pour Astra ; nous n'avons pas pu confirmer ce seuil de version sur les pages d'OpenAI elles-mêmes. Et la documentation de Codex décrit des préréglages du sélecteur de modèles — Astra Light, Astra Medium, Astra Extra High — proposés aux comptes Pro, Business (100 $) et Enterprise éligibles, aux côtés du curseur de raisonnement. Il s'agit de positions dans le sélecteur, et non de produits distincts : OpenAI documente un seul identifiant de modèle, gpt-6-astra, avec un seul ensemble de caractéristiques et un seul prix, et ne publie aucune spécification ni aucun tarif distinct pour une quelconque configuration « Astra Pro » ou « Astra Medium ». Considérez comme non vérifié tout chiffre avancé pour un palier Astra nommé.

Si vous voulez essayer le modèle avant de lui confier un chemin de production, le faire transiter par un seul point d'accès aux côtés de votre modèle actuel est la façon la moins coûteuse de le savoir — GPT-6 Astra figure dans le catalogue OrcaRouter, donc une exécution comparative ne vous coûte qu'une chaîne de modèle plutôt qu'un second contrat et un second SDK.

Effort de raisonnement : cinq niveaux, et ce que chacun coûte

La documentation de l'API d'OpenAI pour gpt-6-astra répertorie cinq niveaux d'effort — low, medium, high, xhigh et max — et les consignes de Codex sont sans détour quant à leur utilisation : « Utilisez l'effort de raisonnement le plus faible qui produise le résultat dont vous avez besoin », et commencez par la valeur par défaut, en l'augmentant lorsqu'une tâche nécessite une planification plus approfondie.

La raison pour laquelle il est coûteux d’ignorer ce conseil sur ce modèle en particulier tient à l’endroit où les jetons de raisonnement se retrouvent sur la facture. Les jetons de raisonnement sont des jetons de sortie, et la sortie sur Astra coûte $50.00 par million — dix fois le tarif des entrées et cinquante fois le tarif des entrées mises en cache. L’arbitrage n’a donc rien d’abstrait :

• Chaque tranche supplémentaire de 1 000 tokens de raisonnement par tour coûte 0,05 $ au tarif de sortie.

• Sur une session de 150 tours, conserver 1 000 jetons de raisonnement supplémentaires par tour coûte environ 7,50 $ ; en conserver 5 000 supplémentaires coûte environ 37,50 $.

• Dans la session détaillée ci-dessous, la sortie est déjà la plus grande ligne unique à 0,200 $ par tour, contre 0,090 $ de lectures de cache — la croissance du raisonnement est le terme qui fait évoluer le total le plus rapidement.

Ce qu'Ope​nAI ne publie pas, c'est un tableau par niveau d'effort : il n'existe aucun chiffre du fournisseur pour le nombre de tokens de raisonnement que xhigh ou max émet sur une tâche de codage par rapport à medium, et aucun benchmark du fournisseur ventilé par niveau d'effort. Quiconque vous cite un ratio précis « max coûte 2x » cite sa propre mesure, pas celle d'Ope​nAI. La méthode honnête consiste à exécuter une tâche représentative à deux niveaux d'effort et à lire le bloc d'utilisation dans la réponse — ce nombre, multiplié par 50 $ par million, correspond à votre véritable surcoût d'effort.

Les résultats mesurés, chacun avec sa propre source

Travaux de codage et de terminal, tous rapportés par le fournisseur Ope​nAI sauf indication contraire. Terminal-Bench 4.0 : GPT-6 Astra à 57,9 %, contre 37,3 % pour GPT-5.6 Sol et 55,8 % pour Claude Fable 5.1 — Ope​nAI estimant un coût d'API par tâche inférieur d'environ 9 % par rapport à GPT-5.6 Sol et inférieur de 63 % par rapport à Claude Fable 5.1. DeepSWE v1.1 de Datacurve place Astra à 74,1 % sur le benchmark propre à Datacurve, un chiffre que Datacurve décrit comme un nouveau record et que certains articles arrondissent à 74 %. Sur l'ensemble agentique plus large, Ope​nAI rapporte OSWorld 2.0 à 72,6 % à environ 40 minutes par tâche — environ 47 % de temps en moins par tâche que GPT-5.6 Sol — aux côtés de FrontierMath Tier 4 à 98 %, ARC-AGI-3 à 99,9 % et ExploitBench à 100 %, tous décrits par Ope​nAI comme des niveaux saturés ou effectivement saturés. Ce sont les chiffres du fournisseur ; nous ne les avons pas reproduits, et un examen indépendant du chiffre ARC-AGI-3 par ARC Prize a conclu qu'il avait été mesuré dans un environnement spécial d'adaptateur de fournisseur et qu'il chutait dans des conditions standard.

Le chiffre qui ne vient pas d’un fournisseur est celui dont un workflow de revue de code devrait se soucier le plus. CodeRabbit a publié sa propre évaluation d’Astra le 4 septembre 2026, et le résultat est plus limité que ne le laisse entendre le gros titre. Sur les pull requests multi-fichiers — les revues difficiles qui exigent de relier une modification à ses conséquences ailleurs dans la base de code — Astra a détecté environ 20 % de bugs en plus que GPT-5.6 Sol, avec une couverture des bugs actionnables de 57,1 % contre 47,6 %. Sur l’ensemble des revues, le gain s’évapore en grande partie : 61,3 % contre 59,0 %, soit environ 4 % de plus. CodeRabbit qualifie les deux de « résultats préliminaires et indicatifs » qui n’établissent pas de classement, et précise que sa méthode ne permet pas d’isoler la cause de l’amélioration. La page de lancement d’Ope​nAI qualifie le même travail de « plus du double sur les pull requests multi-fichiers » ; le compte rendu de CodeRabbit lui-même donne les 20 % et les pourcentages de couverture ci-dessus. Lisez les pourcentages, pas le résumé.

Cette asymétrie est le chiffre le plus utile de cette page pour décider comment déployer le modèle, et elle va dans le même sens que le prix : le gain est concentré dans le raisonnement inter-fichiers, c’est donc là que vous devez investir le modèle.

Qu'est-ce que l'utilisation de l'ordinateur dans Co​dex change pour votre flux de travail ?

Ope​nAI affirme que le harnais Co​dex mis à jour rend GPT-6 Astra 1,9 fois plus rapide pour terminer les tâches sur Mind2Web que l’expérience actuelle GPT-5.6 Sol. Mind2Web est une automatisation de tâches web, donc comprenez-le ainsi : le travail d’agent qui doit toucher un navigateur ou une interface graphique se termine sensiblement plus rapidement, et c’est ce même harnais mis à jour que vous exécutez lorsque vous pilotez Co​dex, tout simplement. Le chiffre complémentaire est le résultat OSWorld 2.0 ci-dessus — 72,6 % à environ 40 minutes par tâche, soit environ 47 % de temps en moins par tâche que Sol.

Pour un développeur, la conséquence pratique est un changement dans ce qui mérite d’être délégué. Les workflows qui étaient auparavant trop lents à automatiser de bout en bout — piloter une console de staging sans API, reproduire un bug via une interface utilisateur, parcourir un formulaire à plusieurs étapes pour générer une fixture — entrent dans la fourchette où une exécution par un agent est moins coûteuse qu’une exécution à la main. Cela augmente aussi la valeur des contrôles côté entreprise qu’Ope​nAI a livrés en parallèle : ChatGPT Work et Co​dex ajoutent des politiques de confirmation, c’est-à-dire une approbation avant les actions à conséquences, et une revue automatisée des appels d’outils dangereux ou non autorisés. Si vous laissez un agent naviguer par clics dans une interface réelle, cette couche de revue est ce qui sépare une mauvaise exécution d’un mauvais après-midi — et c’est la raison pour laquelle le fait que l’accès entreprise soit désactivé par défaut, avec un administrateur qui l’active selon la grille tarifaire applicable, est une fonctionnalité de gouvernance plutôt qu’un obstacle.

Facturer le workflow, pas le token

Voici le prix, nommé et daté. D'après la page tarifaire d'Ope​nAI, consultée le 2026-09-16, gpt-6-astra standard est facturé 10,00 $ par million de tokens d'entrée, 1,00 $ par million de tokens d'entrée mis en cache, 12,50 $ par million d'écritures de cache et 50,00 $ par million de tokens de sortie. Batch et Flex s'appliquent à la moitié de ces tarifs ; le mode Fast les double. C'est cette ligne d'entrée mise en cache qui détermine votre facture dans une boucle agentique, car un agent de codage retransmet un contexte volumineux, en grande partie inchangé, à chaque tour, et l'entrée mise en cache coûte un dixième de l'entrée fraîche.

Deux seuils importent avant le calcul. La documentation du modèle d'Ope​nAI indique que les prompts dépassant 272 000 jetons d'entrée sont facturés à 2x les tarifs d'entrée et de cache et à 1,5x la sortie pour la requête complète — pas seulement l'excédent — et la page de tarification comporte la ligne de contexte long à 20,00 $ en entrée, 2,00 $ en entrée mise en cache et 75,00 $ en sortie. Et chaque jeton de raisonnement est facturé au tarif de sortie, comme indiqué ci-dessus.

Prenons un refactoring nocturne réaliste : 150 tours de modèle, une moyenne de 100 000 jetons d’entrée par tour, dont 90 000 lus depuis le cache et 10 000 nouveaux, et 4 000 jetons de sortie par tour, raisonnement inclus. Sous le seuil de 272K, aux tarifs standards :

• Entrée mise en cache — 90 000 jetons × 1,00 $ par million = 0,090 $ par tour

• Entrée fraîche — 10 000 jetons × 10,00 $ par million = 0,100 $ par tour

• Sortie — 4 000 tokens × 50,00 $ par million = 0,200 $ par tour

• Total — 0,390 $ par tour, donc 150 tours représentent environ 58,50 $ pour la session

Maintenant, faites passer la même session au-dessus du seuil. À 300 000 tokens d'entrée par tour — 270 000 mis en cache, 30 000 nouveaux — toute la requête est re-tarifée, donc l'entrée mise en cache double pour atteindre 2,00 $, l'entrée nouvelle double pour atteindre 20,00 $ et la sortie passe à 75,00 $ :

• Entrée mise en cache — 270 000 × 2,00 $ par million = 0,540 $ par tour

• Entrée fraîche — 30 000 × 20,00 $ par million = 0,600 $ par tour

• Sortie — 4 000 × 75,00 $ par million = 0,300 $ par tour

• Total — 1,44 $ par tour, soit environ 216,00 $ pour 150 tours

Même forme de tâche, une facture environ 3,7 fois plus élevée, et toute la différence tient au côté des 272 000 tokens où se situe votre transcription. Voilà l’argument en faveur du mécanisme de notes résumé en une phrase : si des notes durables et un historique consultable vous permettent de garder un contexte de travail plus concis au lieu de traîner toute la transcription, la fonctionnalité s’amortit en tokens d’entrée avant même d’apporter quoi que ce soit à la qualité. C’est aussi l’argument pour ne pas laisser une exécution sans surveillance faire grossir une transcription sans plafond.

Pour donner un ordre de grandeur, la même session de 150 tours avec le même profil de tokens sur les paliers moins chers : GPT-5.6 Terra, à ses tarifs publiés de 2,00 $ en entrée / 0,20 $ en cache / 12,00 $ en sortie, revient à environ 12,90 $, et GPT-5.6 Luna, à 0,20 $ / 0,02 $ / 1,20 $, revient à environ 1,29 $. Ce ne sont que des calculs basés sur les tarifs publiés d'Ope​nAI, et non une affirmation qu'ils termineraient la même tâche — ce qui est tout l'objet des deux sections suivantes.

Si vous comparez tout cela entre fournisseurs, il est bon de savoir qu’OrcaRouter répercute le prix catalogue du fournisseur sans marge, de sorte qu’une modification de prix d’un fournisseur est prise en compte en direct sur le point de terminaison routé le jour même, plutôt qu’à la prochaine facture.

Les modes de défaillance à anticiper lors de la conception

Astra est un modèle à long horizon reposant sur une conception à long contexte, et ce sont les deux moitiés de cette description qui abritent les problèmes. Il s’agit de constats de la communauté et de retours post-mortem de fournisseurs, pas de nos propres mesures.

• L'expérience de gestion du contexte a connu un bug cette semaine. Le post-mortem d'Ope​nAI du 2026-09-12 confirme que l'expérience opt-in « a causé des arrêts prématurés et des réponses à des messages obsolètes », touchant environ 4 000 à 5 000 utilisateurs, et qu'elle a été désactivée. Ce même post-mortem cite deux autres causes des plaintes concernant la qualité durant la semaine de lancement : des compétences écrites pour des modèles antérieurs qui se déclenchaient à contretemps et empêchaient Astra de vérifier son propre travail, et des moteurs de service mal configurés qui dégradaient une queue de trafic. Une réinitialisation de l'utilisation a suivi à minuit, dans la nuit du 09-12 au 09-13.

• La surréflexion et la prolifération des tests. Un fil r/codex largement partagé décrit Astra répondant à une petite demande de fonctionnalité en construisant d'abord des couches de vérification, des tests de fumée et des contrôles de hachage, en les exécutant dans plusieurs ordres, et en signalant que le compteur d'utilisation était proche de l'épuisement bien avant que la fonctionnalité n'existe. Les rapports sont des témoignages individuels plutôt que des mesures contrôlées, et des plaintes similaires ont circulé au sujet d'autres modèles de pointe le mois précédent — alors traitez cela comme un schéma réel à circonscrire, et non comme un taux sur lequel vous pouvez compter.

• Les exécutions qui ne se terminent pas. Armin Ronacher, le créateur de Flask, a décrit avoir laissé Astra tourner sans supervision pendant 35 heures, au terme desquelles elle avait produit environ 75 000 lignes nettes réparties sur 79 commits, environ 1 400 messages d’agent à agent et près de 1 200 $ de frais d’API — soit environ 15,50 $ par commit — sans, selon son évaluation, qu’aucune valeur n’ait été livrée. Les rapports sur le nombre de tokens varient, alors prenez ce chiffre avec des pincettes. Il a présenté l’absence de condition d’arrêt comme étant autant un problème de harnais qu’un problème de modèle, ce qui constitue la lecture exploitable : définissez la complétion avant de commencer.

• Le problème inverse existe aussi. Des rapports de la communauté décrivent Astra qui s’arrête avant d’avoir terminé une tâche et attend une invite pour continuer, ce qui est la même cause profonde vue de l’autre côté — une notion de « terminé » sous-spécifiée. Définir explicitement « terminé » est la ligne à la plus forte valeur dans votre prompt de tâche.

• Les sessions longues peuvent devenir irrécupérables. Des tickets ouverts sur Co​dex signalent un cercle vicieux : la fenêtre de contexte se remplit, la compaction automatique se déclenche, la tâche de compaction elle-même manque de contexte, et le fil ne peut plus être récupéré — et, séparément, que les routes natives de notes et d’historique renvoient 404 sur Pro avec Astra dans certaines configurations, tandis que la permutation des fenêtres peut supprimer l’état de la tâche. Il s’agit dans les deux cas de rapports ouverts plutôt que de déclarations d’un fournisseur, mais ils plaident pour conserver les exécutions avec des points de contrôle dans git plutôt que de compter sur la survie de la session.

• Les notes obsolètes sont une propriété de conception, pas un bug. Rien ne garantit qu’une note reflète l’état actuel du fichier qu’elle décrit, et la recherche repose sur une correspondance littérale de sous-chaînes plutôt que sur une recherche sémantique. Stockez le chemin source avec la note, revérifiez à chaque modification et traitez les notes d’une exécution non surveillée comme des éléments de preuve à vérifier plutôt que comme une vérité sur laquelle s’appuyer.

• La plainte actuelle porte sur les plafonds d’utilisation. Les signalements de la semaine du 2026-09-14 font état de plafonds jusqu’à quatre fois plus stricts que lors de la semaine du lancement, ainsi que d’une plainte non résolue selon laquelle l’effort xhigh consomme moins d’allocation que medium — ce qui, si cela se vérifie, signifie que l’effort et le quota n’évoluent pas ensemble. Ope​nAI n’a pas publié de plafonds numériques par formule pour Astra.

Quand un modèle moins cher est le bon choix

Les résultats mesurés ci-dessus prennent la décision de routage à votre place. L’avantage d’Astra se concentre sur les travaux qui s’étendent sur plusieurs fichiers ou sur des heures : la revue inter-fichiers, les tâches agentiques à long horizon, les flux d’utilisation de l’ordinateur. Pour les modifications ordinaires d’un seul fichier, les refactorisations mécaniques, l’échafaudage de tests et le formatage, le delta global de revue d’environ 4 % par rapport à GPT-5.6 Sol ne justifie pas un prix par token environ 2,5 fois supérieur au prix actuel — et la conclusion de CodeRabbit elle-même va dans le même sens, recommandant un routage intelligent des tâches plutôt qu’un remplacement généralisé. Réservez le modèle coûteux aux tâches où son avantage se manifeste, et acheminez le reste vers le bas.

Concrètement, une répartition qui fonctionne : GPT-6 Astra pour les modifications multi-fichiers, les bases de code inconnues, les exécutions d’agents de plusieurs heures et tout ce qui touche à un navigateur ; GPT-5.6 Terra pour les modifications ciblées, le code passe-partout et la génération de tests ; GPT-5.6 Luna pour la classification, l’extraction et les traitements mécaniques à grande échelle. D’après l’arithmétique de session ci-dessus, la différence entre tout exécuter sur Astra et n’en exécuter qu’un tiers sur Astra est la différence entre environ 58,50 $ et environ 28 $ pour les mêmes 150 tours.

Réussir cette répartition, c'est exactement le rôle d'une couche de routage. OrcaRouter place 200+ modèles derrière une seule API, donc la répartition ci-dessus est un changement de configuration plutôt que trois intégrations — et le basculement automatique signifie qu'une fonctionnalité expérimentale qui passe une mauvaise semaine, comme celle-ci l'a fait, dégrade votre exécution au lieu d'y mettre fin. Pour un modèle dont le mécanisme de contexte est encore qualifié d'expérimental par Ope​nAI lui-même et a été brièvement désactivé, avoir un second chemin configuré n'est pas de la paranoïa ; c'est la juste dose de prudence.

Ce qu'il faut surveiller à partir d'ici

Quatre choses changeraient cette page, et toutes les quatre sont en suspens. Que l’expérience de gestion du contexte soit réactivée, et sous quelle forme — Ope​nAI dit qu’elle deviendra la valeur par défaut pour Astra, ce qui signifie que la ligne de configuration ci-dessus finira par ne plus être un paramètre que vous définissez. Que les signalements de 404 pour les notes et l’historique sur Pro soient clos, car c’est la différence entre un mécanisme qui fonctionne comme documenté et un mécanisme qui fonctionne sur certaines routes. Que Ope​nAI publie des données de jetons ou de coûts par effort, ce qui est le chiffre manquant dans chaque décision d’effort aujourd’hui. Et que les plafonds d’utilisation qui se sont resserrés pendant la semaine de lancement s’assouplissent une fois que la demande qui a mis en pause les nouveaux abonnements Pro à 200 $ le 10 septembre 2026 est absorbée.

D'ici là, la marche à suivre est courte. Épinglez le modèle avec codex -m gpt-6-astra, activez l'expérience uniquement si vous avez une connexion Plus, Pro ou Pro Lite dans le client, définissez l'effort explicitement plutôt que de vous fier à un libellé de curseur, gardez votre contexte de travail sous 272 000 tokens, car c'est là que la facture double, définissez ce qu'est « terminé » avant de partir, et acheminez le travail facile vers un endroit moins cher. Le modèle date du 2026-09-03 et il n'est pas près de disparaître ; c'est l'outillage autour de lui qui est encore en train de se stabiliser.

Les questions qui se posent

La fonctionnalité de notes inter-fenêtres vaut-elle la peine d'être activée pour des tâches de taille ordinaire ? En général, non. Elle existe pour résoudre les pertes aux frontières des fenêtres de contexte ; dès lors, sur une tâche qui tient dans une seule fenêtre, elle ajoute des pièces mobiles — y compris un chemin de code expérimental qui a été désactivé en raison d'un bug le 2026-09-12 — sans éliminer la moindre difficulté. Activez-la pour le travail à long horizon et laissez-la désactivée pour une modification bien délimitée.

La fenêtre de 1 050 000 tokens peut-elle remplacer la récupération dans ma configuration ? Pas pour des raisons de coût. La relecture d’un grand contexte à chaque tour est facturée à chaque tour, et au-delà de 272 000 tokens d’entrée, la requête entière est refacturée à 20,00 $ en entrée et 75,00 $ en sortie. Une étape de récupération qui maintient le contexte de travail plus petit est généralement la conception la moins coûteuse, ce qui explique pourquoi le mécanisme de notes est intéressant : c’est de la récupération intégrée au harnais.

Que se passe-t-il avec les notes lorsqu'une tâche se termine ? La documentation d'Ope​nAI circonscrit le mécanisme à la même tâche, et les publications de la communauté décrivent les notes comme étant stockées au niveau de cette tâche plutôt que reportées automatiquement. Ne partez pas du principe qu'une nouvelle tâche hérite des notes de la précédente ; tout ce qui doit perdurer a sa place dans votre dépôt, et non dans la mémoire de l'agent.