Filtre maison ou optimiseur de tokens open source ?

Construisez votre propre filtre à tokens quand le gaspillage tient dans quelques commandes bruyantes sur un seul agent, et que vous acceptez de mesurer. Adoptez un optimiseur de tokens open source quand il est réparti entre lectures de fichiers, manifestes d'outils et longues sessions, ou entre plusieurs agents. Écrire le filtre est facile ; l'empêcher de coûter plus qu'il ne rapporte, c'est le vrai travail.

Je conçois Tokenade, un optimiseur gratuit et open source, donc pondérez mon avis en conséquence. J'ai aussi fait tourner des filtres maison pendant des mois avant de l'écrire, et une partie de ce qui suit est la liste de mes propres erreurs.

Les faits sur Claude Code cités ici viennent de la documentation d'Anthropic, lue le 15/10/2026. Le seul chiffre Tokenade cité est le résultat publié de THOL, expliqué sur la page méthodologie.

Les options en un coup d'œil

Construire ou adopter : la réponse courte

Construisez si le problème est étroit et que vous le mesurerez. Adoptez un outil existant s'il est large ou si vous ne le mesurerez pas. Un hook de vingt lignes qui ne garde que les échecs de npm test est un bon morceau d'ingénierie. Un système maison qui veut couvrir commandes, lectures de fichiers, recherche et MCP sur trois agents est un second produit que vous maintenez désormais.

La question décisive n'est pas « suis-je capable de l'écrire ? ». Vous l'êtes. C'est « est-ce que je remarquerai quand il commencera à me coûter de l'argent ? ». La plupart des filtres maison échouent en silence, et l'échec ressemble à une session normale avec une facture un peu plus lourde.

Ce que demande vraiment un filtre maison

Un filtre à tokens maison, c'est en général quatre couches, ajoutées une à une à mesure que la précédente se révèle insuffisante.

1. Des règles dans CLAUDE.md. « Ne fais jamais cat sur un log entier, passe-le dans tail -50. » Pas cher, et l'agent écoute souvent. Mais Anthropic est explicite : Claude les traite « comme du contexte, pas comme une configuration imposée », et renvoie vers un hook PreToolUse quand il faut une garantie (doc mémoire). Chaque règle est aussi renvoyée à chaque tour, si bien qu'un long règlement devient un coût en soi.

2. Des wrappers shell. Un script test qui lance la suite et n'affiche que le résumé et les tests en échec. Ça marche bien quand vous connaissez la commande à l'avance. Ça ne sert à rien quand l'agent improvise une commande que vous n'avez pas emballée, ce qu'il fait sans arrêt.

3. Des hooks. C'est là que vivent les vrais filtres maison. updatedInput sur PreToolUse réécrit un appel avant son exécution ; updatedToolOutput sur PostToolUse remplace le résultat avant que Claude le lise (référence des hooks). J'ai cartographié chaque événement et son coût dans Hooks Claude Code : lesquels ajoutent des tokens, lesquels en retirent.

4. Un proxy MCP. La version ambitieuse : un serveur entre l'agent et ses outils qui compresse les résultats, déduplique les lectures, ajoute peut-être une recherche. À ce stade, vous construisez un optimiseur, sans autre utilisateur que vous pour en trouver les bugs.

