L'agent raye lui-même les anciennes réponses d'outils et réduit de moitié les tokens d'entrée

Un agent qui enchaîne les appels d'outils accumule vite un long historique : logs, dumps, sorties de commandes, contenus de fichiers. Dans chacune de ces réponses, la part utile est souvent d'un ordre de grandeur inférieure à la réponse elle-même, mais celle-ci est réexpédiée en entier à chaque requête suivante. Les auteurs d'un preprint publié sur arXiv proposent de confier le nettoyage au modèle lui-même. Dans leur cas de recherche, le prompt final atteint avec cette approche 231 951 tokens contre 912 492 avec un stockage classique de l'historique. Le volume total d'entrée baisse de 50 %, et le coût estimé de l'API tombe à $1,28–1,44 au lieu d'environ $4,38.

Comment fonctionne l'oubli

La mécanique est simple. Le modèle en action choisit des résultats d'appels d'outils reçus précédemment et remplace chacun par une courte note, exactement à sa position d'origine dans le dialogue. L'ordre des messages et la structure de l'historique restent intacts. L'original exact n'est pas supprimé : il est placé dans une archive, d'où une commande explicite permet de le restaurer s'il redevient nécessaire.

L'approche prend la forme d'un harness en Python, qui donne à l'agent deux actions : l'archivage par lots et la restauration. Il n'est pas nécessaire de réentraîner le modèle pour la tâche. Une protection est également prévue : les instructions de l'utilisateur et les messages de l'assistant ne peuvent pas faire l'objet de ces opérations. Seules les observations peuvent être oubliées, pas ce que l'humain a demandé ni ce que l'agent a dit de lui-même.

Ce que montrent les expériences

Le cas principal est un cas de recherche : un débogage avec OpenTelemetry, suivi d'une tâche d'implémentation sans rapport. C'est précisément une trajectoire bruyante, où les sorties volumineuses servent pendant quelques étapes avant de devenir un simple poids mort.

• Prompt final : 231 951 tokens contre 912 492 avec l'historique conservé.
• Tokens d'entrée cumulés : 50 % de moins.
• Coût estimé de l'API : $1,28–1,44 contre environ $4,38.
• Test comportemental : les deux variantes ont passé l'oracle principal à deux cas.
• Évaluation du follow-up : aucune des deux variantes ne l'a satisfaite pleinement.
• Coûts : davantage de requêtes et 17 % de temps d'exécution en plus.

Économiser des tokens ne revient pas à économiser sur tout. L'agent consacre des étapes au processus de curation lui-même, et cela se voit dans le temps d'exécution.

Là où la méthode n'a pas fonctionné

Les auteurs présentent honnêtement des contre-exemples. Sur une paire contrastée liée au développement d'une application, ils n'ont obtenu d'économie ni sur le contexte, ni sur le coût. Une expérience antérieure avec reprise de session a montré une qualité inférieure selon une évaluation manuelle, bien que le contexte ait été réduit. L'échantillon est petit, les cas sont exploratoires et il n'y a pas de statistiques. Ce travail ne prouve pas que l'astuce convient partout. Il montre que le gain dépend fortement de la nature de la charge, et les auteurs font de cette dépendance le facteur central de la gestion réversible du contexte.

Que tester en pratique

Si votre agent mène de longues sessions de débogage, d'analyse de logs ou de recherche dans de gros volumes de résultats, l'idée mérite une expérience. Commencez par des observations faciles à restaurer : sorties de tests, traces, dumps. Laissez les instructions et les messages de l'assistant intacts, comme dans le schéma d'origine.

Mesurez non seulement les tokens, mais aussi le nombre de requêtes, le temps et la qualité du résultat sur vos propres tâches, car l'économie peut s'avérer apparente. Pour les tâches où chaque fragment de code ou de configuration revient sans cesse, l'archivage peut ne rien apporter. La réversibilité est ici une assurance, pas une garantie : si l'agent a oublié le mauvais élément, il doit s'en apercevoir et le redemander.