Codex sur GPT-6.1 Sol ramène la fenêtre à 828 400 tokens, mais accepte une entrée de 888 000 tokens

Dans ~/.codex/config.toml, on trouve model_context_window = 1000000, mais dans chaque tâche, Codex sur GPT-6.1 Sol annonce une fenêtre de 828 400 tokens. L'auteur d'une analyse publiée sur Habr a cherché l'origine de ce chiffre, l'a relevé à 900 000 avec son propre catalogue de modèles, puis a soumis une entrée synthétique de 890 547 tokens contenant des marqueurs de contrôle. Sa principale conclusion vient du test de contrôle : le même texte, à 888 330 tokens, est passé aussi avec la fenêtre standard de 828 400. Dans Codex, la fenêtre ne limite donc pas la taille d'un message entrant unique.

D'où vient 828 400

Codex récupère les paramètres du modèle auprès du serveur et les met en cache dans ~/.codex/models_cache.json. L'entrée de GPT-6.1 Sol contient context_window 500 000 (valeur par défaut), max_context_window 872 000 (la config ne peut pas relever la fenêtre au-delà) et effective_context_window_percent 95. Résultat : 872 000 × 0.95 = 828 400.

L'auteur ne s'est pas appuyé sur une seule session. Dans les journaux ~/.codex/sessions, il a pris les 40 dernières tâches : 39 sur gpt-6.1-sol et une sur le service codex-auto-review. Dans les 39 événements token_count, on trouve model_context_window: 828400. La valeur se trouve dans le champ info.model_context_window, tandis que l'entrée et la sortie réelles de la dernière requête figurent dans last_token_usage. Le format du journal n'est pas documenté comme stable : après une mise à jour du client, le champ peut donc changer d'emplacement.

Un test à 890 000 tokens avec marqueurs

Avec le paramètre model_catalog_json, l'auteur a branché une copie du catalogue serveur où gpt-6.1-sol a un max_context_window de 1 000 000 et un pourcentage de 90. Cela donne 900 000. Il a retenu une marge de 10 % à partir de sondages réalisés en septembre sur GPT-6 Astra : l'entrée la plus grande acceptée était alors de 900 089 tokens, tandis qu'un texte de remplissage à partir de 909 000 se terminait par une erreur de dépassement.

Le texte de remplissage doit être dense en tokens : en septembre, un texte de 1 720 376 caractères a été arrêté par le client lui-même, qui n'a pas laissé passer un message de plus de 1 048 576 caractères. Le test utilise donc des caractères chinois aléatoires U+4E00–U+9FA4 avec une graine fixe de 42, soit environ 1,9 token par caractère. Trois marqueurs, R7K2, Q9M4 et W3T8, sont insérés à trois endroits du texte, et le modèle doit les restituer dans l'ordre.

• Un simple « ОК », catalogue personnalisé, fenêtre de 900 000 : entrée de 57 187 tokens. Il s'agit de la partie système de l'installation de l'auteur : instructions, règles, descriptions des outils et des compétences.
• Calibrage, 30 302 caractères, catalogue personnalisé : 115 300 tokens, 3 marqueurs sur 3.
• Gros test, 434 302 caractères, catalogue personnalisé : 890 547 tokens, 3 marqueurs sur 3, 62 s, cached_input_tokens 9 216.
• Contrôle, même texte, catalogue serveur, fenêtre de 828 400 : 888 330 tokens, 3 marqueurs sur 3, 60 s, pas de cache.
• L'écart entre les deux dernières entrées est de 2 217 tokens. Le texte de remplissage est identique ; la cause se trouve dans la partie système, mais l'auteur ne l'a pas établie précisément.

Ce que la fenêtre détermine réellement

L'aide décrit ce champ comme « Context window tokens available to the active model ». Tibo Sotto, de l'équipe Codex, a expliqué qu'une fenêtre plus large permet à Codex de conserver davantage de code, de sorties d'outils et d'historique avant de compacter les anciens éléments. Autrement dit, ce chiffre détermine le moment de l'auto-compactage. Le seuil dépend d'un paramètre distinct, model_auto_compact_token_limit ; quant à model_auto_compact_token_limit_scope, en mode total il compte tout le contexte actif, et en mode body_after_prefix seulement l'accroissement après le préfixe reporté.

Le vrai plafond figure sur la page de GPT-6.1 Sol dans la documentation de l'API : fenêtre de 1 050 000 tokens, entrée de 922 000 au maximum. Cela concorde avec les erreurs de septembre. Dans l'API, les requêtes de plus de 272 000 tokens en entrée coûtent deux fois plus cher. Selon Sotto (message du 11.10.2026), l'abonnement n'entraîne pas de supplément pour le contexte long sur GPT-6.1 Sol, et la fenêtre par défaut dans Codex est passée de 272 000 à 500 000. L'auteur n'a pas trouvé cette information dans la documentation. Il n'a pas mesuré la consommation de la limite d'abonnement pour une requête de 890 000 tokens.

Catalogue personnalisé : ce qui casse après une mise à jour

model_catalog_json remplace le catalogue serveur par un fichier statique, et l'auteur s'est lui-même fait piéger. En septembre, il a relevé la limite uniquement pour gpt-6-astra ; puis gpt-6.1-sol est devenu le modèle principal, et sa copie a conservé pour lui les anciens 872 000 et 95 %. Le gain jusqu'à 900 000 a disparu en silence, et toutes les tâches de travail ont tourné à 828 400. La copie ne contient pas non plus gpt-6.1-terra, et la fenêtre par défaut de Sol y est de 272 000 au lieu des 500 000 du serveur.

La gestion expérimentale du contexte [features.context_management] est désactivée depuis le 12.09.2026 : Sotto a écrit que l'équipe avait coupé cette expérimentation en opt-in, qui pouvait provoquer des arrêts prématurés ou des réponses à d'anciens messages. Cela a concerné 4–5 mille utilisateurs. Pour GPT-6.1 Sol, GPT-6.1 Terra et GPT-6 Astra, le catalogue indique supports_experimental_context: false ; le drapeau dans la config n'active rien.

Conclusion pratique pour ceux qui travaillent avec Codex. Inutile de viser le million dans la config : la limite qui vous bloque est le max_context_window du serveur. Pour voir la fenêtre réelle, lisez model_context_window dans le journal de la tâche.

Si vous branchez votre propre catalogue, reconstruisez-le à partir d'un models_cache.json récent après chaque mise à jour du client, et vérifiez la fenêtre dans une nouvelle tâche. Dans les 39 tâches de travail de l'auteur, l'entrée la plus grande a atteint 389 543 tokens : 828 000 tokens suffisent donc largement.

Le prochain test portera sur une longue session jusqu'à l'auto-compactage : à quel volume il se déclenche selon la taille de la fenêtre, et combien de marqueurs survivent au compactage.