Claude Code a déjà des valeurs par défaut à connaître avant d'écrire quoi que ce soit. Un résultat Bash réussi est renvoyé en ligne jusqu'à environ 30 000 caractères ; au-delà, Claude reçoit un chemin de fichier et un aperçu de 2 000 caractères. Une commande en échec reçoit environ 10 000 caractères, en extrait début-et-fin (référence des outils, limites de sortie). La variable BASH_MAX_OUTPUT_LENGTH déplace ce plafond (variables d'environnement).

Le geste maison le plus rudimentaire, baisser cette variable, tient donc en une ligne. Il est aussi brutal : il coupe toutes les commandes au même endroit, que la ligne utile soit en haut ou en bas.

Là où le fait-maison marche vraiment

Le fait-maison est le bon choix plus souvent que les auteurs d'outils comme moi ne l'admettent. Voici les cas où je dirais à un ami d'écrire le filtre et de ne rien installer :

• Une ou deux commandes concentrent le bruit. Un monorepo dont le test runner imprime 4 000 lignes de tests réussis. Un filtre qui garde le résumé et les échecs est rentable le jour même.
• Vous utilisez un seul agent et le mettez rarement à jour. Le format des hooks est assez stable au sein d'un outil, et vous verrez quand il change.
• Vos sessions sont courtes. Sur une session de dix tours, un log égaré coûte peu. L'effet cumulatif qui rend le filtrage rentable a besoin de durée.
• Vous voulez une règle stricte, pas des économies. Bloquer cat sur .env ou plafonner une commande connue pour être énorme, c'est un garde-fou, et c'est exactement ce à quoi servent les hooks.
• Ça vous amuse et vous mesurez. Si vous lisez votre transcript avant et après, vous attraperez vos propres régressions. Cette habitude sépare un filtre maison qui marche d'un placebo.

La technique derrière la plupart de ces cas est ancienne et bien comprise ; l'output filtering des logs de commandes détaille le principe « verdict plus erreur ».

Les coûts cachés d'un filtre maison

Les coûts ci-dessous n'apparaissent pas quand vous écrivez le filtre. Ils apparaissent trois semaines plus tard, sur une facture qui a monté au lieu de baisser.

L'agent relance ce que vous avez coupé

Un filtre qui supprime l'octet dont le modèle avait besoin pousse le modèle à aller le rechercher. Vous réduisez une stack trace à ses dix dernières lignes ; la frame utile était à la ligne douze. L'agent relance la commande avec 2>&1 | grep, ou lit directement le fichier de log, en contournant votre filtre. Vous avez payé la sortie élaguée, la relance et la sortie complète.

C'est le mode de défaillance le plus fréquent que je vois sur le benchmark ouvert THOL, qui le décrit sans détour : quand la compaction retire les octets dont le modèle avait réellement besoin, le modèle relance simplement la commande, souvent en contournant l'outil (classement THOL, lu le 15/10/2026). Un filtre avec perte doit offrir à l'agent un moyen de récupérer la sortie complète sans rien réexécuter.

Votre filtre casse le cache

Le prompt caching ne paie que si le début de la requête est identique, octet pour octet, à la précédente. La doc d'Anthropic liste ce qui l'invalide : modifier les définitions d'outils, par exemple, invalide tout le cache (prompt caching). Une lecture en cache est facturée à une fraction de l'entrée fraîche, donc la perdre coûte cher.

Un proxy MCP maison qui active et désactive des outils en cours de session, ou un hook qui réécrit l'historique, peut transformer un préfixe en cache bon marché en relecture plein tarif à chaque tour. THOL l'a observé précisément avec un proxy qui réécrit l'historique : les quelques tokens gagnés par sa compression étaient écrasés par le cache qu'il cassait. Le mécanisme est détaillé dans prompt caching et facture d'entrée.

Le surcoût permanent oublié

Chaque règle, description d'outil et rappel injecté se paie à chaque tour. Une section de CLAUDE.md qui explique vos filtres, un serveur MCP qui expose six outils d'aide, un hook UserPromptSubmit qui affiche un rappel : chacun est petit, et chacun est renvoyé jusqu'à la fin de la session.

Si l'agent utilise rarement l'outil, sa description est une perte sèche. THOL cite ce coût permanent parmi les principales raisons pour lesquelles des outils séduisants isolément échouent de bout en bout.

La maintenance entre agents et versions

Votre filtre est écrit contre l'interface d'un agent, et cette interface bouge. La référence des hooks de Claude Code ne cesse d'ajouter des événements et des champs ; les limites de sortie et les valeurs par défaut changent d'une version à l'autre. Si vous utilisez aussi Codex, Cursor ou Copilot, chacun a sa propre surface d'extension, et votre hook n'y tourne pas du tout.

Les pannes sont silencieuses. La référence précise qu'un hook de commande PreToolUse qui atteint son timeout ne bloque pas l'appel d'outil, et qu'un chemin de script mal tapé désactive un garde-fou avec un simple avertissement non bloquant. Votre filtre peut être éteint une semaine sans que rien ne vous prévienne.

Aucune mesure de bout en bout

Le chiffre que vous voyez, c'est ce que votre filtre a retiré, pas ce que la session a coûté. Compter les octets avant et après un filtre est facile. Savoir si la session entière est devenue moins chère, après relances, défauts de cache et tours supplémentaires, exige des sessions appariées sur la même tâche, avec et sans le filtre.

Presque personne ne le fait avec un filtre maison, et c'est le seul test qui compte. Commencez par mesurer l'usage de tokens de votre agent avant de faire confiance à un filtre, le mien compris.

Quand adopter un outil open source a du sens

Adopter a du sens quand garder un filtre juste coûte plus que le temps d'installer et d'évaluer un outil existant. En pratique, cela arrive dans ces situations :

• Vos tokens viennent surtout des lectures de fichiers, pas des commandes. Les hooks sur Bash ne touchent pas aux outils de lecture et de recherche intégrés de l'agent, sauf à écrire une logique dédiée pour chacun. La skeleton compression des lectures de fichiers est une autre technique que le filtrage de logs, avec ses propres cas limites.
• Vous utilisez plus d'un agent. Réécrire le même filtre pour le format de hooks de chaque agent, puis à chaque mise à jour, c'est la taxe de maintenance à son pire.
• Vos sessions sont longues. C'est là que se joue l'effet cumulatif, et là que relances et cache cassé font le plus mal.
• Vous voulez un résultat mesuré plutôt qu'une impression. Un outil packagé doit vous montrer ce qu'il a fait, et idéalement être mesuré de bout en bout face à un témoin.

Sur ce dernier point, mon propre chiffre : sur les longues sessions, Tokenade réduit de 39 % le coût d'une session par rapport à Claude Code seul, sur le benchmark THOL (méthodologie). Je maintiens ce benchmark, donc le protocole et les données brutes sont publiés pour que vous puissiez vérifier.

Ce qu'un outil packagé vous apporte, ce sont les parties fastidieuses à construire : la sortie repliée conservée en local, pour que l'agent récupère les octets exacts avec tokenade expand-ref au lieu de relancer la commande ; une compression qui garde le préfixe en cache stable ; et la même couverture sur Claude Code, Codex, Cursor, Copilot et Windsurf.

La compaction tourne sur l'ordinateur où vous travaillez, sans télémétrie. Tokenade est gratuit et open source (MIT/Apache-2.0), sans compte : l'adopter coûte du temps d'installation, pas d'argent. Et comme le code est public, vous gardez le principal avantage du fait-maison : vous pouvez lire exactement ce qu'il fait à vos sorties, ou le forker.

Comment j'ai comparé les deux

J'ai jugé les deux voies sur ce qui arrive sur la facture, pas sur la quantité de texte retirée par un filtre. Cinq questions :

1. Couvre-t-il les canaux où se trouvent réellement vos tokens (commandes, lectures, recherche, MCP) ?
2. Quand il coupe trop, l'agent peut-il récupérer sans relancer ?
3. Garde-t-il le préfixe en cache identique octet pour octet ?
4. Survit-il aux mises à jour de l'agent et à un second agent ?
5. Existe-t-il une mesure avant/après à l'échelle de la session ?

Lequel choisir ?

• Dev solo, un agent, une suite de tests bruyante : écrivez un hook PostToolUse. Gardez les échecs et la ligne de résumé.
• Vous voulez un garde-fou, pas des économies : construisez-le. Un garde-fou PreToolUse est le bon outil.
• Gros usage quotidien, longues sessions, surtout des lectures de fichiers : adoptez un optimiseur existant, ou au moins testez-en un pendant une semaine.
• Plusieurs agents dans la même semaine : adoptez-en un. Maintenir quatre variantes d'un filtre n'est pas un loisir.
• Vous ne mesurez pas encore : ni l'un ni l'autre. Mesurez une semaine, puis décidez.

FAQ

Un hook Claude Code maison suffit-il à réduire l'usage de tokens ?

Pour un problème étroit, oui. Un hook PostToolUse qui renvoie updatedToolOutput avec seulement les échecs et la ligne de résumé peut réduire un log de tests bruyant à une fraction. Il ne touche ni aux lectures de fichiers, ni à la recherche, ni aux manifestes MCP, et il ne tourne que sur Claude Code. Mesurez l'entrée totale de la session avant et après, pas la taille d'un résultat élagué.

Pourquoi un filtre ferait-il monter ma facture ?

De trois façons. Il supprime une ligne dont le modèle avait besoin, et l'agent relance la commande en payant deux fois. Il modifie quelque chose au début du contexte, le préfixe en cache est perdu et l'historique est relu plein tarif. Ou il ajoute des consignes et des descriptions d'outils renvoyées à chaque tour. Les trois sont invisibles si vous ne comptez que les octets retirés.

Puis-je simplement baisser BASH_MAX_OUTPUT_LENGTH ?

Oui, et c'est l'expérience la moins chère qui soit. Par défaut, Claude Code renvoie en ligne la sortie Bash réussie jusqu'à environ 30 000 caractères, et enregistre les résultats plus gros dans un fichier avec un aperçu de 2 000 caractères. Baisser la limite coupe toutes les commandes au même point, si bien qu'une ligne utile en fin de sortie peut finir dans un fichier que l'agent devra lire.

Vaut-il mieux écrire des règles dans CLAUDE.md que des hooks ?

CLAUDE.md pour les habitudes, les hooks pour les garanties. La documentation d'Anthropic indique que Claude traite CLAUDE.md comme du contexte plutôt que comme une configuration imposée, et recommande un hook PreToolUse quand une action doit être bloquée quoi qu'il arrive. Les règles coûtent aussi des tokens à chaque tour : gardez-les courtes.

Tokenade est-il open source ?

Oui. Tokenade est open source sous licence MIT OR Apache-2.0, et le code est sur GitHub. La compaction tourne en local sur l'ordinateur où vous travaillez, sans télémétrie, donc votre code et vos logs ne sont envoyés nulle part. Si vous devez pouvoir inspecter chaque ligne de votre filtre, vous pouvez lire celui de Tokenade ou construire le vôtre.

---

À voir aussi :

• Hooks Claude Code : lesquels ajoutent des tokens, lesquels en retirent : la carte des coûts, événement par événement, pour les filtres maison
• Output filtering : alléger les logs de commandes : la technique « verdict plus erreur »
• Skeleton compression des lectures de fichiers : le canal que la plupart des filtres maison oublient
• Mesurer l'usage de tokens d'un agent : le test avant/après dont tout filtre a besoin
• Meilleurs optimiseurs de tokens pour Claude Code : si vous décidez d'adopter un outil, le classement complet