RTK et Repowise avec Claude Code : le combo qui change vraiment la donne

Claude Code est devenu l'outil par défaut pour beaucoup de devs qui bossent en mode agent. Sauf qu'au bout de quelques semaines d'utilisation intensive, deux problèmes apparaissent toujours : le contexte se remplit trop vite (avec du bruit qui ne sert à rien), et l'agent ne comprend pas vraiment l'architecture du projet sur lequel il travaille.

RTK et Repowise attaquent ces deux problèmes par des angles complètement différents. RTK compresse les sorties de commandes shell avant qu'elles n'arrivent dans le contexte. Repowise indexe ton code en quatre couches d'intelligence (graphe de dépendances, historique git, doc auto-générée, décisions d'architecture) et expose tout ça via MCP.

Ce guide est issu d'une utilisation réelle des deux outils sur un SaaS de taille intermédiaire en production depuis plusieurs mois. Pas de benchmark synthétique, pas de copier-coller de README. Ce qui marche, ce qui coince, et comment les faire travailler ensemble.

Ce qui se passe vraiment dans une session Claude Code "normale"

Avant de parler des outils, il faut comprendre où passent les tokens. Une session Claude Code typique brûle entre 80 000 et 200 000 tokens en quelques heures de boulot sérieux. La fenêtre de contexte est plafonnée à 200K, ce qui paraît énorme jusqu'à ce que tu réalises trois choses.

D'abord, chaque sortie de commande shell entre intégralement dans le contexte. Un cargo test ou un pnpm test qui passe, ce sont 5 000 tokens de "test passed" répétés que l'agent n'a aucun besoin de lire. Un git log non filtré, c'est 3 500 tokens en moyenne d'après les mesures de RTK sur 2 900+ commandes réelles. Multiplié par les dizaines de commandes qu'un agent lance en autonomie, ça finit par coûter cher.

Ensuite, à chaque fois que Claude Code explore un fichier inconnu, il lit le fichier en entier — même s'il n'a besoin que de comprendre une fonction. Sur un projet de taille moyenne, comprendre "comment marche l'authentification" peut nécessiter la lecture de 30 à 50 fichiers, soit facilement 40 000 tokens juste pour répondre à une question d'architecture.

Enfin, le quota n'est pas illimité. Les plans Max d'Anthropic ont des caps hebdomadaires (240 à 480h selon les paliers), avec un reset toutes les 5h. Quand tu touches le mur en plein refactor du vendredi soir, c'est ta soirée qui saute. La pression sur la consommation de tokens n'est pas théorique, elle est concrète.

C'est dans ce contexte que RTK et Repowise prennent leur sens. L'un compresse, l'autre structure. Les deux sont gratuits, open source, et installables en quelques minutes.

RTK — la compression transparente des sorties shell

Ce que c'est, en une phrase

RTK (Rust Token Killer) est un proxy CLI écrit en Rust qui intercepte les commandes shell exécutées par Claude Code, les passe à un filtre adapté à chaque commande, et renvoie une version compressée à l'agent — typiquement 60 à 90 % de tokens en moins.

Le binaire fait moins de 5 Mo, démarre en moins de 10ms, et n'a aucune dépendance runtime.

Comment ça marche concrètement

Le truc malin de RTK, c'est qu'il ne demande pas à Claude Code de changer son comportement. Il installe un hook (rtk-rewrite.sh) qui intercepte les appels au tool Bash et réécrit la commande à la volée. Quand Claude Code lance git status, c'est en réalité rtk git status qui s'exécute. Claude ne voit jamais cette réécriture, il reçoit juste une sortie déjà filtrée.

Le pipeline appliqué à chaque sortie est documenté dans le repo et tient en quatre étapes :

Sortie brute (5 000 tokens)
    ↓ Smart filtering — suppression des codes ANSI, spinners, barres de progression
    ↓ Grouping — consolidation des lignes similaires, écrasement des patterns répétés
    ↓ Deduplication — un seul "test passed" au lieu de 200
    ↓ Truncation — on garde les erreurs et warnings, on tronque le verbeux qui réussit
Sortie filtrée (500-2 000 tokens)

