Fenêtre contexte GPT-6 Astra : pourquoi Codex affiche 258K

La fenêtre contexte de 1 050 000 jetons de GPT-6 Astra est une limite du modèle API, non une promesse que chaque session Codex affichera 1,05M jetons utilisables. Si Codex affiche environ 258K dans votre session et se compacte plus tard, traitez ces chiffres comme un comportement produit au niveau de la session. OpenAI ne publie pas 258K comme spécification Astra officielle et ne divulgue pas la formule d'allocation exacte dans les sources citées ici.^[1]

La réponse utile est de séparer le contrat du modèle, le budget de fonctionnement du produit, la quantité déjà occupée et le seuil de compaction. Ce sont des chiffres différents. Mesurez la session et la version client que vous avez réellement; n'inférez pas une formule d'allocation cachée d'un compteur arrondi.

Réponse rapide

• L'API Astra documente une fenêtre contexte de 1,05M jetons et une sortie maximale de 128K jetons.^[1]
• Un compteur Codex est un budget de fonctionnement du produit, non la limite du modèle API. S'il affiche environ 258K, traitez cela comme une observation de session, non une spécification officielle.
• Les instructions, outils, marge de sortie, état de la conversation et compaction peuvent tous réduire l'ensemble de travail visible; OpenAI ne publie pas un découpage exact.
• Mesurez la capacité API via l'API, et rendez les tâches Codex longues survivantes à la compaction en sauvegardant les exigences, décisions et résultats de test en dehors du chat.

Les trois nombres que les gens mélangent

La phrase « fenêtre contexte » est utilisée librement dans les discussions produit. Avant de déboguer, nommez le chiffre que vous regardez.

Deux autres chiffres importants : le budget restant et le seuil de compaction, où le produit résume ou externalise le travail antérieur avant une défaillance critique.

Le maximum de la page du modèle et le compteur de reste du produit peuvent tous deux être corrects. Ils répondent à des questions différentes :

• Contrat du modèle : la quantité totale de contexte que le modèle API peut supporter selon son contrat documenté.
• Budget de fonctionnement à l'exécution : la quantité que le produit actuel choisit ou peut garder active pour cette session.
• Budget restant : la quantité de ce budget de fonctionnement qui reste après les instructions actuelles, l'historique, le matériel d'outils et la marge de sortie.
• Seuil de compaction : quand le produit commence à préserver la tâche sous une forme plus compacte.

Ne soustrayez pas 128K de 1,05M et ne déclarez pas que le reste est le budget Codex. Si une session affiche 258K, ne divisez pas par un pourcentage de sécurité supposé et ne déclarez pas que le résultat est un plafond caché. Ces calculs peuvent produire des chiffres ordonnés, mais le matériel OpenAI cité ne documente pas cette allocation.

Un modèle budget pratique, non une spécification interne

Pour la planification, il est utile d'utiliser une inégalité conceptuelle :

instructions actives
+ conversation conservée
+ schémas d'outils
+ entrées et sorties d'outils
+ fichiers ou extraits fournis au modèle
+ marge de sortie
<= budget de fonctionnement à l'exécution actuel

C'est un modèle comptable, non une description rétro-conçue de Codex. OpenAI n'a pas publié, dans les sources citées ici, la taille exacte de chaque composant ou la règle derrière un affichage 258K. La valeur de l'équation est que chaque élément de la gauche peut être observé ou contrôlé lors d'un test.

La distinction prévient également une erreur API courante. Une sortie maximale de 128 000 ne signifie pas que l'API laissera toujours beaucoup vide, ni que fixer un plafond de sortie plus petit augmente la fenêtre contexte publiée du modèle. Cela définit simplement une limite pour cette réponse. Inspectez l'utilisation retournée par le point de terminaison au lieu de l'estimer à partir de caractères de document ou d'une barre de progression UI.

Pour l'ID de modèle actuel, les modalités supportées et le comportement spécifique au chemin, utilisez la référence API GPT-6 Astra. La page du modèle affiche le barème tarifaire reAPI actuel. Ces pages décrivent ce chemin; elles ne définissent pas le budget de session de l'application Codex.

Ce que la compaction change dans Astra pour Codex

