OpenAI réduit la taille du contexte du modèle Codex de 372k à 272k

• OpenAI a mis à jour les métadonnées de modèle embarquées de Codex et a rétroporté dans la branche release/0.144 une modification réduisant la taille du contexte du modèle de 372k à 272k
• La PR #33972 transfère les changements de la branche agent/hotfix-0.144-model-metadata vers la release Codex 0.144
• Le périmètre du changement concerne un seul fichier JSON, avec des statistiques de diff de 64 lignes ajoutées et 54 supprimées
• La PR a été fusionnée après 1 commit et 36 vérifications, sans discussion ni contenu de revue distinct
• Sur la page fournie, le diff du fichier ne se charge pas ; il est donc impossible de confirmer les changements précis de métadonnées autres que la réduction du contexte

---

Objectif et périmètre du changement

• Le titre de la PR indique un rétroportage des métadonnées de modèle embarquées actualisées vers Codex 0.144
• Selon le titre Hacker News, la taille du contexte du modèle a été réduite de 372k à 272k
• La branche cible est openai:release/0.144, et la branche source sayan-oai:agent/hotfix-0.144-model-metadata

Résultat de la fusion

• La PR #33972 se compose d’un seul commit, b06f4fa
• Le titre du commit est Backport refreshed bundled model metadata
• Elle a été fusionnée le 18 juillet 2026, avec 36 vérifications et un fichier modifié indiqués
• Le volume de changement est de 64 lignes ajoutées et 54 supprimées, et le format du fichier est JSON

Limites vérifiables

• Les zones de fichiers et de commentaires de la page affichent une erreur de chargement ; le diff JSON réel n’est donc pas consultable dans le contenu fourni
• Les étapes de reproduction, la raison du changement, l’impact sur la compatibilité et les retours de revue ne figurent pas dans le texte

[GN⁺]

Avis sur Hacker News

• On dit souvent que la compression règle le problème, mais dans mon travail, il y a beaucoup trop de détails qui disparaissent avec la compression
  Ça peut aller si le plan est simple ou qu’on n’a pas de discussions très détaillées, mais le manque de long contexte fait qu’au final je continue d’utiliser Anthropic
  Quand il faut garder en mémoire plusieurs articles ou de gros documents complexes dans leur intégralité, le contexte reste toujours bloqué à 16 %. Après environ 5 minutes de conversation, ça compresse, puis il faut relire les documents pour revenir à 16 %, et le cycle se répète
  Le contexte de 372k n’était pas parfait non plus, mais il augmentait la marge de 12~20 % à environ 40 %, ce qui aidait beaucoup

  • Comme on ne peut pas désactiver la compression automatique et qu’on ne peut pas non plus revenir à l’historique avant compression, Codex est inutilisable sur une base de code de plus de 5 000 lignes
    Elle se déclenche de façon aléatoire quand il reste 10 à 20 % de contexte, donc on ne peut utiliser en pratique que 80 % des 272k. Après la compression, les hallucinations deviennent si fortes que c’est pire que de repartir de zéro, et on tombe dans une boucle où l’on relit la base de code avant d’être recompressé
  • Mon processus de conception est différent. Le plan.md modifié à plusieurs reprises sert de mémoire, et redémarrer la session pour relire et revoir le plan aide à obtenir un regard neuf
  • La compression est tellement mauvaise que j’ai créé un outil qui permet au LLM de supprimer sélectivement certaines parties du contexte puis de les restaurer au besoin. Si vous atteignez souvent les limites de la compression automatique, context bonsai vaut le détour
    https://github.com/Vibecodelicious/context-bonsai-agents
  • Les modèles d’Anthropic offrent un contexte d’un million de tokens. Je comptais passer chez OpenAI le mois prochain, mais s’ils sont encore autour de 300k, il va falloir s’adapter à cette nouvelle réalité
  • En général, je recommande à l’agent de créer ou mettre à jour de temps en temps des fichiers .md pour mémoriser les nouvelles informations importantes. Mais si l’agent sait vraiment identifier ce qui est important, alors /compact devrait aussi bien fonctionner

