RTK + Caveman Mode :
réduire les tokens Claude Code
de 50% en mission

Utiliser Claude Code en mission enterprise, c'est consommer des tokens à un rythme soutenu. Une session de travail intensive — feature complète, code review, debugging — peut atteindre 200 000 à 400 000 tokens d'entrée/sortie. À l'échelle d'un mois, la facture devient un sujet. Depuis 6 mois, j'utilise deux techniques complémentaires qui ont divisé ma consommation par presque deux sans réduire la qualité du travail produit : RTK et Caveman Mode.

Le problème : les tokens, c'est de l'argent

Claude Code mesure la consommation en tokens d'entrée et de sortie. Les tokens d'entrée incluent tout le contexte de la session : fichiers lus, historique de conversation, sorties des outils, contenu des fichiers de configuration. Les tokens de sortie sont les réponses de l'IA.

Deux sources de gaspillage dominent dans un workflow de développement classique :

• Les commandes shell non filtrées : Claude Code lit le stdout complet de chaque commande. dotnet test sans flags peut produire 3 000 lignes de sortie — soit ~4 000 tokens de contexte pour informer l'IA que les tests passent. C'est de la pollution contextuelle.
• La verbosité des réponses : sans contrainte, Claude Code répond avec des formules de politesse, des hedges, des répétitions de contexte. Une réponse type fait 500 à 800 tokens. La même information utile en tient 150.

RTK adresse le premier point. Caveman Mode adresse le second.

RTK : un wrapper qui rend les commandes prévisibles

RTK est un wrapper de commandes shell. Toutes les commandes exécutées par Claude Code sont préfixées par rtk :

rtk dotnet build Edenred.Smarter.slnx
rtk dotnet test tests/Application.Tests --no-build
rtk git fetch origin && rtk git checkout -b feat/mbois/LCT-44631 origin/develop
rtk npm install -g uipro-cli

RTK fonctionne comme un proxy transparent : il passe les commandes inconnues sans modification. Pour les commandes connues, il applique des filtres projet-spécifiques configurés en amont.

Ce que RTK fait concrètement

Pour dotnet test, RTK peut appliquer automatiquement :

# Sans RTK — sortie brute, 2000+ lignes
dotnet test → résultat : 3800 tokens de contexte injecté

# Avec RTK — sortie filtrée, erreurs seulement
rtk dotnet test → résultat : 180 tokens de contexte injecté

Pour dotnet build, RTK filtre les avertissements connus (false positifs SonarQube sur les générateurs de code) et ne remonte que les erreurs réelles. Claude Code reçoit un signal propre, pas du bruit.

Pourquoi le préfixe systématique ?

L'intérêt n'est pas seulement technique — c'est aussi comportemental. En configurant dans le CLAUDE.md que toutes les commandes portent le préfixe RTK, Claude Code développe un pattern cohérent. Il ne part pas dans des constructions ad hoc (dotnet test | grep -E "Failed|Error") qui varient selon le contexte et produisent des résultats imprévisibles. Le comportement devient auditable et reproductible d'une session à l'autre.

"La prévisibilité d'une IA dépend de la prévisibilité de son environnement. RTK est une contrainte qui libère — Claude Code sait exactement ce qu'il peut faire avec les commandes, et le fait systématiquement bien."

Configuration dans CLAUDE.md

# RTK
Always prefix shell commands with `rtk`.
It passes through unchanged if no filter exists.
Even in command chains:
  rtk git add . && rtk git commit -m "msg" && rtk git push

C'est tout. Une règle, deux lignes. Claude Code l'applique sur 100% de ses appels shell sans exception.

Caveman Mode : communiquer sans bruit

Caveman Mode est un protocole de communication injecté dans chaque échange via les hooks UserPromptSubmit de Claude Code. Le principe : supprimer tout ce qui ne porte pas d'information.

Ce qui disparaît

Sans Caveman Mode, une réponse type de Claude Code commence par :

Sure! I'd be happy to help you with that. The issue you're experiencing
is likely caused by the fact that the authentication middleware is
checking the token expiry using the wrong comparison operator...

Avec Caveman Mode activé :

Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:

La même information, sans les articles définis, les formules de politesse, les adverbes de remplissage (just, really, basically, actually, simply), le hedging (likely, probably, might be), et les reformulations du contexte que l'utilisateur connaît déjà.

Les niveaux de Caveman Mode

Le mode supporte trois niveaux selon l'intensité souhaitée :

• lite : supprime les politesses et les adverbes de remplissage. Style professionnel direct. Gain : ~20%.
• full : supprime aussi les articles (a/an/the), les hedges et les répétitions de contexte. Fragments acceptés. Gain : ~45%.
• ultra : style télégraphique pur. Une information par ligne. Gain : ~60%. Réservé aux sessions de debugging intense.

Le mode full est le meilleur compromis au quotidien : l'information reste lisible, les économies sont significatives.

Les exceptions automatiques

Caveman Mode intègre une règle d'auto-clarté : il se suspend automatiquement pour :

• Les avertissements de sécurité (actions destructives, push force, suppression de données)
• Les séquences multi-étapes où l'ordre des fragments risque de créer une ambiguïté
• Les questions de l'utilisateur qui indiquent une incompréhension