La compaction existe parce que les tâches longues pilotées par outils finissent par remplir leur contexte de travail actif. Historiquement, OpenAI dit, Codex résumait le travail accumulé, qui pouvait omettre des détails tels que pourquoi un correctif a échoué ou comment un composant s'est comporté. Avec Astra, OpenAI a introduit un mécanisme Codex expérimental qui peut conserver des notes sur les fenêtres contexte. Les fenêtres antérieures restent interrogeables, de sorte que le modèle peut récupérer une exigence ou un résultat de test passé même s'il n'a pas été capturé dans ces notes.^[2]

Cela donne à une session longue trois formes distinctes de mémoire :

1. Contexte actif : matériel immédiatement présent pour le tour actuel.
2. Notes entre fenêtres : faits sélectionnés préservés quand le contexte actif bascule.
3. Fenêtres antérieures interrogeables : messages plus anciens et résultats d'outils qui peuvent être récupérés quand pertinents.

Le contexte actif est la partie qu'on attendrait qu'un indicateur direct « jetons restants » décrive. L'article d'OpenAI n'explique pas comment le compteur Codex traite les notes ou les fenêtres interrogeables. Ces deux formes peuvent aider l'agent à récupérer les informations sans conserver chaque octet actif. L'historique interrogeable n'est pas la même chose que chaque résultat d'outil antérieur occupant le contexte actuel du modèle à la fois.

OpenAI dit que le nouveau mécanisme peut être activé dans la configuration Codex et devrait devenir la valeur par défaut Astra dans les semaines suivant le lancement.^[2] Comme ce statut est sensible au temps, consultez la documentation Codex actuelle et votre version installée plutôt que de copier un extrait de configuration non vérifié. Cet article n'impose intentionnellement pas un remplacement de fenêtre contexte non documenté.

Enquêter sur un affichage 258K sans le traiter comme universel

Un test utile compare les sessions, non les mémoires. Commencez avec une tâche vide et notez les conditions avant d'ajouter du matériel.

Puis exécutez une séquence contrôlée :

1. Ouvrez une nouvelle session, sélectionnez Astra et capturez le libellé du modèle et le budget affiché avant d'attacher des fichiers ou d'exécuter des outils.
2. Donnez-lui une tâche de référentiel bornée et en lecture seule. Enregistrez quels fichiers sont lus et si les commandes produisent une sortie courte ou longue.
3. Demandez le même livrable dans une deuxième nouvelle session, mais filtrez les recherches et limitez les journaux à la source. Comparez la modification du budget affiché.
4. Si la compaction se produit, demandez les critères d'acceptation d'origine, les fichiers modifiés, les approches échouées et le dernier résultat de test. Vérifiez chaque élément par rapport au référentiel plutôt que d'accepter un résumé courant.
5. Répétez après une mise à jour client. Ne comparez pas une ancienne session reprise avec une nouvelle fraîche et n'attribuez pas chaque différence au modèle.

Ce test ne révélera pas les détails d'implémentation privés. Il répondra à la question opérationnelle : quelles entrées consomment le budget que vous voyez, quand ce client se compacte-t-il et quelles informations doivent être écrites quelque part de durable?

Si votre interface affiche 258K, préservez les conditions de test complètes : version client, catalogue à l'exécution, compte, âge de session, outils activés et entrées récentes. Sans ces variables et une spécification officielle OpenAI, le chiffre ne peut pas être promu à une limite Codex générale.

La sortie d'outil peut consommer plus d'espace que la demande elle-même

Une tâche de codage peut commencer avec une invite de deux phrases et devenir toujours grande. Les listes de fichiers récursives, les fichiers verrous générés, les paquets minifiés, les rapports de test verbeux, les vidages de base de données et les diffs répétés peuvent surpasser la demande d'origine. Le modèle n'a peut-être besoin que de cinq lignes d'erreur pertinentes, tandis que l'outil en retourne cinq mille.

Réduisez ce matériel avant qu'il ne pénètre la conversation :

• recherchez un symbole ou une chaîne d'erreur avant d'ouvrir un répertoire entier;
• demandez la plage de ligne pertinente au lieu d'un fichier généré entier;
• montrez un diff ciblé, puis ouvrez le contexte inchangé seulement quand c'est nécessaire;
• exécutez le test d'échec étroit avant la suite complète;
• limitez les traces de pile répétées et conservez le journal complet en tant que fichier;
• résumez un grand résultat de données avec des comptages, puis inspectez les lignes anormales;
• évitez de coller la même sortie de construction en plusieurs tours.

