10 leviers pour diviser ta facture de tokens par 5 (Copilot, Claude Code, Cursor)
Alexandre
··
Durée de lecture : 16 min
Cliquer pour agrandir
Depuis le 1er juin 2026, GitHub Copilot facture à l'usage. 1 AI Credit = 0,01 $. Un échange avec Claude Opus 4.8 coûte 25 $ par million de tokens de sortie. Le même échange avec Haiku 4.5 coûte 5 $. Facteur x5 sur la même tâche, selon le modèle choisi (GitHub Docs).
Sur AlexWrites et Waku, j'utilise au quotidien un combo de 4 outils pour réduire ma consommation : RTK pour compresser les sorties CLI, codegraph pour donner du contexte structuré au modèle, un CLAUDE.md compact avec des règles proactives (j'en parle ici), et une stratégie de choix de modèle par tâche. J'ai testé Caveman aussi (un skill qui force le modèle à répondre en mode ultra-court, GitHub), mais je ne le recommande pas : la réduction de 60-75 % sur les tokens de sortie se paie par une perte d'information trop importante dans les échanges. Quand le modèle te répond en mode télégraphique, tu perds du contexte critique et tu finis par poser plus de questions pour compenser.
Décryptage.
Le problème : les coûts d'usage explosent (et ce n'est pas près de s'arrêter)
Un token est l'unité de facturation de tous les modèles de langage. Ce n'est pas un mot : c'est un fragment de texte d'environ 4 caractères que l'IA découpe pour traiter le langage. 750 mots correspondent à environ 1 000 tokens. Et chaque token qui entre ou sort de la fenêtre de contexte a un prix.
La fenêtre de contexte d'un LLM (Large Language Model, le modèle de langage qui propulse ton assistant de code), c'est sa mémoire de travail. Elle fait environ 200 000 tokens par défaut, extensible à 1 million sur certains modèles. Mais au-delà de 60 à 70 % de remplissage, la qualité des réponses chute. Le modèle perd le fil, se répète, hallucine. C'est ce que les chercheurs appellent le problème "lost in the middle" (VS Code Blog, juin 2026).
Chaque interaction mobilise deux flux de tokens qui s'additionnent. Les tokens d'entrée, c'est tout ce que tu envoies : ton prompt, les fichiers ouverts, l'historique de conversation, les instructions système. Les tokens de sortie, c'est ce que le modèle génère en retour. Et le piège est là : les tokens de sortie coûtent 4 à 8 fois plus cher que les tokens d'entrée (CIO). Sur Claude Opus 4.8, c'est 5 $ en entrée contre 25 $ en sortie par million de tokens (Anthropic).
Les conséquences sont triples. Le coût augmente avec chaque token superflu envoyé ou généré. La vitesse se dégrade proportionnellement au volume de tokens traités, chaque milliseconde de latence en plus. Et la qualité chute quand la fenêtre de contexte est saturée de données non pertinentes (Anthropic, 2026 Agentic Coding Trends Report).
Modèle
Coût entrée (1M tokens)
Coût sortie (1M tokens)
Ratio sortie/entrée
Usage recommandé
Claude Opus 4.8
5 $
25 $
x5
Architecture, refactoring complexe
Claude Sonnet 4.6
3 $
15 $
x5
Implémentation, debug courant
Claude Haiku 4.5
1 $
5 $
x5
Tests, docs, tâches simples
Gemini 3 Flash
0,60 $
3 $
x5
Lecture, reformulation
Ce changement de modèle tarifaire a pris beaucoup d'équipes de court. William Ogez de Carbon IT a écrit un article complet sur le sujet : "Maîtriser la facturation GitHub Copilot". Il y détaille comment le passage des "premium requests" aux "AI Credits" oblige les entreprises à repenser leur gouvernance IA. Fixer un budget global, définir des profils d'usage par équipe (power users vs profils légers plafonnés), mettre en place des alertes de consommation via le dashboard admin. Côté entreprise, c'est devenu un vrai poste à piloter. Côté dev solo, les mêmes principes s'appliquent, mais les leviers sont différents : c'est la suite de cet article.
Étape 1 : la méthodologie (avant d'installer quoi que ce soit)
Levier 1 : choisir le bon modèle par tâche
Sur une même tâche, l'écart de coût entre un modèle premium et un modèle léger peut atteindre un facteur x9. La stratégie la plus efficace n'est pas de réduire l'usage de l'IA, c'est d'utiliser le modèle adapté à chaque étape du travail. C'est le levier que personne n'utilise et qui rapporte le plus.
Concrètement, ça veut dire utiliser Opus pour écrire la spec ou résoudre un bug multi-fichiers, puis switcher sur Haiku ou Sonnet pour exécuter les tâches une par une. C'est ce que la documentation GitHub appelle la "stratégie hybride" (GitHub Docs). Le modèle premium raisonne et décide. Le modèle léger applique et exécute.
Tâche
Modèle recommandé
Coût sortie
Pourquoi
Spec, architecture, debug complexe
Opus 4.8
25 $/M
Raisonnement profond nécessaire
Implémentation, application de plan
Sonnet 4.6
15 $/M
Bon rapport qualité/coût
Tests unitaires, docs, reformulation
Haiku 4.5
5 $/M
Exécution simple, volume élevé
Lecture de code, résumé
Gemini 3 Flash
3 $/M
Tâches à faible valeur ajoutée
Pour Waku et mes projets, je fais exactement ça avec Claude Code au quotidien. Quand je dois repenser l'architecture d'un module, je lance une session Opus. Quand je dois générer 15 tests unitaires à partir d'une spec déjà écrite, Haiku fait le job en 3 fois moins de tokens. L'écart sur une journée de travail, c'est facilement 40 à 60 % de tokens économisés, sans aucune perte de qualité sur le code produit.
Levier 2 : régler le niveau d'effort. Le niveau d'effort du modèle est le deuxième réflexe qui compte. Claude Code et Copilot permettent de régler l'intensité de raisonnement (low, medium, high, max). Laisser "high" en permanence pousse le modèle à réfléchir plus longtemps et à appeler plus d'outils que nécessaire. Le réglage "medium" suffit pour 80 % des tâches et consomme significativement moins de tokens que "high" ou "max". Mickey Gousset le démontre bien dans sa vidéo (3 900 vues), où il mesure l'impact direct du niveau d'effort sur la consommation.
Levier 3 : écrire avant de coder (spec-driven development)
Le spec-driven development (SDD, une méthode qui consiste à structurer le travail en spec, plan et tâches avant de laisser l'agent coder) réduit les allers-retours coûteux et évite que le modèle ne parte explorer le codebase sans direction claire. Moins d'itérations = moins de tokens gaspillés en exploration inutile.
Le processus tient en 4 étapes. D'abord, tu décris le quoi et le pourquoi dans une spec courte (Specify). Ensuite, tu fournis la direction technique et les contraintes dans un plan (Plan). Puis tu décomposes en tâches courtes et testables (Tasks). Et enfin, tu confies chaque tâche à un modèle adapté, souvent plus léger que celui qui a écrit le plan (Implement). Point important : chaque étape est relue et validée par le dev avant de passer à la suivante.
Comparaison : avec et sans SDD
Sans SDD
Avec SDD
Exploration du codebase
L'agent lit 10-15 fichiers pour comprendre le contexte
L'agent sait exactement quels fichiers toucher
Itérations
3-5 allers-retours de clarification
1 seul passage, la spec est claire
Tokens gaspillés
Relecture du contexte complet à chaque itération
Contexte minimal et ciblé
Modèle utilisé
Opus sur toute la session
Opus pour la spec, Haiku pour l'exécution
Coût estimé par feature
~3-5 $
~1-2 $
Plusieurs frameworks open-source structurent cette approche. BMAD Method (50 700 étoiles GitHub) propose un workflow agile complet avec agents spécialisés, du brief jusqu'à l'implémentation. Spec-Kit est le toolkit officiel GitHub pour le SDD dans Copilot, avec des commandes /speckit.specify, /speckit.plan et /speckit.tasks. Et AI-Driven Dev Community rassemble des outils, prompts et snippets pour les devs qui utilisent l'IA au quotidien.
L'intérêt en termes de tokens est direct. Sans cette structure, l'agent explore sans contrainte, lit des fichiers qui ne servent pas, pose des questions de clarification, revient en arrière. Chaque itération inutile coûte des tokens d'entrée (relecture du contexte complet) et des tokens de sortie (génération abandonnée). Avec le SDD, le modèle sait exactement quoi faire dès le premier prompt. Nate Herk le montre bien (258 000 vues) : structurer ses demandes avant de les envoyer est le hack le plus rentable de tous.
C'est exactement le workflow que j'utilise avec Claude Code sur Waku. Je rédige une spec courte en Opus, je génère le plan, puis j'exécute chaque tâche en Haiku. Le coût par feature a baissé de moitié par rapport à l'approche "je décris mon besoin en vrac et je laisse l'agent se débrouiller".
Étape 2 : les outils de compression
La méthodologie réduit les tokens inutiles en amont. Les outils qui suivent compressent ce qui passe quand même.
Levier 4 : compresser les sorties CLI avec RTK
Cliquer pour agrandir
RTK (Rust Token Killer) est un proxy CLI open-source écrit en Rust qui intercepte les sorties de commandes terminal avant qu'elles n'atteignent la fenêtre de contexte de l'IA. Résultat mesuré : 60 à 90 % de tokens en moins sur les commandes courantes, sans aucune modification du workflow. 71 400 étoiles GitHub en moins de 6 mois (GitHub).
Le problème est simple. Quand Claude Code exécute un git status, un npm test ou un docker ps, la sortie brute contient des centaines de lignes de données répétitives, de headers système et de messages que le modèle ne va jamais utiliser pour résoudre ta tâche. Toutes ces sorties verbeuses atterrissent dans la fenêtre de contexte, occupent de la place, et diluent l'attention du modèle sur ce qui compte vraiment. Sans cadrage, ton agent IA est un stagiaire curieux avec une carte de crédit illimitée qui lit tout le node_modules pour comprendre une lib.
RTK agit comme un filtre intelligent entre ton terminal et l'IA. Le flux est simple : le modèle exécute une commande (git, npm, docker...), RTK intercepte la sortie brute (~2 000 tokens), applique ses filtres, et ne renvoie que l'essentiel (~200 tokens) dans la fenêtre de contexte. Le modèle ne voit jamais la sortie verbeuse.
4 stratégies de compression : filtrage (retrait des données système non essentielles), regroupement (agrégation des éléments similaires), troncature (conservation sélective des segments critiques), déduplication (fusion des lignes répétées avec compteur d'occurrences).
Comparaison avant/après RTK par commande
Commande
Tokens sans RTK
Tokens avec RTK
Réduction
cargo test (suite complète)
~4 500
~360
92 %
git status (repo monorepo)
~1 200
~230
81 %
docker ps (10 containers)
~800
~160
80 %
npm test (Jest, 50 tests)
~3 200
~400
87 %
kubectl get pods
~1 500
~200
87 %
Session 30 min (total)
~118 000
~24 000
80 %
Sources : RTK Benchmarks, Medium. FuturMinds a reproduit ces résultats (25 000 vues) :
curl -fsSL https://rtk-ai.app/install.sh | sh
rtk init --global
Après un redémarrage de VS Code ou de ton terminal, le hook se déclenche automatiquement sur plus de 100 commandes (git, npm, cargo, Docker, Kubernetes, AWS...). Tu peux suivre les gains en temps réel avec rtk gain --graph, et rtk discover analyse ton historique pour trouver les commandes qui pourraient encore être compressées.
RTK ne couvre pas tout. D'autres outils complètent le tableau pour des cas spécifiques :
Attention à ne pas empiler RTK et Snip ensemble : ils interceptent la même catégorie de flux, et le gain combiné n'est pas proportionnel (Sogeti Labs).
Franchement, j'utilise RTK sur tous mes projets depuis avril. Combiné avec le setup CLAUDE.md et les hooks que j'avais mis en place (le détail complet ici), c'est le combo qui m'a fait passer de 6 $/jour à moins de 2 $ en moyenne sur Waku.
Levier 5 : donner du contexte structuré avec codegraph
Cliquer pour agrandir
Codegraph est un serveur MCP (Model Context Protocol, le standard ouvert qui connecte les agents IA à des sources de données externes) qui construit un graphe de connaissances de ton codebase en local. Au lieu de laisser l'agent lire des fichiers entiers pour comprendre le code, il lui fournit du contexte structuré : symboles, imports, call graphs, architecture. Résultat mesuré : environ 35 % de tokens en moins et 70 % d'appels d'outils en moins (DeveloperDigest).
Le problème que codegraph résout est différent de RTK. RTK compresse les sorties de commandes shell. Codegraph compresse le contexte de code lui-même. Quand Claude Code a besoin de comprendre comment une fonction est utilisée dans le projet, sans codegraph il va lire le fichier entier, puis ses imports, puis les fichiers qui l'appellent. Ça peut représenter 10 à 15 fichiers ouverts, des milliers de lignes ingérées. Avec codegraph, il interroge le graphe via l'outil MCP codegraph_context ou codegraph_explore et obtient directement la réponse structurée, sans ingérer le contenu brut.
Comparaison : avec et sans codegraph sur un refactoring multi-fichiers
Sans codegraph
Avec codegraph
Fichiers lus par l'agent
10-15 fichiers complets
3-4 fichiers ciblés
Appels d'outils (read, grep)
~25 appels
~8 appels
Tokens consommés
~45 000
~29 000
Réduction
baseline
~35 %
Précision de la réponse
Se perd dans le contexte
Trouve la bonne réponse du premier coup
L'outil est développé par Colby McHenry, distribué en npm sous @colbymchenry/codegraph, et fonctionne entièrement en local avec tree-sitter (un parseur de code universel) pour le parsing et SQLite + FTS5 pour l'indexation. Il est compatible avec Claude Code, Cursor, Codex et tout client MCP (BigHatGroup).
Je viens de l'installer sur le monorepo d'AlexWrites, là où j'écris ces lignes. C'est assez bluffant. Sur les tâches de refactoring multi-fichiers, là où l'agent devait habituellement lire une dizaine de fichiers pour comprendre les dépendances, il en lit 3 ou 4 et trouve la bonne réponse du premier coup. L'économie de tokens est réelle, mais ce qui m'a le plus convaincu c'est la précision : le modèle ne se perd plus dans des milliers de lignes de contexte non pertinent.
Codegraph vs AGENTS.md : pourquoi le graphe gagne
AGENTS.md / copilot-instructions.md
Codegraph
Mise à jour
Manuelle (tu dois penser à le faire)
Automatique (file watcher, 2s de délai)
Couverture
Ce que tu as pensé à documenter
Tout le codebase indexé
Risque de péremption
Élevé après chaque refactoring
Nul (re-indexation en continu)
Coût en tokens par session
Fixe (chargé à chaque session)
À la demande (interrogé quand nécessaire)
Info obsolète =
Modèle qui suit des instructions fausses
Impossible (le graphe reflète le code réel)
Selon moi, codegraph est plus puissant qu'un AGENTS.md bien rédigé, et pour une raison simple : un fichier de documentation de projet, tu dois le maintenir à la main. Chaque refactoring, chaque nouveau module, chaque renommage de fonction peut le rendre obsolète. Et un AGENTS.md périmé, c'est pire que pas de AGENTS.md du tout, parce que le modèle va suivre des instructions qui ne correspondent plus au code réel. Codegraph, lui, se met à jour automatiquement. Son file watcher natif (FSEvents/inotify) surveille les changements de fichiers et re-indexe en continu avec un debounce de 2 secondes (GitHub). Tu modifies une fonction, le graphe est à jour 2 secondes plus tard. Zéro maintenance manuelle (Sourcegraph).
Étape 3 : cache, sous-agents et contexte ciblé
Le cache de prompt (un mécanisme qui réutilise les portions de contexte identiques d'un appel à l'autre au lieu de les refacturer plein tarif) est le levier le plus silencieux et le plus puissant. Garder un contexte stable et compact en tête de conversation permet d'atteindre des taux de cache de 90 à 97 %, ce qui réduit la facture de tokens d'entrée de façon massive.
Le principe est simple. À chaque échange, l'agent renvoie tout l'historique au modèle. Si le début de cet historique ne change pas d'un tour à l'autre (instructions système, CLAUDE.md, fichiers de règles), ces tokens sont facturés à tarif réduit. D'où l'importance de garder ces fichiers de configuration stables et compacts. Au-delà de quelques centaines de lignes, l'utilité marginale de ton CLAUDE.md ou de ton AGENTS.md chute, mais le coût reste là à chaque session. Sur mon setup, j'atteins un taux de cache de 96,80 % sur Claude Opus 4.8 : 27 467 tokens réutilisés sur 28 375, seulement 908 tokens non cachés (VS Code Blog).
Levier
Ce que ça change
Impact estimé
#6 CLAUDE.md compact et stable
Maximise le taux de cache de prompt
90-97 % de cache sur les tokens d'entrée
#7 Nouveau chat à chaque feature
Évite le contexte parasite accumulé
-20 à 30 % de tokens par session
#8 Sous-agents pour la recherche
Résumé ciblé au lieu du contexte brut complet
-40 à 60 % sur les tâches de lecture
#9 MCP sélectif (désactiver les inutiles)
Moins de descriptions d'outils dans le contexte
-5 à 15 % de tokens système
#10 Contexte ciblé ("ce fichier" vs "tout le dépôt")
L'agent ne lit que ce qui sert
Facteur x5 à x10 sur les tâches ciblées
Levier 7 : nouveau chat à chaque feature. Garder un contexte devenu hors-sujet coûte plus cher que le cache ne fait économiser. Chaque nouvelle tâche mérite une fenêtre propre.
Levier 8 : sous-agents pour la recherche. Les sous-agents travaillent dans leur propre fenêtre de contexte et remontent un résumé ciblé au lieu du contexte brut complet. C'est le pattern que je décris dans mon article sur l'architecture des agents : un agent léger lit et analyse, le modèle premium synthétise et décide.
Levier 9 : MCP sélectif. Chaque serveur MCP chargé ajoute ses descriptions d'outils dans le contexte. Si tu ne fais pas de revue de qualité, désactive SonarQube. Si tu ne touches pas à la base de données, désactive le MCP PostgreSQL. Moins de MCP actifs = moins de tokens système à chaque tour.
Levier 10 : contexte ciblé plutôt que scope large. Fournir directement le bon fichier, la bonne classe ou la bonne fonction. Ne jamais laisser l'agent explorer tout le dépôt sans contrainte. C'est la différence entre "regarde ce fichier" et "cherche dans tout le projet", et l'écart en tokens peut facilement atteindre un facteur x10. RoadsideCoder le démontre (2 700 vues) avec des mesures avant/après sur Claude Code et Cursor :
1. Le coût de l'IA est devenu un poste à piloter, pas juste un abonnement
Avec la facturation à l'usage, chaque session a un coût variable. Comme pour l'hébergement cloud, la bonne pratique c'est de mesurer (avec /cost sur Claude Code, rtk gain sur RTK), de fixer un budget quotidien, et d'optimiser les postes les plus gourmands en premier. D'après Anthropic, la moyenne constatée est de 6 $/dev/jour, avec 90 % des utilisateurs sous les 12 $/jour. Si tu es systématiquement au-dessus, les sections précédentes sont pour toi.
2. La vraie économie vient du cadrage, pas de la restriction
Ne pas utiliser l'IA pour économiser des tokens, c'est comme ne pas conduire pour économiser de l'essence. Le levier, c'est de mieux cadrer : bon modèle, bonne structure de prompt, bon niveau de contexte. Mes sessions sur Waku sont plus productives depuis que j'ai mis en place ces 10 leviers, pas moins productives. Le code produit est meilleur parce que le modèle se concentre sur les bons fichiers au lieu de se noyer dans du contexte inutile.
3. Les outils de compression ne sont plus optionnels
RTK à 71 000 étoiles en 6 mois, codegraph en MCP natif, le cache explorer de VS Code : l'écosystème d'optimisation de tokens est en train de devenir un standard. Ne pas les utiliser, c'est accepter de payer 3 à 5 fois plus cher pour le même résultat.
Conclusion : l'IA la plus efficace, c'est celle qui ne lit que ce qui compte
Dix leviers, un seul principe. La bonne question n'est pas "comment dépenser moins de tokens". C'est "comment donner les bons tokens au bon moment". Un modèle qui reçoit exactement le contexte dont il a besoin répond plus vite, plus juste, et pour moins cher. Un modèle noyé sous des milliers de lignes de logs, de fichiers non pertinents et d'historique périmé va produire du code médiocre, lentement, à prix fort.
Ces outils sont encore jeunes. RTK a 6 mois, codegraph en est à sa version 1.1.0, BMAD Method évolue vite. Les chiffres que je donne dans cet article viennent de mes mesures et de sources publiques, mais ton contexte (taille de projet, stack, fréquence d'usage) va donner des résultats différents. Le meilleur conseil que je puisse te donner, c'est d'installer RTK et codegraph, de mesurer tes gains avec rtk gain et /cost, et de te faire ton propre avis. Les chiffres comptent, mais c'est ton ressenti sur la qualité des réponses qui doit guider tes choix.
La vraie optimisation, ce n'est pas de moins utiliser l'IA. C'est de lui donner exactement ce dont elle a besoin, rien de plus.
Et toi, tu as mesuré ta consommation de tokens ? Tu utilises RTK ou codegraph ? Dis-le moi sur X, LinkedIn ou en commentaire.
Alex
À retenir
Choisir le bon modèle par tâche (Opus pour la spec, Haiku pour l'exécution) réduit la facture de 40 à 60 % sans perte de qualité
RTK compresse les sorties CLI de 60 à 90 % automatiquement (71 400 étoiles GitHub), codegraph réduit le contexte de code de 35 % via un graphe structuré en MCP
Le cache de prompt récompense la stabilité : un CLAUDE.md compact et stable peut atteindre 97 % de taux de cache sur les tokens d'entrée
