Output filtering : alléger les logs de commandes pour les

Qu'est-ce que l'output filtering pour les agents de codage IA ?

L'output filtering, c'est la pratique qui consiste à réduire la sortie d'un outil ou d'une commande aux seules lignes qui comptent avant même qu'elle n'atteigne la context window du modèle. Quand votre agent lance npm install, cargo build, pytest ou terraform plan, la commande déverse des centaines de lignes de barres de progression, d'arbres de dépendances et d'avertissements de dépréciation — et par défaut chacune de ces lignes devient des tokens que le modèle doit lire, à ce tour-ci et à chaque tour suivant, tant que le log persiste dans le transcript. Je passe une grande partie de mon temps à scruter des factures de tokens, et la sortie de commande est le poste qui surprend le plus les gens. Ils s'obsèdent sur la taille des fichiers que l'agent lit, puis lancent un seul pnpm install et envoient 4 000 lignes de « resolved / downloaded / linked » directement dans un modèle frontier, au prix d'un modèle frontier. L'agent n'a pas besoin du log de résolution. Il a besoin de savoir si l'installation a réussi et, sinon, quel paquet a cassé. L'output filtering, c'est la façon de lui donner exactement ça et rien d'autre. Cela fait partie de la discipline plus large du context engineering — décider ce que le modèle voit, sous quelle forme et dans quel ordre. La sortie de commande en est l'un des recoins les moins aimés, ce qui explique précisément pourquoi il y a tant de gaspillage à y récupérer.

Pourquoi les logs de commandes coûtent-ils si cher dans une boucle agentique ?

Les logs de commandes coûtent si cher parce qu'ils sont renvoyés à chaque tour suivant, et pas seulement à celui où la commande a tourné. C'est la partie que les gens manquent. Dans un chat one-shot, un log bruyant ne vous coûte qu'une fois. Dans une boucle d'agentic coding, l'agent garde la sortie de commande dans son transcript pour « se souvenir » de ce qui s'est passé, et ce transcript est resoumis en entrée à chaque nouveau tour jusqu'à ce que quelque chose compacte ou évince. Un log de build de 3 000 tokens n'est pas un coût de 3 000 tokens. Sur dix tours supplémentaires de la même session, c'est plutôt 30 000 tokens d'entrée que vous avez payés pour dire trente fois la même chose au modèle. Maintenant chiffrez-le. Sur Claude Opus 4.8, l'input revient à 5 $ par million de tokens et l'output à 25 $ ; sur Sonnet 4.6, c'est 3 $ / 15 $ ; sur Haiku 4.5, 1 $ / 5 $ ; GPT-5.5 se situe à 5 $ / 30 $ (tarifs Anthropic, tarifs OpenAI, 2026). Le prompt caching atténue le coup — un cache read représente environ 10 % du tarif d'input — mais le caching n'aide que lorsque le préfixe est stable, et un log de commande frais et verbeux est un tout nouveau suffixe qui n'a pas encore été mis en cache. La première fois que le modèle lit ce log, vous payez plein tarif. Il y a une seconde taxe, plus subtile. Les modèles prêtent le moins d'attention au contenu échoué au milieu d'une longue fenêtre — l'effet « Lost in the Middle » documenté par Liu et al. (2023, arxiv.org/abs/2307.03172). Un mur de lignes de résolution de dépendances ne coûte pas seulement de l'argent ; il repousse la seule ligne qui comptait — l'erreur réelle — dans la zone de faible attention où le modèle est le plus susceptible de passer dessus sans la voir. Filtrer le bruit relève le rapport signal/bruit et rend le modèle plus précis, pas seulement moins cher.

Que supprime réellement l'output filtering ?

L'output filtering supprime les lignes qui ne portent aucune information pertinente pour une décision, tout en préservant chaque ligne dont l'agent a besoin pour choisir son action suivante. En pratique, cela se range en trois catégories. Le bruit de progression pur. Barres de téléchargement, spinners, compteurs de pourcentage, « resolving… », « linking… », redessins répétés via retour chariot \r. Rien de tout cela ne survit pour influencer une décision ; tout cela coûte des tokens. C'est la chose la plus facile et la plus sûre à jeter. La répétition dédupliquée. Les test runners, linters et type checkers adorent imprimer le même avertissement 200 fois — une fois par fichier. Le modèle a besoin de savoir que l'avertissement existe et grossièrement à quelle fréquence, pas de lire 200 copies identiques. Réduire « cette ligne répétée 200× » en une seule ligne plus un comptage conserve le signal et écarte la redondance. Le boilerplate de succès en masse. Quand cargo build se termine par Finished dev [unoptimized] in 14.2s avec 600 lignes vertes « Compiling » au-dessus, l'agent n'a besoin que du verdict et d'éventuels avertissements. En cas de succès, le corps du log est du bruit ; en cas d'échec, on garde l'erreur et son contexte environnant. Ce que l'output filtering ne doit jamais supprimer, c'est la charge utile de l'échec : le message d'erreur, la stack frame, l'assertion échouée, le nom du paquet fautif, le diff qui ne s'est pas appliqué. Tout l'enjeu est d'être impitoyable avec le bruit et conservateur avec le signal. Un filtre qui supprime une vraie erreur pour économiser des tokens est pire que pas de filtre du tout — il fait gesticuler l'agent à l'aveugle et brûler bien plus de tokens à se rattraper qu'il n'en a jamais économisé. Voir output filtering pour la définition canonique.

Comment applique-t-on l'output filtering aujourd'hui ?

On applique l'output filtering en interceptant la sortie de commande entre le shell et le modèle, puis en la résumant ou en la compactant avant qu'elle n'entre dans le contexte. Voici la séquence pratique que j'utilise.