Ce n'est pas seulement un moyen de repousser la compaction. Les résultats d'outil plus petits et plus ciblés facilitent la distinction de l'erreur actuelle des défaillances obsolètes. Ils laissent également plus de place pour les exigences, les décisions et la vérification.

Conservez les artefacts complets en dehors du chat et enregistrez leurs chemins. L'agent peut rouvrir le pertinent quand c'est nécessaire. Un chemin plus une conclusion concise est généralement plus utile qu'une transcription copiée trois fois.

Concevoir une tâche longue de sorte que la compaction soit survivable

Un modèle d'un million de jetons n'est pas un substitut à l'état du projet. Pour une modification de référentiel qui peut s'étendre sur plusieurs fenêtres contexte, conservez un grand livre compact dans l'espace de travail ou le système de tâche :

Objectif :
Contraintes non négociables :
Fichiers intentionnellement modifiés :
Décisions et preuves :
Approche échouée et pourquoi :
Vérifications exécutées et résultat exact :
Travail restant :
Point de retour :

Mettez-le à jour quand une décision change, pas après chaque commande. Le grand livre a deux emplois : il laisse une session compactée récupérer les faits qui importent, et il laisse un humain auditer si le résumé de l'agent correspond au vrai worktree.

Utilisez des critères d'acceptation explicites. « Terminez la refactorisation » est fragile parce qu'une session post-compaction peut réinterpréter « terminer ». « L'analyseur accepte ces trois fixtures, l'ancien point de terminaison reste derrière un interrupteur, et aucun fichier non pertinent ne change » survivrait mieux à la compression.

Pour une migration API, le guide de migration GPT-6 Astra fournit une découverte, un canari et une séquence de retour. Pour les questions d'accès produit, séparez Codex de Chat, Work et API en utilisant la matrice d'accès GPT-6 Astra.

Quand le contrat API 1,05M est le chiffre qui importe

Utilisez un test API quand l'exigence est d'envoyer un contexte volontairement assemblé grand à gpt-6-astra. Confirmez le modèle avec /v1/models, construisez une fixture représentative, définissez une limite de sortie bornée et stockez les champs d'utilisation de la réponse. Commencez bien au-dessous du plafond et augmentez seulement si la tâche en bénéficie vraiment.

Le guide du modèle Astra d'OpenAI énumère la compaction parmi les capacités disponibles via l'API.^[3] C'est un mécanisme API séparé; il ne documente pas le seuil ou la comptabilité utilisés par Codex.

La page du modèle d'OpenAI indique également que les demandes avec plus de 272 000 jetons d'entrée utilisent des tarifs de contexte long plus élevés, appliqués à la demande entière selon la règle de tarification publiée.^[1] Ce seuil de tarification 272K ne prouve pas que Codex doit exposer 272K ou 258K. Les niveaux tarifaires, la capacité du modèle et le budget de travail d'une application sont des politiques indépendantes.

Une expérience API devrait répondre à une question produit, non prouver qu'une charge utile grande peut être acceptée. Une évaluation compacte pourrait comparer :

retention score = faits requis correctement récupérés / faits requis interrogés

accepted cost = coût total réglé / réponses qui passent chaque chèque requis

Placez des faits connus au début, au milieu et à la fin de la fixture. Demandez des réponses qui peuvent être vérifiées exactement. Enregistrez la latence, l'utilisation des jetons et les défaillances. Ne prétendez pas que le modèle « a utilisé la fenêtre entière » simplement parce qu'une demande a retourné avec succès.

Dépannage d'un budget Codex plus petit que prévu

La page du modèle dit 1,05M, mais une nouvelle session Codex dit 258K

Enregistrez la version du client, le libellé du modèle et la valeur affichée. Mettez à jour via le canal officiel, ouvrez une nouvelle session et vérifiez à nouveau. Si la valeur persiste, signalez ces faits à OpenAI. Ne décrivez pas la lecture comme une spécification API et ne forcez pas une valeur de configuration tierce en production.

La compaction commence plus tôt que le total affiché

