Token Economy : trois outils qui attaquent le problème différemment

Les context windows grandissent. Gemini, Claude — tous à 1M tokens maintenant. Et pourtant, les agents qui tournent en production saturent leur contexte en moins d’une heure de session intensive. Pas un paradoxe : une course que le volume de données générées gagne systématiquement sur la taille des fenêtres.

Trois outils récents attaquent ce problème, chacun à un niveau différent de la chaîne. Pas de solution universelle : des philosophies distinctes, des compromis différents.

Le vrai problème n’est pas le prix des tokens

Le coût est la justification qu’on donne aux managers. Le vrai problème, c’est la qualité du raisonnement.

Un LLM avec un contexte de 180k tokens utilisés sur 200k ne raisonne pas aussi bien qu’avec 40k. L’attention se dilue. Les instructions système du début de session pèsent moins. L’agent commence à oublier, pas les faits bruts, mais les contraintes, les priorités, le fil conducteur de ce qu’il était censé faire.

C’est observable en pratique : dans une session de débogage longue, l’agent qui a accumulé 50 tours de git status, cat fichier.ts, et des stack traces répétées commence à proposer des solutions qu’il avait déjà essayées. Pas parce qu’il est stupide. Parce que le signal est noyé dans le bruit.

La réduction de tokens n’est donc pas une optimisation de coût avec effet de bord positif sur la qualité. C’est une question de fiabilité avant tout.

Trois niveaux d’attaque

Les approches ne sont pas interchangeables parce qu’elles n’agissent pas au même endroit.

graph TD
    subgraph "Couche 3 — Historique de contexte"
        DCP["DCP\nDynamic Context Pruning\nPrune l'historique accumulé"]
    end
    subgraph "Couche 2 — Outputs des outils"
        RTK["RTK\nRust Token Killer\nFiltre les sorties avant injection"]
    end
    subgraph "Couche 1 — Réponses du modèle"
        CAV["Caveman\nContraint la verbosité du LLM"]
    end

    CAV --> RTK --> DCP

RTK intercepte les sorties des outils système avant qu’elles entrent dans le contexte. DCP travaille sur ce qui est déjà dans la fenêtre de contexte. Caveman agit sur ce que le modèle produit en réponse. Trois points d’intervention distincts, trois mécaniques qui ne se substituent pas l’une à l’autre.

RTK : compresser ce que les outils racontent

RTK (Rust Token Killer) est un proxy CLI écrit en Rust. Il s’intercale entre l’agent et les commandes système : git status devient rtk git status, mais via un hook shell rtk-rewrite.sh, cette réécriture est transparente. L’agent appelle git status, RTK intercepte, filtre, et renvoie une sortie allégée.

40+ commandes couvertes. Le cas concret : cargo test génère typiquement 25k tokens de sortie (tests passants, warnings, timings, statistiques de couverture) réduit à 2,5k. Les tests qui échouent, les erreurs, rien d’autre. Startup en moins de 10ms.

Le filtrage est sémantique, pas mécanique. RTK ne tronque pas à N lignes. Il comprend que dans une sortie de tests, ce qui compte c’est ce qui a échoué. Dans un git log, les 50 derniers commits importent moins que le diff du HEAD. Dans des logs applicatifs, les lignes dupliquées n’apportent rien après la première occurrence.

Les exit codes sont préservés. L’agent conserve le signal de succès/échec, souvent la seule information dont il a besoin pour décider de la suite. Le reste était du padding.

Compatible Claude Code, Cursor, Windsurf — n’importe quel agent qui invoque des commandes shell.

→ github.com/rtk-ai/rtk

DCP : gérer ce qui s’accumule

DCP (Dynamic Context Pruning) n’est pas un proxy. C’est un plugin qui agit directement à l’intérieur de la fenêtre de contexte, sur l’historique déjà accumulé.

Deux mécaniques coexistent. La première est automatique : déduplication des tool calls identiques (si l’agent a appelé ls trois fois avec le même résultat, DCP n’en garde qu’un), purge des inputs d’erreurs après N tours, suppression des writes redondants. Ça tourne en continu sans intervention.