Identifiez vos commandes les plus bruyantes. Elles sont prévisibles : installations de paquets (npm, pnpm, pip, cargo), builds, suites de tests complètes, git status/git log sur des dépôts chargés, kubectl, terraform plan, docker build. Ce sont elles qui produisent le gros du bruit.
Décidez la forme verdict-plus-détail. Pour chacune, la sortie utile est « est-ce que c'est passé ? » plus « sinon, quelle est la plus petite tranche de log qui explique l'échec ? » Concevez votre filtre pour émettre exactement cela.
Éliminez d'abord le bruit évident. Les redessins par retour chariot, les codes couleur ANSI, les pourcentages de progression et les horodatages sur chaque ligne sont du pur surcoût. Les retirer suffit souvent à diviser un log par deux.
Dédupliquez les lignes répétées avec un comptage, et tronquez les longs corps de succès en tête + queue + résumé. Gardez les échecs intacts.
Mesurez avant et après. C'est non négociable. Faites passer un vrai build dans votre filtre, comptez les tokens sur les deux versions, et confirmez que le modèle répond toujours correctement. Si vous ne mesurez pas, vous devinez — et deviner, c'est comme ça qu'on supprime accidentellement la seule ligne d'erreur qui comptait.

Si bricoler des wrappers shell et peaufiner des regex pour terraform contre cargo contre pytest ressemble à une quête annexe dont vous vous passeriez, c'est le manque que Tokenade comble : il s'intercale entre votre agent et ses outils, applique l'output filtering (aux côtés de la semantic code search, de la skeleton compression et du chargement paresseux des MCP) automatiquement, et vous montre les tokens économisés sur un dashboard, de sorte que l'étape « mesurer avant et après » est faite pour vous. Il fonctionne avec Claude Code, Cursor, Codex, Copilot et Windsurf, il est source-available sous licence MIT donc vous pouvez lire exactement ce qu'il élague, et le tier gratuit couvre jusqu'à environ 10M tokens par mois avant Pro (19,90 $/mois hors taxe aux États-Unis, 19,90 €/mois TTC en France, postes illimités).

Combien l'output filtering peut-il réellement économiser ?

Les économies de l'output filtering croissent avec le niveau de bruit de vos commandes et la durée de vos sessions — plus la commande est bruyante et plus elle reste longtemps dans le transcript, plus vous récupérez. Le mécanisme est une simple multiplication : tokens retirés × tours où le log aurait survécu × votre tarif d'input. Une façon concrète d'y penser. Disons qu'un seul log de pnpm install fait 3 000 tokens majoritairement de bruit qui se compresse à 200 tokens (le verdict plus d'éventuels avertissements). Cela fait 2 800 tokens économisés au tour où il a tourné. Si la session se poursuit pendant dix tours de plus avec ce log dans le transcript, et que vous êtes sur Opus 4.8 en input à 5 $ par million, vous avez évité de renvoyer 28 000 tokens — environ 14 cents pour une seule install. Faites cela sur une journée d'installs, de builds et de runs de tests, et ça se cumule en argent réel. Je m'abstiens délibérément de citer ici un chiffre racoleur « X % moins cher », parce que la réponse honnête est « ça dépend de votre mix de commandes » — le seul nombre qui compte est celui que vous mesurez sur vos propres logs. L'output filtering se cumule aussi avec les autres leviers de tokens plutôt que de les concurrencer. Élaguer les fichiers que l'agent lit est un axe ; élaguer la sortie de commande qu'il lit en est un autre, orthogonal. Tirez les deux et l'effet se multiplie. Pour l'ensemble complet des leviers et la place de celui-ci, voir Comment réduire l'usage de tokens de Claude Code.

Qu'est-ce qui tourne mal avec l'output filtering (anti-patterns) ?

Les modes de défaillance sont prévisibles, et chacun d'eux vient du fait d'être trop agressif plutôt que trop prudent. Supprimer l'erreur pour économiser le token. Le péché capital. Un filtre réglé pour une compression maximale qui avale la stack trace transforme un échec débogable en mystère. L'agent relance alors la commande, relit un log désormais différent, et part en vrille — dépensant plus de tokens que le filtre n'en a jamais économisé. Préservez toujours les charges utiles d'échec en entier. Filtrer une sortie interactive ou en streaming. Certaines commandes attendent un TTY ou diffusent en flux des tokens dont l'agent a besoin en temps réel. Les bufferiser et les résumer aveuglément les casse. Filtrez la sortie des commandes batch ; laissez tranquilles les flux véritablement interactifs. Compresser une sortie déjà minuscule. Emballer un git status de 12 lignes dans une couche de filtrage ajoute de la latence et de la complexité sans aucun gain de tokens. Réservez le filtrage aux commandes véritablement bruyantes ; un bon filtre est un no-op sur une sortie courte. Filtrer sans mesurer. Si vous ne pouvez pas voir combien de tokens sont entrés versus sortis, vous ne pouvez pas distinguer un filtre qui marche d'un filtre qui charcute silencieusement les logs. Instrumentez-le. Un token counter de chaque côté du filtre est la barre minimale, et un dashboard d'économies en cours est ce qui transforme « je crois que ça aide » en « ça a économisé 4,2M tokens cette semaine ». L'output filtering n'a rien de glamour. C'est de la plomberie. Mais c'est de la plomberie qui se branche directement sur le poste le plus surpayé de l'agentic coding, et c'est ce qui en fait l'une des habitudes au plus fort levier qu'un gros utilisateur d'agents puisse se construire.

À voir aussi :

Output filtering : alléger les logs de commandes pour les agents