Une étude de l'université du Texas à Austin mesure l'effet de la compression de contexte sur les agents de code
Selon arXiv.org et la fiche d'academy.dair.ai, des chercheurs de l'université du Texas à Austin ont mené près de 35 000 exécutions d'agents sur SWE-bench Verified et Terminal-Bench afin d'isoler les décisions habituellement regroupées dans une politique de compression de contexte : la méthode employée, le moment du déclenchement et la quantité d'information retirée. Les auteurs mesurent le taux de réussite, la consommation de jetons, la latence de bout en bout et le coût estimé. D'après l'article, sur Terminal-Bench avec Qwen, des politiques consommant environ un tiers des jetons peuvent prendre de 20 % à 80 % de temps de plus que l'agent sans compression, les appels de résumé et les étapes supplémentaires ajoutant de la durée.
Ce que ça change pour toi
Si tu tailles le contexte de ton agent pour alléger la facture, mesure aussi la durée et le coût réels : d'après ces travaux, ils peuvent évoluer à contresens du nombre de jetons. Garde en tête qu'un réglage trouvé pour un modèle demande un nouvel essai dès que tu changes de moteur. Concrètement, fixe un petit lot de tâches représentatives de ton travail, fais tourner ton agent avec puis sans compression, et compare temps total, coût facturé et résultats obtenus avant de figer ta configuration.
Un message relaie une étude attribuée à l'université du Texas à Austin sur la compression de contexte dans les agents de code. Près de 35 000 exécutions d'agents ont été menées sur SWE-bench Verified et Terminal-Bench, en faisant varier séparément trois décisions : la méthode de compression, son déclenchement et le volume retiré. Les chiffres rapportés indiquent que des politiques utilisant environ un tiers des jetons peuvent allonger la durée d'exécution de 20 % à 80 % par rapport au contexte complet.
Un réglage que tu subis sans le voir
Quand une session d'agent s'allonge, l'historique de raisonnement, d'actions et de sorties d'outils finit par être compressé. Selon arXiv.org, les harnais existants regroupent dans une politique figée ce qu'il faut compresser, à quel moment et dans quelle proportion. L'apport de l'étude consiste à faire varier ces décisions séparément pour observer comment chacune pèse sur la réussite et sur le coût d'exécution. Tu es concerné même sans toucher à ces réglages : dans un outil d'agent du commerce, cette politique existe déjà, quelqu'un d'autre l'a choisie pour toi, et elle influence tes résultats autant que le modèle que tu as retenu.
Moins de jetons peut te coûter plus de temps
Un résultat contre-intuitif rapporté par les auteurs concerne la latence : sur Terminal-Bench avec Qwen, des politiques utilisant environ un tiers des jetons peuvent allonger l'exécution de 20 % à 80 % par rapport au contexte complet. L'explication avancée tient aux appels de résumé qui s'ajoutent et aux étapes supplémentaires que l'agent doit refaire quand il a perdu de l'information utile. Si tu suis uniquement le nombre de jetons facturés, tu peux donc croire à une économie tout en payant davantage de temps machine et d'attente. Regarde le coût complet, latence comprise.
Ton réglage ne voyage pas d'un modèle à l'autre
Les auteurs rapportent que des politiques affichant un taux de réussite global voisin résolvent des tâches différentes, et qu'une même politique se comporte très différemment selon le modèle. La fiche d'academy.dair.ai cite un cas où une politique donnée fait descendre Devstral à 38,7 % tout en augmentant sa latence, sans que les extraits consultés précisent la définition exacte de ce score. Tu en tires une règle de prudence : un réglage recommandé dans un article de blog ou livré comme configuration par défaut ne t'offre aucune garantie sur ton couple modèle plus tâche.
Comment vérifier chez toi
Construis un lot de tâches représentatives de ton travail réel, assez petit pour que tu le rejoues souvent et assez varié pour que tu ne te trompes pas sur un cas isolé. Exécute-le avec le contexte complet pour obtenir ta référence, puis avec le réglage de compression que tu envisages. Relève à chaque fois la réussite, la durée de bout en bout et le coût facturé, et compare ces trois indicateurs ensemble. Rejoue l'essai après chaque changement de modèle. Ce protocole te demande du temps une fois, puis il te protège des réglages que tu adopterais par habitude ou sur recommandation extérieure.
Ce que la source n'établit pas pour toi
L'étude porte sur des modèles à poids ouverts et sur des bancs d'essai de code et de terminal, ce qui ne te renseigne pas directement sur un agent de rédaction, de support client ou de traitement documentaire. Les extraits consultés ne décrivent pas chaque politique testée en détail ni le matériel de mesure, et ils restent partiels : l'article complet peut contenir ces éléments. Rien n'y indique non plus une réplication par des tiers. Retiens donc la méthode, séparer les décisions et mesurer leurs effets, et évite de recopier des valeurs telles quelles dans ta configuration.
Ce qui reste à vérifier
Les mesures sont celles des auteurs, sur des modèles à poids ouverts et des bancs d'essai publics, sans reproduction indépendante signalée dans les extraits consultés. Ces extraits ne décrivent pas en détail chaque politique testée, ne précisent ni la définition du score de 38,7 % attribué à Devstral ni le matériel utilisé pour chronométrer les exécutions, et ils restent partiels. Ce que l'étude établit, c'est que l'économie de jetons suffit mal à juger une politique de compression. Ce que tu dois tester toi-même, c'est le réglage adapté à ta tâche, à ton modèle et à ta charge de travail.