La deuxième est plus intéressante : l’agent lui-même dispose d’un outil compress qu’il peut invoquer pour résumer des blocs de contexte terminés. L’agent décide quand une portion de l’historique peut être cristallisée en résumé dense, libérant de l’espace pour la suite. Les compressions peuvent s’imbriquer si la session est très longue.

RTK empêche les déchets d’entrer. DCP gère ce qui est déjà là et ne peut pas toujours être évité. Ce n’est pas le même problème.

La limitation actuelle : DCP est spécifique à OpenCode. Le système de protection (turn protection, patterns de fichiers, outils protégés) est configuré via dcp.jsonc et s’intègre dans l’infrastructure d’OpenCode. Pas encore portable vers d’autres agents.

→ github.com/Opencode-DCP/opencode-dynamic-context-pruning

Caveman : compresser ce que l’IA dit

55 000 étoiles GitHub en quelques semaines. Ce chiffre dit quelque chose sur la frustration accumulée des développeurs face à la verbosité des LLM.

Caveman est un skill/plugin multi-agents qui force le modèle à répondre en style ultra-compressé. Trois niveaux : lite (réponses courtes), full (prose éliminée, structure essentielle), ultra (style télégraphique). Il existe même un mode 文言文 — chinois classique — qui pousse la compression à l’extrême en exploitant la densité sémantique de cette langue.

Le benchmark annoncé : 65% de réduction des output tokens sur des appels API Claude réels. Une étude de mars 2026 ajoute un angle contre-intuitif : forcer la brièveté améliore la précision de 26 points sur certains benchmarks. La verbosité ne serait pas un proxy de la qualité du raisonnement — parfois elle le masque.

La verbosité des LLM est un artefact d’entraînement, pas une nécessité. Les modèles ont été entraînés à produire des réponses longues et structurées parce que les annotateurs humains évaluaient favorablement les réponses exhaustives. En production dans un agent, cet héritage devient un défaut : chaque réponse verbeuse est du contexte consommé pour la suite. Caveman force le modèle à désapprendre cette habitude.

Caveman inclut aussi un middleware MCP (caveman-shrink) qui comprime les descriptions des outils MCP — un angle souvent négligé, alors que les descriptions d’outils peuvent représenter plusieurs milliers de tokens fixes à chaque appel. Compatible avec 30+ agents, installation en one-liner.

→ github.com/juliusbrussee/caveman

La question qui fâche

Vers où va ce bras de fer ?

La réponse honnête : le volume de données générées par un agent en session intensive explose plus vite que les windows grandissent. Passer de 200k à 1M tokens ne règle rien si la session génère 800k tokens de logs, stack traces et réponses verbeuses en deux heures.

Et puis il y a la latence. Un contexte de 800k tokens, même si le modèle le supporte techniquement, a un coût en temps de traitement à chaque inférence. Ce n’est pas seulement une question d’argent ou de qualité de raisonnement. C’est aussi une question de fluidité d’utilisation.

Il y a un troisième angle qu’on mentionne rarement dans les discussions techniques : le CO2. Chaque inférence consomme de l’énergie. Un agent qui traite 800k tokens à chaque tour, des dizaines de fois par heure, a une empreinte carbone réelle. Chaque développeur qui déploie des agents en production peut réduire ça concrètement, sans attendre que les datacenters tournent au renouvelable. Moins de tokens, c’est moins de calcul, c’est moins d’énergie.

Ces outils vont-ils migrer côté modèle ou rester côté infra ? On peut imaginer des modèles qui gèrent nativement la compression de leur contexte, qui savent distinguer signal et bruit dans leurs propres historiques. Certaines architectures expérimentales vont dans ce sens. Pour l’instant, l’outillage externe reste nécessaire. RTK, DCP, Caveman sont trois réponses opérationnelles à un problème que les fournisseurs de modèles n’ont pas encore résolu.