6 semaines de RAG — comment j'ai réduit ma consommation de tokens Claude de 70 %

Au bout de deux semaines de développement, mes sessions Claude commençaient à coûter cher.

Pas en euros — je suis sur un abonnement Max. En débit. Mon orchestrateur /mutant chargeait 40 000 tokens de contexte à chaque requête. Mes 55 hooks PostToolUse injectaient du contexte supplémentaire à chaque appel outil. Et avec 6 à 8 agents en parallèle, j'atteignais les limites de rate limit Anthropic avant même d'avoir fini ma matinée de dev.

J'ai commencé à auditer. Ce que j'ai trouvé m'a obligé à repenser entièrement comment j'organisais les instructions de mes agents.

Six semaines plus tard, je tourne à 10 000 tokens par appel en moyenne. Le contexte fixe par prompt est passé de 39 000 à 11 700 tokens — soit une réduction de 70 %. Le taux de gaspillage outil est tombé de 17-19 % à 5,7 %.

Voici ce qui a vraiment fonctionné.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le premier problème : tout charger à chaque prompt

Mon infrastructure Claude Code s'est développée progressivement. Au départ, j'avais un fichier CLAUDE.md de projet avec les instructions de l'agent. Puis un deuxième. Puis des fichiers de règles (token-budget.md, agent-behavior.md, coding-patterns.md). Chaque fichier ajoutait 1 000 à 5 000 tokens au contexte permanent — le contenu chargé à chaque prompt, quel que soit le sujet de la conversation.

Quand j'ai fait l'audit, j'ai trouvé :
- 11 fichiers CLAUDE.md projets : 24 292 tokens chargés en permanence
- 3 fichiers de règles globaux : 14 399 tokens supplémentaires
- Total contexte fixe : ~39 000 tokens par prompt

La solution était contre-intuitive. Ces fichiers contiennent des instructions précieuses — ne pas les supprimer. Les migrer dans le RAG.

Le principe : le CLAUDE.md ne contient plus que le rôle (2-3 lignes) et une requête SQL pour charger les instructions complètes à la demande depuis rag_agent_instructions. Le fichier slim passe de 10 Ko à 400 octets. Les sections détaillées ne sont chargées que quand l'agent en a besoin.

Résultat après migration :
| Catégorie | Avant | Après | Gain |
|-----------|-------|-------|------|
| CLAUDE.md projets (11 fichiers) | 24 292 t | 4 540 t | −81 % |
| Rules files (3 fichiers) | 14 399 t | 6 628 t | −54 % |
| Total contexte fixe/prompt | ~39 000 t | ~11 700 t | −70 % |

Ce gain est permanent. Il s'applique à chaque prompt de chaque session, pas seulement aux cas particuliers.

Le prompt caching : la victoire invisible

Anthropic propose un système de cache côté serveur avec un TTL de 5 minutes. Un token en cache coûte 0,10× le prix standard. Un token créant un cache coûte 1,25×. L'économie sur un cache hit est donc de ×12,5 par rapport à une création.

Claude Code applique automatiquement cache_control au system prompt — c'est déjà en place sans configuration. Mais j'ai découvert deux angles non exploités.

Le premier : le warm-cache au démarrage. Avant ma première requête de la journée, un hook SessionStart pré-réchauffe les 5 agents les plus utilisés. Sans ça, le premier prompt crée le cache (×1,25) et c'est seulement à partir du deuxième qu'on commence à économiser. Avec le warm-cache, le premier prompt est déjà un cache hit (×0,10).

Le deuxième : la règle /clear cache-safe. /clear réinitialise l'historique de conversation locale — mais n'invalide pas le cache Anthropic. Le cache serveur persiste pendant 5 minutes. On peut donc utiliser /clear librement pour alléger le contexte local sans perdre les gains de cache. J'évitais /clear par réflexe, craignant de perdre des économies. Cette règle a changé mon utilisation quotidienne.

Un détail souvent ignoré : les tokens en cache_read ne comptent pas dans le calcul ITPM (tokens par minute). Plus vous utilisez le prompt caching, plus votre débit effectif augmente indépendamment de vos limites.

Les règles comportementales : 15 % récupérés dans les interstices

Quand on track les tokens outil par outil, certains patterns sautent aux yeux.

Un audit de 65 380 événements (30 derniers jours, 54,4 M tokens estimés) révèle que 15 % des tokens outils trackés venaient de... echo et sleep.