• À cause de la grande fenêtre de contexte, on ne trie plus ce qu’on y met, et la compression applique une compression avec perte à l’ensemble d’un coup, ce qui fait perdre même les détails nécessaires
  Je pense que le vrai problème de fond, c’est de renvoyer toute la conversation à chaque fois. Avec le plugin mémoire/contexte que j’ai créé, je vide le contexte à chaque tour puis je réinjecte seulement les informations pertinentes ; ainsi, au lieu de lire un historique de 200 000 tokens, le modèle ne lit qu’un état sélectionné de quelques milliers de tokens, et un petit contexte ne posait plus problème
  Je n’ai pas encore résolu ça pour les agents de code, mais la vraie solution est une politique de rétention qui garde seulement ce qui est nécessaire pour terminer la tâche ou pour la suivante, et j’estime qu’on peut l’implémenter avec un LLM dédié

  • Beaucoup de spécialistes du NLP ayant travaillé sur les LSTM, les GRU, etc., considéraient eux aussi que le renvoi intégral de la conversation était un problème fondamental, mais empiriquement, les Transformer l’ont emporté
    Ce sera intéressant de voir si les futures architectures de modèles reviendront sur ce problème. Si on prend l’humain comme référence, ce qui manque encore, c’est la capacité à transférer efficacement l’information de la mémoire à court terme vers la mémoire à long terme ; le fine-tuning fait en principe quelque chose de proche, mais de manière inefficace

• Je ne sais pas si c’est la raison de ce changement, mais dès le départ je pense qu’utiliser un contexte plus grand que cela est généralement une erreur
  On sous-estime à quel point les performances du modèle baissent et à quel point le coût en tokens augmente quand le contexte grossit. Claude n’utilise pas plus de 300k et, au lieu de compresser, découpe le travail en tâches séparées tout en gardant une documentation et une base de code modulaire concises
  Pour des tâches ponctuelles, un grand contexte peut être utile, mais si vous dépassez en permanence les 300k, il est très probable que vous perdiez beaucoup de choses ou que la conception de votre base de code ne soit pas bonne

  • Moi aussi, je compresse ou redémarre à 250k. Comme la taille de contexte nécessaire est proportionnelle à l’ampleur du projet, ceux qui ont besoin d’une fenêtre plus grande semblent simplement travailler sur de plus gros projets
  • J’ai la même impression, et je mettrais même plutôt la limite à 100~150k. Même si le modèle prend en charge un long contexte, les performances réelles ne sont pas bonnes
  • Je ne partage pas l’impression que le modèle devient nettement plus bête quand le contexte augmente. Il devient plus lent et plus cher, certes, mais pour des tâches complexes c’est un coût à accepter
    L’agent principal fait rechercher les éléments nécessaires par des sous-agents et rédige un plan, puis d’autres sous-agents le passent en revue de manière antagoniste pour l’améliorer. À la fin, 30 à 40 % d’une fenêtre d’un million de tokens sont remplis, ce qui est impossible avec 272k
    Sur 5.6 Sol, il a fallu réduire fortement ce processus, et c’est probablement pour cela que le résultat était moins bon

• Quand ce changement a eu lieu, Tibo a publié une explication en même temps : https://x.com/thsottiaux/status/2076543065045795309

  • Les réponses sont visibles ici : https://xcancel.com/thsottiaux/status/2076543065045795309
    Le tweet lié est une réponse non officielle aux informations officielles de Tibo, et Tibo corrige le contenu dans les réponses
  • Je ne comprends pas ce graphique. Pourquoi la ligne continue-t-elle de monter alors qu’il y a compression, ou bien y a-t-il un sens particulier à “overall trajectory size” que je ne connais pas ?
  • Je ne vois pas comment la longueur totale de trajectoire peut être identique alors que l’intensité du raisonnement diffère. Même si on exclut les tokens de raisonnement de la longueur de trajectoire, ça ne me paraît pas possible

• Je n’aime pas leur compression du contexte, et j’estime qu’ils devraient désormais proposer au moins 1 million de tokens
  GPT 5.5 et 5.6 deviennent poussifs à chaque compression avant de retrouver leur rythme, et se focalisent parfois excessivement sur d’anciens messages d’instruction restés dans le contexte compressé

  • GPT-5.6-Sol est environ 2 fois plus efficace en tokens qu’Opus/Fable, donc un maximum de 258k correspond à environ 516k chez Claude
    La corruption du contexte reste un problème[1][2], et il existe aussi des indices montrant que, pour les tâches agentiques, la compression est équivalente ou supérieure à un long contexte[3]. Le mieux serait que le modèle raisonne sur un contexte d’un million comme il le fait sur 256k, mais ce n’est pas encore possible
    [1] https://arxiv.org/abs/2605.12366
    [2] Comparaison des F1 GraphWalks 256K et 1M dans la System Card d’Opus 4.8 : https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
    [3] https://context-folding.github.io/
  • Contrairement aux autres outils de code, il est frustrant de ne pas pouvoir désactiver la compression automatique. Elle se déclenche de façon irrégulière quand il reste 10 à 20 % du contexte, donc la capacité réellement garantie n’est que de 80 % des 272k
    Sur une grosse base de code, alors que le travail est presque terminé et qu’il ne reste qu’une réponse d’environ 2 000 tokens, si on passe sous les 20 %, après un long traitement apparaît Context compacted. Impossible de revenir avant la compression, il faut réexaminer la base de code, puis ça recompresse, et on finit par épuiser tous les tokens
  • J’espère que cette réduction de tokens n’est pas une manœuvre détournée pour augmenter l’usage, mais surtout une mesure de réduction des coûts. Dans mon entreprise aussi, les responsables des coûts ont tellement limité le contexte qu’ils ont rendu presque inutilisable un LLM interne qui était pourtant correct au départ
    On dirait qu’il existe une sorte de réunion où les dirigeants se partagent les pires pratiques
  • La mémoire de travail peut être stockée dans des fichiers Markdown, il n’y a donc pas besoin d’un grand contexte. Quand le contexte augmente, l’attention se disperse et les performances du LLM baissent, donc le garder petit favorise la qualité

