Un paper d’une équipe ByteDance montre que les agents de codage portent déjà en eux une cartographie de ce qui est pertinent dans le code qu’ils lisent. Pas besoin d’un classificateur externe pour décider ce qu’il faut garder et ce qu’il faut jeter : il suffit d’une petite tête qui lit les représentations internes du modèle et décide, ligne par ligne, de la conserver ou de l’élaguer.

SWE-Pruner Pro fonctionne ainsi : quand l’agent lit la sortie d’un outil, une tête légère transforme ses représentations internes en une étiquette « garder » ou « élaguer » pour chaque ligne, avec un embedding qui tient compte de la longueur de la sortie. Sur deux modèles open-weight et quatre benchmarks multi-tour, l’économie atteint 39% des tokens de prompt et completion en maintenant la qualité (données déclarées dans le paper, non vérifiées par nous). Sur MiMo-V2-Flash l’élagage améliore même les résultats : +3,8% sur SWE-Bench Verified et +2,2 points sur Oolong.

Pourquoi c’est pertinent pour toi. Si tu utilises des agents de codage sur de longues codebases, le contexte est le goulot d’étranglement. Chaque fichier lu, chaque sortie d’outil s’accumule dans la fenêtre et consomme des tokens. Un système qui élague le contexte de l’intérieur du modèle, sans alourdir le pipeline avec un classificateur séparé, réduit les coûts et les latences où ils font le plus mal. C’est particulièrement pertinent pour qui fait du refactoring ou du debugging sur de grands projets, où les sessions s’allongent et le contexte grandit jusqu’à saturer la fenêtre. Le surcoût de tokens dans les agents de codage est un problème concret que nous avons déjà observé de près.

Le code est public sur GitHub, mais nous ne l’avons pas testé.

En détail

Ce qu’il y avait avant.

Les agents de codage travaillant sur des codebases réelles accumulent du contexte à chaque étape. L’agent lit un fichier, exécute une recherche, inspecte un répertoire : chaque sortie finit dans la fenêtre de contexte et y reste pour le reste de la session. Sur de grands projets, la fenêtre se sature rapidement, les coûts augmentent et la qualité du raisonnement se dégrade, car le modèle doit se démêler parmi des milliers de lignes dont beaucoup sont irrélevantes.

La solution existante, appelée SWE-Pruner, attache un classificateur externe au modèle : un modèle séparé lit la sortie de l’outil et décide ce qu’il faut garder et ce qu’il faut jeter. Ça fonctionne, mais ajoute un composant supplémentaire, avec ses coûts et ses latences.

Ce qui change.

Les chercheurs de ByteDance ont découvert que le modèle principal, celui qui joue le rôle d’agent, codifie déjà dans ses représentations internes une indication de pertinence. Quand il lit la sortie d’un outil, ses couches intermédiaires « savent » quelles lignes comptent et lesquelles non. Il suffit d’une tête légère, un petit module ajouté au-dessus du modèle existant, qui lit ces représentations et produit une étiquette binaire pour chaque ligne : garder ou élaguer.

La tête inclut aussi un embedding sensible à la longueur de la sortie, car le jugement sur ce qui est pertinent change si l’outil retourne 10 lignes ou 1 000. Ce détail compte : un classificateur externe traitait toutes les sorties de la même façon, tandis que l’agent adapte son propre filtre à l’échelle du matériel.

Les chiffres, dans leur contexte.

Le paper teste SWE-Pruner Pro sur deux backbones open-weight et quatre benchmarks multi-tour. L’économie maximale déclarée est de 39% des tokens de prompt et completion, avec une surcharge d’inférence que les chercheurs décrivent comme « limitée » sans la quantifier de manière que nous puissions la vérifier à partir du résumé. Sur MiMo-V2-Flash, l’un des deux backbones, l’élagage ne se limite pas à économiser : il améliore les résultats, avec +3,8% sur SWE-Bench Verified et +2,2 points sur Oolong, un benchmark de contexte long.

Le fait que l’élagage du contexte améliore la qualité n’est pas aussi contre-intuitif que cela peut paraître. Un contexte encombré de lignes irrélevantes distrait le modèle et dégrade ses décisions. Moins de bruit, signal plus net.

Jusqu’à quel point faire confiance.

Les chiffres proviennent du paper, pas d’une évaluation indépendante. Les benchmarks sont quatre, les backbones deux : c’est un échantillon respectable pour un paper de recherche, mais cela ne dit pas comment le système se comporterait sur un modèle différent ou sur une codebase avec des caractéristiques différentes. La surcharge d’inférence est décrite comme « limitée » mais n’est pas quantifiée de manière vérifiable dans le résumé. Le code est public sur GitHub, donc quiconque veut peut reproduire ou vérifier.

Qu’en faire.

Si tu construis ou configures des agents de codage pour un usage réel, le point pratique est que le contexte doit être géré aussi en aval : élaguer ce que l’agent a déjà lu et qui n’est plus utile, pas seulement décider en amont ce qu’il faut lui faire lire. SWE-Pruner Pro suggère que le modèle lui-même est la meilleure source pour ce jugement, et qu’un classificateur externe peut être redondant. Pour qui utilise des agents de codage prêts à l’emploi, la leçon reste utile même sans implémenter le système : quand une session s’allonge, compacter le contexte manuellement (en résumant ce qui a émergé et en écartant les sorties brutes) est le geste que ce paper automatise de l’intérieur.