echo "Step 1: analyzing file..."   # ~25 tokens perdus
sleep 1                            # ~15 tokens perdus, rien accompli
echo "Done."                       # ~10 tokens perdus

Ce sont des habitudes de scripting classiques. Mais dans un hook PostToolUse qui tourne à chaque appel outil — potentiellement 200 fois par session — ça s'accumule.

La règle est simple : ne jamais ajouter echo pour le statut ou le progrès, ne jamais sleep entre des commandes indépendantes. Juste exécuter.

Dans le même registre, le waste breakdown (8 509 événements de gaspillage identifiés) montre :
- 40,6 % : lectures répétées du même fichier déjà en contexte
- 28,7 % : cat au lieu de Read (outil dédié)
- 24,5 % : grep bash au lieu de Grep (outil dédié)

Ces trois patterns représentent 94 % du gaspillage. Des hooks read-guard et tool-redirect bloquent maintenant ces anti-patterns à la source.

La délégation Gemini : 60 à 70 % du quota libéré

Mon orchestrateur /mutant décompose les demandes complexes en questions, consulte des agents spécialisés via des "phone calls", puis synthétise. Chaque CALL créait une requête Claude — avec le prompt complet de l'agent (15-20 K tokens), le contexte de session, les instructions.

La solution : router les workers vers Gemini CLI par défaut (GEMINI_WORKERS=true). Les sous-agents d'analyse passent sur gemini-2.5-flash (~15 s, stable). Les raisonnements profonds passent sur gemini-2.5-pro. Seule l'orchestration — le cerveau /mutant lui-même — reste sur Claude.

Économie mesurée : 60 à 70 % du quota Claude économisé sur chaque session /mutant.

J'ai établi trois flux Gemini obligatoires :

Le tracking des appels Gemini est intégré dans la même table que les appels Claude — ce qui permet de mesurer le "Gemini %" hebdomadaire et d'ajuster les seuils.

La discipline des sous-agents

Avec 124 agents actifs dans mon infrastructure, la configuration des sous-agents avait une variance importante. Tâche #137 a documenté ce que j'ai trouvé :

La plupart des agents workers n'avaient aucune raison d'être sur sonnet. Lire un fichier, faire un grep, formater un JSON — haiku fait le travail en moins cher et plus vite. Migrer 27 agents de sonnet vers haiku = −65 % de coût par worker.

L'autre discipline : max_turns OBLIGATOIRE sur chaque Task. Sans ça, un sous-agent peut consommer 25 tours de contexte pour une tâche qui en nécessite 5. La règle : ≤10 tours inline, 11-25 en background uniquement (le background isole le risque d'atteinte à la limite de contexte).

Le résultat : 10 000 tokens par appel

Six semaines après le début de ces optimisations, voici où j'en suis :

• Contexte fixe/prompt : 39 000 t → 11 700 t (−70 %)
• Taux de gaspillage outil : ~18 % → 5,7 %
• Consommation moyenne : de pointes à 930 M tokens input/semaine (semaine du 16 fév) vers une consommation stable et maîtrisée
• Tokens par appel : ~10 000 en moyenne

Ces 10 000 tokens ne signifient pas "peu de contexte". Ça signifie que le contexte est pertinent. Le RAG injecte 2 à 4 000 tokens ciblés par requête (embedding + rerank via bge-m3 + qwen3:4b), au lieu de charger 40 000 tokens d'instructions dont 80 % ne sont pas pertinentes pour la requête courante.

L'insight stratégique

La leçon principale de ces six semaines n'est pas technique — elle est conceptuelle.

Le RAG n'est pas seulement de la mémoire. C'est du contrôle de débit.

Moins de tokens input par requête = plus d'agents parallèles avant d'atteindre la limite TPM d'Anthropic. L'optimisation du contexte fixe a un effet multiplicateur sur toutes les sessions. Chaque token économisé dans un CLAUDE.md slim est économisé ×N fois par jour, ×M agents en parallèle.

La prochaine étape ? Réduire le prompt /mutant lui-même — 53 Ko de prose qui pourrait devenir 8 Ko de pseudocode structuré. Estimation : −70 à −80 % du coût par session d'orchestration. C'est le levier non exploité le plus important qui reste.

Mais pour l'instant, 10 000 tokens par appel en moyenne. C'est un résultat qui me permet de faire tourner 6 à 8 agents en parallèle sans déclencher de rate limit avant midi.

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.

​