Trois pull requests déjà fusionnées sur la branche principale du dépôt openai/codex dévoilent la direction prise pour refondre la gestion de la fenêtre de contexte de Codex : lorsqu'une session dépasse la limite de la fenêtre, le système ne génère plus de résumé pour compresser l'historique, il active directement une toute nouvelle fenêtre pour poursuivre le travail. Les fonctionnalités concernées sont toutes cachées derrière le feature flag `Feature::TokenBudget`, pas encore officiellement lancé.
L'approche actuelle repose sur la compression par résumé. Quand la fenêtre approche de sa limite, le système demande au serveur de condenser la conversation précédente en un résumé, puis l'utilise à la place de l'historique d'origine. Cette méthode a deux coûts fixes : générer le résumé lui-même consomme des tokens, et la compression entraîne des pertes — conventions d'interface, noms de chemins, arbitrages tranchés quelques échanges plus tôt peuvent être effacés au passage. Quiconque a fait tourner des tâches longues avec Codex connaît bien ce second type de défaillance : le modèle oublie une règle fixée deux heures plus tôt, et répond quand même avec assurance.
Le modèle peut demander lui-même une page neuve
La première étape est la PR #27488, fusionnée le 11 juin, intitulée « Add new context window tool ». Elle ajoute au modèle l'outil `new_context`, réservé au modèle lui-même, que l'auteur décrit comme une « escape hatch » pour les moments où la fenêtre en cours devient inutilisable.
La requête est enregistrée sur `AutoCompactWindow` puis consommée juste après l'échantillonnage ; la requête suivante dans le même tour atterrit déjà dans la nouvelle fenêtre. Le point de départ de la nouvelle fenêtre est un checkpoint de compression sans résumé, qui ne conserve que le contexte initial — l'historique de conversation précédent n'est pas conservé.
Le nettoyage manuel passe désormais par le même chemin
La deuxième étape est la PR #29743, fusionnée le 23 juin. Elle unifie la compression manuelle et la compression automatique dans un seul cycle de vie, `compact_token_budget` : une fois le token budget activé, la compression ne demande plus de résumé au serveur, elle charge directement en local un tout nouveau contexte initial.
Les détails techniques de cette étape révèlent une certaine retenue : le comportement visible de l'extérieur est préservé, les hooks de compact se déclenchent comme d'habitude, l'événement de cycle de vie `ContextCompaction` continue d'être émis. Autrement dit, les clients qui dépendent de ces événements n'ont rien à changer — c'est l'implémentation sous-jacente qui change.
La partie récupération revient à l'historique et aux notes
Les deux premières étapes ne réglaient que le « jeter » ; c'est la PR #39827, fusionnée le 21 août, qui comble le « récupérer ». La description de cette PR est directe : les sessions en token budget ont besoin d'un moyen de restaurer le contexte de conversation précédent et de préserver l'état de travail d'un changement de fenêtre à l'autre.
Elle ajoute deux groupes d'outils. Les outils d'historique servent à lister les fenêtres et les entrées, lire une entrée donnée, chercher dans le contenu de la session ; les outils de notes servent à lister, lire, chercher, ajouter et écrire des notes persistantes. Les appels passent par le backend de Codex, nécessitent le fournisseur OpenAI et une authentification backend, et sont eux aussi cachés derrière le feature flag `features.token_budget.use_history_notes_history`.
Sur le plan technique, plusieurs limites ont été mises en place : la sortie est traitée de façon consciente de la troncature, et les paramètres de requête ont des bornes définies. Les remarques de la revue automatique portent surtout sur le plafond de 10 000 tokens pour les résultats en texte brut, les limites de paramètres pour les opérations sur les notes, et la suggestion d'un déploiement progressif.
Ce qui est réellement remplacé
Compression par résumé et changement de fenêtre avec recherche sont, au fond, deux stratégies de mémoire différentes. La première est une compression implicite et avec pertes : le modèle ne sait pas ce qu'il a perdu, ni comment le retrouver. La seconde est un redémarrage explicite et sans état : le modèle sait précisément que l'ancien contenu existe toujours quelque part, et va le chercher en cas de besoin.
Le coût, lui aussi, change de place. L'échec de la compression avec pertes survient en silence ; l'échec du changement de fenêtre se traduit par « il aurait fallu chercher et on n'a pas cherché » ou « on a cherché mais pas trouvé le bon ». Le premier est difficile à déboguer, le second se voit au moins dans les logs. Pour des agents qui exécutent des tâches longues, un échec observable est bien plus facile à gérer qu'un échec silencieux.
L'économie réalisée est le gain de l'autre côté. Un résumé exige un appel modèle supplémentaire, un coût qui se répète sans cesse dans les sessions longues ; le changement de fenêtre ne génère pas cet appel, la recherche ne s'effectue qu'en cas de besoin, entrée par entrée. Pour les utilisateurs intensifs qui épuisent leur quota chaque jour, c'est une économie bien réelle.
Il faut cependant préciser le calendrier : une PR fusionnée ne signifie pas une fonctionnalité en production. Les trois changements restent cachés derrière des feature flags, et la revue automatique continue de suggérer un déploiement progressif. De la première version de l'outil en juin jusqu'au complément historique et notes en août, OpenAI a passé plus de deux mois à peaufiner cette voie — quand l'interrupteur sera activé, et pour qui, les archives du dépôt ne le disent pas encore.
Sources : trois pull requests déjà fusionnées dans le dépôt openai/codex, CocoLoop, commentaires de revue automatique sur GitHub ; noms des outils, noms des feature flags et statut de fusion vérifiés un par un à partir des archives du dépôt.