Le principe est élégant dans sa simplicité : Claude n'a pas besoin de lire chaque ligne "test passed", il a juste besoin de savoir combien de tests sont passés et lesquels ont échoué. Cette information tient en deux lignes au lieu de deux pages.

Installation sur un poste de dev

Le chemin court (Linux/macOS/WSL) :

bash

# Installation via le script officiel
curl -sSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | bash

# Vérification
rtk --version  # doit afficher rtk 0.28.2 ou supérieur

# Hook pour Claude Code (par défaut)
rtk init -g

# Redémarrer Claude Code, puis tester
git status  # automatiquement réécrit en rtk git status

Sur Windows pur, le hook auto-rewrite ne fonctionne pas (il a besoin d'un shell Unix). RTK tombe alors en mode injection CLAUDE.md : l'agent reçoit les instructions RTK mais doit appeler les commandes manuellement. Pour une expérience complète sous Windows, WSL est recommandé — c'est le combo Windows + Git Bash + WSL qui tient le mieux sur les sessions Claude Code longues.

Pour vérifier que tout est en place :

bash

rtk init --show       # affiche l'état de l'installation
rtk gain              # affiche les statistiques d'économies de tokens

La commande rtk gain est précieuse parce qu'elle te donne des chiffres concrets sur ton projet, pas des moyennes marketing.

Cas où RTK fait vraiment la différence

D'expérience, voici les commandes où le gain est le plus visible :

• git log et git diff sur des branches actives : compression jusqu'à 95 % grâce à la dedup des messages de commit verbeux et au filtrage des diffs binaires

• Test runners (pytest, cargo test, gradle test) : tout ce qui réussit est résumé en compteur, seuls les échecs gardent leur stack trace complète

• Docker logs : suppression des timestamps redondants, regroupement des messages répétés

• pnpm install, npm install : la liste des 800 packages devient un compteur + les warnings réels

• find, grep récursifs : sur un monorepo, le gain peut dépasser 90 %

À l'inverse, RTK n'apporte rien sur les commandes courtes ou ciblées (cat fichier.kt, head -20, wc -l). Et c'est normal : si la sortie fait déjà 50 tokens, il n'y a rien à compresser.

La limite honnête à connaître

RTK n'agit que sur les commandes Bash. Les outils built-in de Claude Code (Read, Grep, Glob) bypassent le hook et arrivent dans le contexte sans filtrage. Si tu veux maximiser les économies, il faut donc préférer les commandes shell explicites quand ça a du sens, et utiliser les built-ins quand l'usage le justifie (par exemple Read sur un fichier précis reste plus propre qu'un cat).

Cette limite n'est pas un bug, c'est une décision d'architecture assumée. Mais elle vaut la peine d'être connue avant de s'attendre à des économies "magiques" sur tous les usages.

Le réglage qui tient sur la durée

Au-delà de l'install par défaut, voici la config Claude Code qui tourne en parallèle de RTK depuis plusieurs semaines :

bash

# settings.json de Claude Code (extrait)
{
  "model": "sonnet",
  "env": {
    "MAX_THINKING_TOKENS": "0",
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50",
    "DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1"
  }
}

Avec CLAUDE_AUTOCOMPACT_PCT_OVERRIDE: 50, l'auto-compact se déclenche plus tôt, ce qui combiné à RTK permet de tenir des sessions de 3 à 4h sans hit le mur du contexte. Sur un projet de taille moyenne, l'auto-compact passe en gros de "toutes les 45 minutes" à "toutes les 2 heures" — gain net pour la cohérence des sessions de refactor.

Repowise — donner à Claude Code un cerveau spatial du codebase

Ce que c'est, en une phrase

Repowise est un moteur d'intelligence de codebase open source qui indexe ton repo en quatre couches (graphe de dépendances, historique git, doc auto-générée, décisions d'architecture) et les expose à Claude Code via MCP avec 7 à 8 outils précis.

L'objectif n'est pas de compresser, c'est de structurer. Plutôt que de laisser Claude Code lire 40 fichiers source pour comprendre une feature, l'agent appelle get_overview() ou get_context() et reçoit une synthèse structurée tirée du graphe réel.

Les quatre couches d'intelligence

1. Le graphe de dépendances. Repowise parse ton code (Python, TypeScript, et d'autres langages selon la version) et construit un graphe NetworkX des relations fichiers/symboles, des appels avec scores de confiance, et des communautés détectées par algorithmes de clustering. C'est ce graphe qui permet à l'agent de répondre à "quelles modifs ce fichier va impacter" sans tout lire.

2. L'historique git. Repowise mine les commits pour extraire les hotspots (fichiers qui changent le plus), les ownership maps (qui touche quoi), et surtout les co-changements cachés — les paires de fichiers qui changent ensemble sans dépendance explicite, signe d'un couplage implicite à risque.

3. La documentation auto-générée. Sur la base du graphe et du git, Repowise génère un wiki complet : architecture overview, module map, entry points, tech stack. Ce wiki est ensuite indexé en embeddings (LanceDB ou pgvector) pour la recherche sémantique.

4. Les décisions d'architecture. C'est la couche la plus intéressante à mon sens. Tu peux enregistrer des décisions ("on a choisi JWT over sessions parce que..."), les linker à des nœuds du graphe, et Repowise track leur fraîcheur au fil des commits. Quand 8 fichiers sur 14 régis par une décision ont été modifiés, la décision est marquée comme "potentiellement obsolète" et remontée à Claude Code via get_why().

Cette dernière couche résout un problème ultra concret : quand un dev senior part, le "pourquoi" du code part avec lui. Garder ces décisions dans le codebase plutôt que dans des Notion morts, c'est un pari pragmatique qui se défend.

Installation et configuration

Repowise s'installe via pip (Python 3.10+) :

bash

pip install repowise

# Initialisation dans le repo
cd /chemin/vers/mon-projet
repowise init

# Mode "graph + git uniquement", sans appels LLM
repowise init --index-only

# Avec exclusions
repowise init -x vendor/ -x node_modules/ -x .next/

À l'init, Repowise propose de configurer le hook post-commit. Accepter, c'est s'assurer que les couches d'intelligence restent en sync avec le code à chaque commit. Un update incrémental typique touche 3 à 10 pages et termine en moins de 30 secondes.

La config se trouve dans .repowise/config.yaml :

yaml

provider: anthropic    # ou openai, ollama, litellm
model: claude-sonnet-4-5
embedding_model: voyage-3

git:
  co_change_commit_limit: 500
  blame_enabled: true

dead_code:
  enabled: true
  safe_to_delete_threshold: 0.7

maintenance:
  cascade_budget: 30                 # max pages régénérées par commit
  background_regen_schedule: "0 2 * * *"

Le mode fully offline mérite d'être souligné : avec provider: ollama et un modèle d'embedding local, ton code ne quitte jamais ta machine. Pour un projet sous NDA ou un code base interne, c'est un argument lourd face aux solutions cloud comme Google CodeWiki.

L'intégration Claude Code via MCP

Après repowise init, deux fichiers sont générés ou mis à jour :

• CLAUDE.md à la racine du projet — contient l'architecture summary, la module map, les hotspot warnings, l'ownership map, les paires de couplage caché, les décisions actives, et les candidats au dead code. Ce fichier est régénéré à chaque repowise update à partir de données réelles, pas via un appel LLM. Génération en moins de 5 secondes.

• La config MCP pour Claude Code, qui expose les 8 outils Repowise : get_overview, get_context, get_hotspots, get_why, search, get_decision_health, et quelques autres selon la version.

Le pattern d'usage typique devient :

Dev : "Pourquoi le module de paiement utilise EventBus en mémoire ?"
Claude Code (interne) : appelle get_why("payments/")
Repowise : retourne la décision "EventBus in-process only" + la liste des fichiers régis
Claude Code (réponse) : "C'est lié à une décision prise il y a 8 mois pour
                        éviter la dépendance Kafka au début. La décision est
                        marquée comme à revoir parce que 8 fichiers sur 14
                        régis par cette décision ont été modifiés depuis."

Comparé à un Claude Code qui lirait payments/processor.ts + payments/eventbus.ts + 5 autres fichiers pour deviner l'intention, le gain en tokens et en pertinence est massif.

Le bench officiel et ce qu'il vaut

Le team Repowise publie un benchmark sur 48 tâches de SWE-QA tirées du repo pallets/flask, avec claude-sonnet-4-6 en bout de chaîne. Le résultat annoncé : 27× moins de tokens par requête, 36 % moins cher, qualité de réponse équivalente au Claude Code baseline.

Sur des bench externes, je serais prudent — un facteur 27× est très projet-dépendant. Mes mesures empiriques (sur une vingtaine de questions d'architecture posées avant/après) donnent plutôt 8× à 12× moins de tokens sur les questions "comment ça marche" et "qu'est-ce qui dépend de quoi". Toujours énorme, mais loin du 27×. Le bench officiel reste une indication directionnelle, pas un chiffre à reprendre tel quel.

RTK vs Repowise — le comparatif honnête

Ils ne résolvent pas le même problème

C'est le point essentiel à comprendre avant tout. Dire "RTK ou Repowise" est une mauvaise question. La bonne formulation, c'est : "qu'est-ce qui consomme tes tokens en ce moment ?".

Quand l'un suffit, quand il faut les deux

RTK seul suffit si tu fais surtout du dev "in-the-small" : tu travailles sur quelques fichiers que tu connais déjà, l'agent compile/teste/commit beaucoup, et tu n'as pas besoin qu'il comprenne l'archi globale. Typiquement : itération sur un module isolé, debug, ajout de features bien cadrés.

Repowise seul a du sens si tu fais surtout du dev "in-the-large" : exploration de codebases volumineux, onboarding sur un nouveau repo, refactor cross-modules, audit de dette technique. Et si tu n'as pas envie d'installer un binaire Rust supplémentaire.

Les deux ensemble, c'est le combo qui fait la différence sur un projet qui combine les deux usages — ce qui est le cas dès qu'on dépasse le solo prototype. RTK compresse les sorties pendant que Claude Code teste/commit/déploie, Repowise structure l'exploration pendant que l'agent réfléchit à l'architecture. Les deux outils n'entrent pas en collision, ils opèrent à des couches différentes du pipeline.

Le coût caché à anticiper

RTK n'a pas de coût caché. Le binaire est petit, le hook est transparent, la maintenance se résume à un cargo install --git de temps en temps pour upgrade.

Repowise a un coût d'install initial — l'indexation d'un repo de taille moyenne prend 30 secondes à 2 minutes selon le nombre de commits à miner. Et surtout, il faut maintenir les décisions d'architecture pour que la couche 4 garde sa valeur. Si tu enregistres trois décisions au début et plus rien pendant six mois, l'outil perd son intérêt principal. C'est un coût humain, pas technique, et il faut l'anticiper.

Retour d'expérience après plusieurs mois d'usage

Le contexte type

Le profil de projet où ces deux outils paient le mieux n'est pas la startup à 50 devs avec un monorepo Go de 2 000 fichiers. C'est plutôt le profil dev solo ou petite équipe sur un SaaS de taille intermédiaire — quelques centaines de fichiers code, un backend, un frontend, une base de données, une CI maison. Assez gros pour que les questions d'archi commencent à coûter cher en tokens, assez petit pour qu'il n'y ait pas d'équipe DevX dédiée à optimiser ça.

L'usage typique de Claude Code dans ce contexte, c'est plusieurs sessions en parallèle dans des IDE différents, avec des sessions séparées par feature ou bugfix — pratique recommandée pour éviter les cross-contaminations de contexte. C'est sur ce pattern que les optimisations RTK + Repowise ont le plus d'impact mesurable.

Ce que RTK a changé concrètement

Le gain le plus net est sur les sessions de CI debugging. Quand un pipeline CI échoue, on colle souvent le log à Claude Code pour qu'il diagnostique. Sans RTK, un log de pipeline complet faisait régulièrement 8 000 à 12 000 tokens. Avec RTK actif (en passant le log via cat fichier.log | rtk passthrough ou en relançant la commande localement avec le wrapper rtk), le même log descend à 1 200-2 500 tokens. Facteur 5 à 8 sur un usage récurrent.

Sur les sessions de tests, le gain est plus modeste mais constant : autour de 70 % en moyenne, parce que la majorité de la sortie est composée de "test passed" répétés que RTK collapse efficacement.

L'effet secondaire que je n'avais pas anticipé : la qualité des réponses de Claude s'améliore aussi sur les sessions longues. Avec moins de bruit dans le contexte, l'agent se concentre mieux. Subjectif, mais reproductible — nettement moins de "Claude relit un fichier qu'il a déjà lu il y a 10 minutes" depuis que RTK est installé.

Ce que Repowise a apporté

L'usage le plus marquant arrive sur les refactors qui touchent un module central et son réseau de dépendances. Typiquement : une table partagée par plusieurs endpoints, ou une couche métier appelée depuis des points d'entrée hétérogènes. Sans outil d'introspection, la première étape de ce genre de refactor c'est toujours la même — demander à l'agent "fais l'inventaire de tout ce qui dépend de X", regarder l'agent lire 30+ fichiers, recevoir une liste partielle, et se rendre compte deux jours plus tard qu'il manquait des appels indirects.

Avec Repowise, un appel à get_context("module_cible") retourne en quelques secondes : la liste des fichiers qui touchent ce module, le hotspot score (élevé = fichier instable, faible = fichier stable), les co-changements cachés (les modules qui bougent souvent en même temps, signe d'un couplage implicite), et l'ownership. C'est exactement le type de scan que tu fais mentalement quand tu connais bien un projet, sauf que là c'est tiré du graphe et de l'historique git réels.

Le wiki auto-généré sert aussi à autre chose qu'à alimenter l'agent : c'est une base solide pour documenter ton archi à l'extérieur (articles techniques, onboarding d'un freelance ponctuel, README de release). Au lieu de réécrire la section "architecture" depuis zéro, tu pars de la module map et tu y ajoutes du contexte humain.

Côté décisions d'architecture, j'ai commencé léger — trois décisions structurantes au début, du type "tel choix d'ORM plutôt qu'un autre", "telle stratégie de migration", "tel découpage de pipelines". Le payoff arrive quand l'agent revient avec "pourquoi pas X ici" trois mois plus tard et qu'il a la réponse sans que tu aies à la retaper. Le coût de discipline est faible si tu enregistres au fil de l'eau, brutal si tu essayes de tout rattraper d'un coup six mois après.

Là où ça a coincé

Honnêteté oblige, deux frictions notables.

D'abord, Repowise sous Windows + Git Bash a demandé un peu de bidouille pour faire fonctionner les hooks post-commit. Le repowise watch fonctionne bien, mais le hook git nécessite un environnement Unix-like complet — j'ai fini par le faire tourner uniquement depuis WSL, ce qui suffit pour mon workflow mais reste un point d'accroc.

Ensuite, RTK n'agit pas sur les outils MCP. Quand Claude Code appelle Repowise via MCP, la sortie de get_context() arrive dans le contexte sans passer par RTK. Heureusement, Repowise renvoie déjà du contenu structuré et compact, donc le problème est marginal — mais c'est une zone d'optimisation qui reste ouverte. Pour info, RTK ne couvre que les Bash tool calls, c'est une limite assumée et documentée.

L'ordre dans lequel adopter ces outils

Si tu pars de zéro, voici l'ordre que je recommanderais après plusieurs mois d'usage. C'est la séquence qui a marché pour moi, pas une vérité absolue.

Étape 1 — Mesurer avant tout. Installer ccusage ou équivalent et passer une semaine d'usage normal pour avoir une baseline de consommation. Sans baseline, les gains affichés par RTK ou Repowise sont invérifiables. Cette étape paraît bureaucratique mais elle évite de s'auto-convaincre que ça marche alors qu'on a juste eu une semaine plus calme.

Étape 2 — Installer RTK. C'est l'outil avec le meilleur ratio effort/gain immédiat. 5 minutes d'install, gain mesurable en quelques jours, zéro maintenance. Si tu hésites entre les deux, commence par celui-là.

Étape 3 — Installer Repowise sur tes deux ou trois repos principaux. Pas besoin de l'installer partout d'un coup. Choisis le repo où tu passes le plus de temps en mode "exploration" plutôt qu'en mode "édition rapide". Le ROI sera plus visible.

Étape 4 — Enregistrer les premières décisions d'architecture. Trois à cinq décisions structurantes suffisent au début. C'est la couche qui prend le plus de discipline à maintenir, mais qui paye le plus à long terme. Ne laisse pas vide.

Étape 5 — Mesurer à nouveau. Comparer la consommation après 2-3 semaines d'usage des deux outils. Sur un projet typique, attendre une réduction de 40 à 60 % de la consommation totale, avec un effet plus prononcé sur les sessions longues que sur les sessions courtes.

Conclusion : deux outils, deux couches, un seul objectif

RTK et Repowise sont les deux outils qui ont eu l'impact le plus mesurable sur ma productivité avec Claude Code, devant tous les autres "Claude Code optimizers" testés ces derniers mois. Pas parce qu'ils sont magiques, mais parce qu'ils attaquent le problème à des niveaux différents et complémentaires : compression des sorties pour l'un, structuration du contexte pour l'autre.

Le piège classique avec les outils d'optimisation, c'est d'empiler des solutions qui se chevauchent. RTK et Repowise n'ont aucune surface de chevauchement — ils sont littéralement à des couches différentes du pipeline. Ce qui en fait, à mon sens, le combo de base à installer dès qu'on dépasse l'usage solo occasionnel de Claude Code.

Pour ceux qui hésiteraient encore : les deux outils sont gratuits, open source, et installables en moins de 30 minutes au total. Le coût d'essai est ridicule comparé au gain potentiel. La seule vraie raison de ne pas les essayer, c'est de ne pas avoir de problème de consommation de tokens — ce qui, à l'usage intensif de Claude Code, finit toujours par arriver.

FAQ

RTK fonctionne-t-il avec d'autres agents que Claude Code ?

Oui. RTK supporte officiellement Claude Code, GitHub Copilot, Cursor, Windsurf, Cline, Roo Code, Kilo Code, Gemini CLI, Codex (OpenAI), Antigravity, et OpenCode. Les flags d'installation diffèrent (rtk init -g --gemini, rtk init --agent cursor, etc.), mais le fonctionnement de base est identique.

Repowise envoie-t-il mon code à un service externe ?

Pas obligatoirement. Avec provider: ollama et un modèle d'embedding local, Repowise tourne en 100 % offline. Si tu utilises provider: anthropic ou openai, alors oui, le contenu utilisé pour générer le wiki transite par l'API du provider configuré. Le graphe de dépendances et l'historique git, eux, sont toujours calculés localement.

Combien de tokens RTK fait-il économiser concrètement ?

D'après les chiffres publiés par le projet (mesurés sur 2 900+ commandes réelles), la moyenne est de 89 % de compression. Sur mon projet, je mesure plutôt 70 à 85 % selon les commandes. La commande rtk gain te donnera des chiffres précis sur ton propre usage après quelques jours d'utilisation — c'est la seule mesure qui compte vraiment.

Repowise remplace-t-il une vraie documentation ?

Non. Repowise génère un wiki structurel (architecture, modules, dépendances) à partir du code, mais il ne remplace pas la documentation orientée utilisateur, les ADRs détaillés, ou les guides d'usage. Il enlève la doc "qui décrit le code" — celle qui devient obsolète dès qu'un dev oublie de la mettre à jour. Il ne remplace pas la doc "qui explique les intentions et les usages".

Y a-t-il un risque de conflit entre RTK et Repowise ?

Aucun, à ma connaissance. Les deux outils opèrent sur des canaux différents (Bash tool pour RTK, MCP pour Repowise) et ne partagent aucune dépendance. Tu peux les installer dans n'importe quel ordre sans souci d'interférence.

Quel est le meilleur entre les deux si je dois choisir ?

Si ton usage de Claude Code est dominé par les commandes shell (test, build, git, docker), commence par RTK. Si ton usage est dominé par l'exploration et la compréhension de code (refactor, onboarding, audit), commence par Repowise. Pour un usage mixte (cas le plus courant), les deux ensemble valent largement la somme de leurs parties.

Les deux outils fonctionnent-ils sous Windows ?

RTK fonctionne en mode dégradé sous Windows pur (pas de hook auto-rewrite, mais injection CLAUDE.md fonctionnelle). Repowise tourne en Python 3.10+ donc supporte Windows nativement, mais certains hooks git nécessitent un environnement Unix-like. Pour les deux outils, WSL est recommandé pour une expérience complète sous Windows.