• J’utilise Opus au quotidien et je lance souvent /clear. Même avec un contexte d’un million, les performances chutent rapidement quand on approche des 50 %, donc j’obtiens généralement de bien meilleurs résultats en réinitialisant vers 30 à 40 %
  Mieux vaut repartir de zéro et réinjecter d’emblée le contexte nécessaire plutôt que compresser. Il est efficace d’organiser des documents Markdown par fonctionnalité en plusieurs recueils techniques, puis d’indiquer dès le chargement initial où trouver les informations liées à la tâche

• Avec Codex, je n’ai jamais eu l’impression que la taille du contexte posait problème. Je ne sais pas comment la compression fonctionne, mais ça continue comme s’il n’y avait pas de limite

  • On dirait que tu as commencé à utiliser Codex récemment. Au début, il y avait de graves erreurs model context size exceeded qu’aucune compression ne permettait de rattraper, et elles n’ont disparu qu’il y a quelques mois
    C’est bien mieux maintenant, mais après compression, on ne voit pas ce qui a été mis dans le concise summary, donc il est difficile de savoir si les éléments importants ont été conservés
    Codex semble aller dans le sens d’un maximum de choses cachées à l’utilisateur, et comme ils ont récemment chiffré les prompts entre l’agent et les sous-agents, ils pourraient aussi chiffrer l’ensemble des logs de session. C’est regrettable, mais parmi tout ce que j’ai utilisé jusqu’ici, cela reste la meilleure combinaison outil/modèle
  • Codex oublie souvent de terminer la dernière tâche lorsqu’une compression se produit, surtout quand on envoie un message juste avant la compression
  • La plupart des problèmes se prêtent au diviser-pour-régner, donc la différence entre 300k et 400k pose rarement problème. Un agent de code n’est pas une conversation infinie

• Même avec une excellente compression, sur de gros projets il faut lire beaucoup de fichiers. Les 200 000 premiers tokens se consomment très vite, puis le rythme ralentit
  Les sessions Fable dépassent rarement 500 000 tokens, donc il n’y a pas besoin de compression, alors qu’avec Codex il faut continuer à compresser au cours d’une même session

  • À mon avis, s’il faut lire autant de fichiers, c’est parce que agents.md est insuffisant. Il suffit de lire les vrais fichiers de travail et quelques fichiers liés, le reste devrait être organisé dans la documentation

• Pour mon travail, c’est une taille assez petite. J’essaie de rester sous les 200k, mais si je pousse les dernières itérations dans des sessions DeepSeek et MiMo, ça monte parfois jusqu’à 350k tokens avant de compresser
  Je me demande si OpenAI ne pourrait pas adopter la technologie de cache K/V de DeepSeek décrite dans ses publications pour réduire fortement les coûts

  • Personne ne gère le cache aussi bien que DeepSeek, donc les écarts d’implémentation semblent trop importants pour qu’il soit facile de les imiter
    Avec DeepSeek et Reasonix, l’usage suit une méthode dédiée supplémentaire adaptée à la structure du cache, si bien que 97 à 98 % des tokens sont mis en cache dans les longues sessions. Un modèle déjà peu coûteux devient encore moins cher
  • Sur des modèles open source locaux basés sur llamacpp, l’agent ordonne une compression entre 55k et 85k, et à moins d’avoir absolument besoin d’un grand contexte, comme pour le suivi de logs complexes, il est rare d’aller jusqu’à 120k
    J’ai aussi ajusté le prompt système pour que l’agent crée des sous-agents en fonction du budget d’inférence et des messages de llamacpp, puis compresse le contenu. J’utilise l’élagage dynamique du contexte d’opencode pour conserver la direction sans gonfler le volume, et cela fonctionne généralement bien pour développer de manière itérative plusieurs sous-composants

• Ces deux derniers mois, c’était bien mieux pour mon usage, donc je suis passé de Claude à OpenAI. Je me demande si cette modification fera sentir une différence dans la qualité de sortie