Après ces passages, le mode reprend automatiquement. Le code, les commits et les PR ne sont jamais affectés — ils sont écrits normalement.

Configuration via les hooks

Le hook s'ajoute dans .claude/settings.json :

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "command": "echo 'CAVEMAN MODE ACTIVE (full). Drop articles/filler/pleasantries/hedging. Fragments OK. Code/commits/security: write normal.'"
      }
    ]
  }
}

Ce hook injecte les instructions de communication dans chaque prompt entrant. Claude Code reçoit la contrainte avant de traiter votre demande, et y répond en conséquence dès le premier token de sa réponse.

"Caveman Mode n'est pas du manque de respect — c'est du respect du temps. La politesse en communication humaine compense l'absence de contexte partagé. Avec un outil qui connaît votre projet, elle ne fait qu'ajouter de la friction."

Mesures concrètes sur 30 jours de mission

Sur ma mission actuelle (plateforme enterprise .NET 10, 8 devs, base de code 180k LOC), voici les chiffres mesurés sur un mois de travail intensif avec Claude Code :

Le gain sur les tokens shell est plus élevé que le gain sur les réponses parce que les sorties de commandes non filtrées sont proportionnellement très coûteuses : une seule exécution de dotnet test sur une solution de 50 projets peut injecter autant de tokens que 20 échanges conversationnels.

Ce que ça change dans la pratique

La réduction de tokens a un effet secondaire souvent sous-estimé : la fenêtre de contexte disponible reste propre plus longtemps. Claude Code peut travailler sur des features plus longues sans atteindre la limite de contexte. Les sessions durent plus longtemps sans dégradation de la cohérence.

Sur ma mission, nous avons mesuré une augmentation de la durée moyenne des sessions de 35 min à 58 min avant le premier signal de compression de contexte. C'est 23 minutes de travail continu supplémentaires par session, sans interruption pour "recharger" le contexte.

Setup complet : 4 étapes

Voici le setup exact que j'utilise, reproductible sur n'importe quel projet .NET avec Claude Code :

Étape 1 — Installer RTK

RTK s'installe comme un outil global sur votre machine de développement. Une fois installé, la commande rtk est disponible dans votre PATH et agit comme proxy pour toutes vos commandes.

Étape 2 — Configurer CLAUDE.md

# RTK
Always prefix shell commands with `rtk`.
It passes through unchanged if no filter exists.
Even in command chains: `rtk git add . && rtk git commit -m "msg"`

# Commandes projet
rtk dotnet build Solution.slnx
rtk dotnet test Solution.slnx --no-build
rtk dotnet format Solution.slnx --verify-no-changes

Étape 3 — Configurer le hook Caveman Mode

// .claude/settings.json
{
  "hooks": {
    "UserPromptSubmit": [
      {
        "command": "echo 'CAVEMAN MODE ACTIVE (full). Drop articles/filler/pleasantries/hedging. Fragments OK. Code/commits/security: write normal.'"
      }
    ]
  }
}

Étape 4 — Ajuster le niveau si nécessaire

Commencez par le niveau full. Si vous trouvez les réponses trop telegraphiques pour les explications architecturales complexes, passez en lite. Si vous faites une session de debugging pur et que vous voulez aller vite, basculez en ultra pour cette session.

// Commandes de contrôle pendant une session
/caveman lite    // moins agressif
/caveman full    // défaut recommandé
/caveman ultra   // debugging intensif
stop caveman     // désactiver complètement
normal mode      // identique à stop caveman

Pièges à éviter

Deux erreurs que j'ai faites en configurant ce setup :

1. Appliquer Caveman Mode aux sorties de revue de code. Le mode full sur une code review génère des findings trop concis — il manque le "pourquoi" derrière chaque suggestion. J'ai ajouté une règle explicite dans CLAUDE.md : les reviews et les analyses de sécurité s'écrivent en mode normal, pas en caveman.

2. Oublier RTK dans les séquences git complexes. Sur les worktrees (plusieurs branches en parallèle), il y a des commandes qui ne passent pas par RTK parce qu'elles sont construites dynamiquement. J'ai ajouté dans CLAUDE.md : even in command chains, pour que Claude Code ne génère jamais de séquence sans le préfixe.

Est-ce applicable hors .NET ?

Oui. RTK est agnostique au langage — c'est un wrapper shell. Il fonctionne aussi bien avec npm test, pytest, cargo build ou go test. Les filtres sont configurables par commande, indépendamment de l'écosystème technique.

Caveman Mode est encore plus universel — il opère sur la couche communication, pas sur le code. Il s'applique à n'importe quel workflow Claude Code, quelle que soit la technologie du projet.

En résumé

Les tokens ne sont pas une ressource infinie. Les optimiser, c'est non seulement réduire les coûts — c'est aussi travailler avec une IA qui reste cohérente plus longtemps, sur des sessions plus denses, avec moins de friction. RTK filtre le bruit côté commandes. Caveman Mode filtre le bruit côté communication. Ensemble, ils définissent un contrat clair entre vous et l'outil : chaque token injecté dans le contexte doit porter de l'information utile.

C'est du Kaizen appliqué à l'IA — améliorer le système, pas seulement l'utiliser.