Vérifiez si l'interface affiche la capacité totale ou la capacité restante. Notez la taille de la sortie d'outil récente et si la session a été reprise. Le déclencheur de compaction peut inclure une marge qu'un simple comptage de texte visible n'capture pas; les sources citées ne fournissent pas sa formule exacte.

La tâche oublie une exigence après compaction

Déplacez les contraintes durables et les contrôles d'acceptation dans le grand livre des tâches. Demandez à l'agent de les renoncer, puis vérifiez la déclaration par rapport au fichier. Les notes entre fenêtres et la recherche d'OpenAI peuvent aider la récupération, mais elles ne suppriment pas le besoin d'une source de vérité vérifiable.^[2]

Le compteur contexte chute rapidement après une commande

Inspectez ce que la commande a retourné. Remplacez les listes larges, les journaux complets ou les fichiers générés volumineux par une sortie filtrée. Conservez l'artefact complet en dehors de la conversation pour qu'il reste disponible sans rester actif.

Une demande API directe échoue au-dessous de 1,05M

Vérifiez l'ID de modèle exact, le point de terminaison, les paramètres d'entrée et de sortie, et l'erreur retournée. Comptez les jetons avec le tokenizer approprié à la demande plutôt que des caractères. Le chiffre contexte est un maximum de modèle, non une garantie que chaque combinaison de charge utile, demande de sortie, compte et chemin sera acceptée.

FAQ

GPT-6 Astra a-t-il vraiment une fenêtre contexte d'un million de jetons?

Oui pour le contrat du modèle API officiel : OpenAI énumère 1 050 000 jetons pour gpt-6-astra, avec une sortie maximale séparée de 128 000 jetons.^[1]

258K est-il la limite Codex officielle pour Astra?

Non. Les sources OpenAI officielles citées ici ne définissent pas une limite Codex 258K. Si votre interface affiche cette valeur, enregistrez-la comme comportement de cette session jusqu'à ce qu'OpenAI documente le budget Codex pertinent.

Puis-je modifier un paramètre Codex pour forcer 1,05M?

Ne vous fiez pas à la configuration copiée à partir de commentaires sans correspondre la documentation officielle pour votre version client. Un nombre déclaré plus grand ne prouve pas que l'exécution l'a accepté, et cela peut changer le comportement d'utilisation et de compaction.

La compaction signifie-t-elle que Codex supprime tout avant?

OpenAI dit qu'Astra peut conserver les notes entre fenêtres et rechercher les fenêtres contexte antérieures dans Codex. C'est différent de garder tout le contenu antérieur actif à la fois. Vérifiez les exigences critiques et les résultats de test après un événement de compaction.^[2]

Les appels d'outils comptent-ils par rapport au contexte de travail?

Les définitions d'outils, les arguments et le matériel retourné font partie de l'information que l'agent doit traiter. La comptabilité Codex exacte n'est pas publiée dans les sources citées, donc mesurez le changement affiché dans une session contrôlée au lieu d'attribuer une surcharge fixe à chaque outil.

L'API est-elle meilleure que Codex pour le travail de contexte long?

Ils résolvent différents problèmes. L'API est la surface appropriée quand votre application assemble et mesure une demande selon le contrat de modèle documenté. Codex fournit un harnais de codage, des outils, la gestion de session et la compaction. Choisissez en fonction du flux de travail, non du plus grand nombre dans l'une ou l'autre interface.

Mesurez la session que vous avez, puis concevoir pour la compaction

Le chiffre 1,05M et un possible affichage de session 258K ne sont pas des spécifications concurrentes. Le premier est la capacité de modèle API documentée d'OpenAI. Le second est une condition à enquêter dans l'exécution Codex actuelle, non une limite Astra publiée. Capturez les conditions à l'exécution et rendez la sortie d'outil et l'état du projet auditable.

Puis un événement de compaction devient une remise planifiée plutôt qu'un mystère. La session peut récupérer son objectif, ses contraintes, ses décisions et sa vérification la plus récente à partir de preuves durables même quand l'ensemble de travail actif change.

Références

1. OpenAI API, « GPT-6 Astra Model », consulté le 7 septembre 2026.
2. OpenAI, « GPT-6 Astra: A new generation of intelligence », publié le 3 septembre 2026; consulté le 7 septembre 2026.
3. OpenAI API, « Model guidance: Using GPT-6 Astra », consulté le 7 septembre 2026.