> ## Content Index
> Fetch the complete content index at: https://www.sfeir.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# FinOps Claude Code : comment optimiser sa consommation de tokens
- URL: https://www.sfeir.dev/ia/finops-claude-code-comment-optimiser-sa-consommation-de-tokens/
- Published: 2026-02-18T11:17:24.000Z
- Updated: 2026-02-18T11:17:24.000Z
- Description: Claude Code coûte en moyenne 6 $ par jour et par développeur. Avec quelques ajustements sur votre CLAUDE.md, vos skills et vos hooks, vous pouvez réduire significativement cette facture. Voici comment.
- Author: Thomas GRUSON
- Tags: IA, DevOps, FinOps, claude code, Productivité

## Le **context engineering*

## Introduction

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#introduction)

*Claude Code*, c'est l'outil qui a changé ma façon de coder. J'ai commencé avec un abonnement Pro... et j'ai très vite été limité ! Quand j'ai fait le calcul de la projection de ma consommation, j'ai réalisé que même avec un abonnement max x5 ou x10 ça ne suffirait peut-être pas.

Le coût moyen rapporté par Anthropic, c'est **6 $ par développeur par jour** avec Sonnet 4.6, et 90% des utilisateurs restent sous les 12 $/jour. En usage équipe, ça représente **100 à 200 $ par développeur par mois**. Et avec Opus ? On monte encore plus vite.

Le **problème**, ce **n'est pas le prix** du token en soi. C'est qu'**on en gaspille** une bonne partie sans **s'en rendre compte**. Un CLAUDE.md trop long, des serveurs MCP inutilisés, des sessions qui traînent, des prompts vagues qui déclenchent des explorations infinies... Chaque token gaspillé, c'est du budget en moins pour les tâches qui comptent.

Ce qu'on appelle aujourd'hui le **context engineering** — l'art de contrôler ce qui entre dans la fenêtre de contexte d'un LLM — est un enjeu universel. *Cursor* a ses règles conditionnelles `.mdc`, *Aider* propose 3 niveaux de configuration et un repo map, *Codex CLI* a son `AGENTS.md`, *Gemini CLI* son `GEMINI.md` avec hooks, *GitHub Copilot* ses multipliers de requêtes premium, *Kiro CLI* ses specs. Les mécanismes diffèrent, mais **le problème** est le même : **maîtriser ce que l'agent voit** pour maîtriser ce qu'il coûte.

Cet article se concentre sur *Claude Code*, mais les stratégies sont transposables à n'importe quel outil de coding assisté par IA. Voici ce qu'on va couvrir :

1. **Comprendre** ce qui consomme des tokens (et où se cachent les coûts)
2. **Optimiser** votre CLAUDE.md et vos skills
3. **Organiser** vos configurations par projet et maîtriser vos MCP
4. **Automatiser** avec les hooks notamment pour éviter les gaspillages récurrents
5. **Adopter** les bons réflexes au quotidien

![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/02/finops-tokens-claude-code_diagram-repartition-tokens.png)

## Étape 1 : Comprendre

## Comment Claude Code consomme vos tokens

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#comment-claude-code-consomme-vos-tokens)

Avant d'optimiser, il faut comprendre la mécanique. Chaque message que vous envoyez à *Claude Code* ne se limite pas à votre question : il embarque tout un contexte.

### Anatomie d'une requête

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#anatomie-dune-requ%C3%AAte)

À chaque tour de conversation, voici ce qui est envoyé à l'API :

1. **Le system prompt** : les instructions internes de Claude Code (\~quelques milliers de tokens)
2. **Votre CLAUDE.md** : chargé intégralement, à chaque message
3. **Les descriptions de skills** : noms + descriptions de toutes les skills disponibles
4. **Les définitions d'outils MCP** : chaque serveur MCP actif injecte ses outils dans le contexte
5. **L'historique de conversation** : tout ce qui a été dit depuis le début de la session
6. **Les outputs des outils** : le contenu des fichiers lus, les résultats de commandes, les réponses MCP

Le coût ne vient pas d'un seul de ces éléments, mais de leur accumulation. Et surtout : **ces tokens sont envoyés à chaque message**. Un CLAUDE.md de 1 000 lignes, c'est \~4 000 tokens facturés à chaque interaction, pas une seule fois !

### Le contexte qui grossit

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#le-contexte-qui-grossit)

**Le piège classique** : vous démarrez une session, vous explorez le code, vous lisez des fichiers, vous lancez des commandes... et sans vous en rendre compte, votre fenêtre de contexte se remplit.

Prenons un scénario courant :

- Vous posez une question → Claude lit 5 fichiers pour comprendre le code → **\~10 000 tokens** d'outputs de lecture
- Vous demandez un fix → Claude lance les tests → **\~5 000 tokens** d'output de tests
- Vous demandez une amélioration → Claude lit 3 fichiers supplémentaires → **\~6 000 tokens**

En 3 échanges, vous avez accumulé **\~21 000 tokens de contexte** qui seront renvoyés intégralement au prochain message. Le coût par message augmente au fil de la conversation.

### Les coûts cachés

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#les-co%C3%BBts-cach%C3%A9s)

Certains postes de consommation sont moins visibles :

- **Extended thinking** : activé par défaut avec un budget de **31 999 tokens**. Ces tokens de "réflexion" sont facturés au tarif des tokens de sortie (le plus cher). Pour une tâche simple comme renommer une variable, c'est du gaspillage pur
- **Auto-compaction** : quand le contexte atteint \~95% de la fenêtre, Claude résume automatiquement la conversation. Ce résumé consomme des tokens (entrée et sortie), mais c'est un mal nécessaire
- **Résumés de sessions** : Claude génère des résumés en arrière-plan pour la fonctionnalité `--resume`, coûtant environ **0,04 $ par session**

💡

Utilisez `/cost` (en mode API) ou `/usage` en mode abonnement pour le suivi d'usage, et `/stats` pour vos habitudes d'utilisation (streaks, modèles favoris). Vous pouvez aussi configurer votre status bar pour afficher le contexte utilisé en continu.

### Les prix en un coup **d’œil**

| Modèle                 | Input (par M tokens) | Output (par M tokens) | Usage type                  |
| ---------------------- | -------------------- | --------------------- | --------------------------- |
| Haiku 4.5              | 1 $                  | 5 $                   | Sous-agents, tâches simples |
| Sonnet 4.6             | 3 $                  | 15 $                  | Usage quotidien             |
| Sonnet 4.6 (>200K ctx) | 6 $                  | 22,50 $               | Long context                |
| Opus 4.6               | 5 $                  | 25 $                  | Raisonnement complexe       |
| Opus 4.6 (>200K ctx)   | 10 $                 | 37,50 $               | Grosses codebases           |

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#les-prix-en-un-coup-doeil)

⚠️

Les tokens d'****extended thinking** sont facturés au ****tarif output** : Un budget thinking de 32K tokens sur Opus 4.6, c'est 0,80 $ par requête rien que pour la réflexion.

Maintenant que vous avez une idée de la mécanique des tokens et des prix, intéressons-nous à un poste de consommation souvent sous-estimé : les serveurs MCP.

---

## MCP : le mangeur de contexte silencieux

Les serveurs MCP (Model Context Protocol) connectent Claude Code à des services externes : Notion, GitHub, Slack, bases de données... Chaque serveur actif injecte ses **définitions d'outils** dans le contexte. Et ça chiffre vite.

### Le coût réel

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#le-co%C3%BBt-r%C3%A9el)

Chaque serveur MCP ajoute entre **3 000 et 15 000 tokens** de définitions d'outils au contexte, selon le nombre d'outils qu'il expose. Avec 10 serveurs actifs, vous pouvez facilement atteindre **60 000 à 100 000 tokens** de contexte occupé avant même d'avoir tapé un mot.

Sur une fenêtre de 200K tokens (ou 1M en bêta avec Sonnet 4.6), c'est **30 à 50% de votre contexte** consommé par des descriptions d'outils que vous n'utilisez peut-être même pas dans cette session.

### Diagnostiquer avec /context

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#diagnostiquer-avec-context)

La commande `/context` affiche ce qui consomme votre contexte. Lancez-la et regardez la section MCP :

```
> /context

System prompt:      4,200 tokens
CLAUDE.md:            480 tokens
Skill descriptions:   320 tokens
MCP tools:         52,400 tokens  ← le problème est là
Conversation:       8,300 tokens
---
Total:             65,700 tokens

```

💡

Pour info, cet output est volontairement simplifié. En réalité, on trouve également les "System tools" (les outils natifs de Claude Code) représentent \~12k à 17k tokens supplémentaires non négligeables, qui ne sont pas affichés dans cet exemple.

## Étape 2 : Optimiser

## Votre CLAUDE.md vous coûte cher (et vous ne le savez pas)

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#votre-claudemd-vous-co%C3%BBte-cher-et-vous-ne-le-savez-pas)

Le CLAUDE.md, c'est le fichier de mémoire de Claude Code. Il est chargé **intégralement** au début de chaque session, et son contenu est inclus dans **chaque message** envoyé à l'API.

Un CLAUDE.md de 100 lignes bien ciblées ? Pas de problème. Un CLAUDE.md de 800 lignes avec des instructions pour chaque workflow possible ? Vous payez ces 800 lignes à chaque interaction, même quand vous ne faites qu'un simple `git status`.

### Le calcul

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#le-calcul)

Prenons un exemple concret :

- **CLAUDE.md de 200 lignes** (\~800 tokens) : sur 50 messages dans la journée = **40 000 tokens d'input**
- **CLAUDE.md de 800 lignes** (\~3 200 tokens) : sur 50 messages = **160 000 tokens d'input**

La différence : **120 000 tokens par jour**, soit environ **0,36 $ de plus par jour avec Sonnet 4.6**. Ça paraît peu, mais sur un mois de travail (20 jours), c'est **7,20 $** de gaspillage. Et avec Opus, on double.

### Ce qui doit rester dans le CLAUDE.md

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#ce-qui-doit-rester-dans-le-claudemd)

La règle d'or d'Anthropic : **gardez votre CLAUDE.md sous \~500 lignes**. Pour chaque ligne, posez-vous la question : *"Est-ce que Claude ferait une erreur sans cette instruction ?"* Si la réponse est non, supprimez-la.

Ce qui doit rester :

- Les commandes bash que Claude ne peut pas deviner (`bun test` au lieu de `npm test`)
- Les conventions de code qui diffèrent des standards du langage
- Les instructions de test et le runner préféré
- Les conventions Git (nommage de branches, format des commits)
- Les décisions d'architecture spécifiques au projet
- Les variables d'environnement et quirks du setup dev

Ce qui doit **partir** :

- Les instructions détaillées pour des workflows spécifiques (PR reviews, migrations DB, déploiements)
- La documentation d'API (mettez un lien plutôt)
- Les descriptions fichier par fichier de la codebase
- Les conventions standard que Claude connaît déjà
- Les tutoriels et explications longues

### Avant / Après

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#avant--apr%C3%A8s)

**Avant** (780 lignes, \~3 100 tokens) :

```markdown
# Projet MonApp

## Architecture
Le projet est structuré en modules...
[200 lignes de description de l'architecture]

## Conventions de code
[100 lignes de conventions]

## Workflow PR
1. Créer une branche feature/xxx
2. Faire les changements
3. Lancer les tests avec bun test
4. Créer la PR avec gh pr create
[80 lignes de détails sur le workflow PR]

## Workflow de déploiement
[120 lignes]

## Workflow de migration DB
[100 lignes]

## Guide de debug
[80 lignes]

## API Reference
[100 lignes]
```

CLAUDE.md

**Après** (120 lignes, \~480 tokens) :

```markdown
# Projet MonApp

## Commandes
- Tests : `bun test`
- Lint : `bun lint`
- Build : `bun run build`
- DB migrations : `bun db:migrate`

## Conventions
- ES modules (import/export), pas de CommonJS
- Nommage de branches : feature/xxx, fix/xxx, refacto/xxx
- Commits conventionnels : feat:, fix:, refacto:, docs:

## Architecture
- Monorepo avec packages/ (api, web, shared)
- API : Hono + Drizzle ORM + PostgreSQL
- Web : Next.js 15 + Tailwind

## Important
- Toujours lancer les tests après une série de changements
- Préférer les tests unitaires isolés pour le dev (pas la suite complète)
```

CLAUDE.md

Les 660 lignes supprimées ? Elles deviennent des **skills** chargées à la demande dans ce que l'on va voir juste après.

---

## Skills : le chargement à la demande qui change tout

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#skills--le-chargement-%C3%A0-la-demande-qui-change-tout)

Les skills sont le mécanisme clé pour garder un CLAUDE.md léger sans perdre en fonctionnalités. Le principe : **progressive disclosure**.

### Comment ça marche

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#comment-%C3%A7a-marche)

Au démarrage d'une session, Claude Code charge uniquement le **nom** et la **description** de chaque skill (le frontmatter YAML). Chaque skill consomme environ **30 à 50 tokens** dans le contexte initial. Le contenu complet de la skill n'est chargé que lorsque Claude décide qu'elle est pertinente, ou quand vous l'invoquez avec `/skill-name`.

Comparaison directe :

| Approche                    | Tokens au démarrage    | Tokens quand utilisé   |
| --------------------------- | ---------------------- | ---------------------- |
| Instructions dans CLAUDE.md | \~3 000 (toujours)     | \~3 000 (toujours)     |
| Skill dédiée                | \~50-100 (description) | \~3 000 (à la demande) |

Sur 50 messages où vous n'utilisez pas ce workflow : **\~150 000 tokens économisés** avec l'approche skill.

### Refactoring concret : du CLAUDE.md vers une skill

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#refactoring-concret--du-claudemd-vers-une-skill)

Prenons les 80 lignes de workflow PR qui étaient dans le CLAUDE.md. On les déplace dans une skill :

```bash
mkdir -p .claude/skills/create-pr
```

`.claude/skills/create-pr/SKILL.md` :

```yaml
---
name: create-pr
description: Crée une PR avec les conventions du projet (branch naming, tests, review checklist)
disable-model-invocation: true
---

## Workflow PR

1. Vérifier que les tests passent : `bun test`
2. Vérifier le lint : `bun lint`
3. Créer la branche si pas encore fait : `feature/xxx` ou `fix/xxx`
4. Commit avec message conventionnel
5. Push et créer la PR avec `gh pr create`

## Checklist PR
- [ ] Tests passent
- [ ] Pas de TODO laissé dans le code
- [ ] Types à jour
- [ ] Documentation mise à jour si API publique modifiée
```

Résultat :

- **Au démarrage** : la skill coûte \~40 tokens (juste le frontmatter)
- **Quand invoquée** (`/create-pr`) : le contenu complet est chargé
- **Quand non utilisée** : zéro impact sur le contexte

😈

Je vous ai menti. Au démarrage, c'est 0 token, la clé : `disable-model-invocation: true`

### Le flag `disable-model-invocation`

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#le-flag-disable-model-invocation)

Par défaut, Claude peut décider seul de charger une skill s'il juge qu'elle est pertinente. C'est pratique pour les skills de type "conventions" ou "référence", mais pour les workflows avec des effets de bord (déploiement, envoi de messages, création de PR), vous voulez garder le contrôle.

`disable-model-invocation: true` empêche Claude de l'invoquer automatiquement et retire sa description du contexte. **Zéro token consommé** tant que vous ne l'invoquez pas vous-même avec `/skill-name`.

| Flag                           | Tokens au démarrage    | Chargement                     |
| ------------------------------ | ---------------------- | ------------------------------ |
| Par défaut                     | \~50-100 (description) | Auto par Claude ou /skill-name |
| disable-model-invocation: true | 0                      | /skill-name uniquement         |

💡

Utilisez `disable-model-invocation: true` pour tous vos workflows d'action (deploy, PR, release). Gardez le comportement par défaut pour les skills de type référence (conventions, patterns, architecture).

### Rules conditionnelles : le juste milieu

Entre le CLAUDE.md (toujours chargé) et les skills (invoquées à la demande), il existe un mécanisme intermédiaire : les **rules** (`.claude/rules/*.md`). Elles permettent de découper vos instructions en fichiers modulaires.

Sans frontmatter `paths:`, une rule est chargée à chaque message, comme le CLAUDE.md. L'intérêt est purement organisationnel. Mais avec `paths:`, elle ne se charge **que quand Claude travaille sur des fichiers qui matchent le pattern glob :** 0 token le reste du temps.

Exemple : des conventions React chargées uniquement sur les fichiers concernés :

```markdown
---
paths:
  - "src/components/**/*.tsx"
  - "src/hooks/**/*.ts"
---
# Conventions React
- Composants fonctionnels uniquement
- Custom hooks dans src/hooks/
- Tests colocalisés : Component.test.tsx

```

Voici le spectre complet des mécanismes de chargement :

| Mécanisme                            | Tokens au démarrage    | Quand chargé                |
| ------------------------------------ | ---------------------- | --------------------------- |
| CLAUDE.md                            | \~800+ (toujours)      | Chaque message              |
| Rule sans paths                      | Idem CLAUDE.md         | Chaque message              |
| **Rule avec paths**                  | **0**                  | **Quand fichier matche**    |
| Skill (auto)                         | \~50-100 (description) | Quand Claude juge pertinent |
| **Skill (disable-model-invocation)** | **0**                  | **/skill-name uniquement**  |

💡 Les rules conditionnelles sont idéales pour les conventions spécifiques à un sous-dossier ou une techno (frontend vs backend, Terraform vs Python). Pour les workflows avec effets de bord, préférez les skills.

### Fichiers de support : charger encore moins

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#fichiers-de-support--charger-encore-moins)

Le CLAUDE.md, les skills ou les rules peuvent inclure des fichiers additionnels. Claude ne les charge que quand il en a besoin. Par exemple :

```
create-pr/
├── SKILL.md              # Instructions principales (~500 tokens)
├── pr-template.md        # Template de body PR (~200 tokens)
└── examples/
    └── good-pr.md        # Exemple de bonne PR (~300 tokens)

```

dans le .claude/skills

Référencez-les dans le SKILL.md pour que Claude sache qu'ils existent :

```markdown
## Ressources
- Template de PR : [pr-template.md](pr-template.md)
- Exemple de bonne PR : [examples/good-pr.md](examples/good-pr.md)
```

Claude chargera le template uniquement quand il crée effectivement une PR. Les 300 tokens de l'exemple ne seront lus que si Claude estime en avoir besoin.

---

## Tool Search : l'optimisation automatique

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#tool-search--loptimisation-automatique)

*Claude Code* détecte automatiquement quand les descriptions d'outils MCP dépassent **10% de la fenêtre de contexte**. Quand ce seuil est franchi, il active le **Tool Search** : les outils sont mis en mode "deferred" et ne sont chargés que quand Claude en a réellement besoin.

D'après les retours d'expérience, le Tool Search peut faire passer la consommation de contexte MCP de **\~134 000 tokens à \~5 000 tokens**, soit une réduction de **85 à 96% selon le nombre d'outils**.

Par défaut, le Tool Search s'active quand les outils dépassent **10%** du contexte. Vous pouvez abaisser ce seuil pour un déclenchement plus agressif par exemple :

```bash
# Abaisser le seuil de 10% (défaut) à 5% du contexte
ENABLE_TOOL_SEARCH=auto:5

```

### Les bons réflexes MCP

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#les-bons-r%C3%A9flexes-mcp)

1. **Désactivez les serveurs inutilisés** : `/mcp` → désactivez ceux dont vous n'avez pas besoin pour la tâche en cours
2. **Préférez les CLI quand c'est possible** : `gh` au lieu d'un MCP GitHub, `aws` au lieu d'un MCP AWS, `gcloud` au lieu d'un MCP GCP. Les CLI n'ajoutent aucun token de définition au contexte
3. **Gardez moins de 80 outils actifs** au total pour maintenir un contexte sain

Avoir 20+ serveurs MCP configurés globalement alors que chaque projet n'en utilise que 3-4, c'est le scénario classique de gaspillage

## Étape 3 : Organiser

## Organiser ses configurations par projet

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#organiser-ses-configurations-par-projet)

Vous avez allégé votre CLAUDE.md, créé des skills... mais où vivent ces configurations ? Claude Code propose plusieurs niveaux de réglages, et les confondre peut ruiner vos efforts d'optimisation.

### La hiérarchie

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#la-hi%C3%A9rarchie-en-un-coup-doeil)

**Deux mécanismes** coexistent, et ils **ne fonctionnent pas pareil** :

**Les settings** (JSON) suivent une logique de **priorité** : le plus spécifique gagne. De la priorité la plus haute à la plus basse : Managed Policy → CLI flags → `.claude/settings.local.json` (projet, non versionné) → `.claude/settings.json` (projet, versionné) → `~/.claude/settings.json` (user). Si vous définissez `model: "opus-4-6"` au niveau projet et `model: "sonnet-4-6"` au niveau user, c'est Opus qui s'applique.

**Les CLAUDE.md** suivent une logique d'**accumulation** : tous les niveaux sont **concaténés** et envoyés à chaque message. Votre `~/.claude/CLAUDE.md` personnel + le CLAUDE.md du projet + celui du sous-dossier, tout s'additionne.

L'implication FinOps est directe : un `~/.claude/CLAUDE.md` user de 300 lignes, c'est \~1 200 tokens ajoutés dans **tous** vos projets, même ceux qui n'en ont pas besoin. Les settings, eux, s'overrident sans accumulation.

**Les MCP, les agents, les skills, les hooks** existent aussi à deux niveaux : `~/.claude.json` (global) et `.mcp.json` (projet). Les serveurs MCP définis globalement sont chargés partout. Ceux définis au niveau projet ne le sont que dans ce projet.

👍

Bonnes pratiques : n'hésitez pas à placer vos configurations au scope projet, plutôt qu'au scope user

💡

Notons qu'en pratique il y a aussi le "niveau" local mais c'est à peu près pareil que le "niveau" projet, la volonté de partage en moins.

### L'impact des plugins sur le contexte

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#limpact-des-plugins-sur-le-contexte)

Les plugins *Claude Code* sont des packages qui peuvent embarquer des MCP servers, des skills, des agents et des hooks. Côté contexte, ce sont les MCP servers des plugins qui pèsent le plus. Par exemple : Playwright injecte **\~20 outils**, Notion **\~10 outils**, chacun avec sa description. C'est une super feature pour partager plus largement des configurations qui sont liées entre-elles (skill, agent, mcp) mais elles amplifient également le problème !

Le piège : si vous activez des plugins au niveau user (`enabledPlugins` dans le `~/.claude/settings.json`), ils se chargent dans **tous** vos projets. Vous faites du Terraform ? Notion, ses skills et ses 20 outils sont quand même là...

👍

La solution : déplacez `enabledPlugins` dans le `.claude/settings.json` de chaque projet. Chaque projet n'active que ce dont il a besoin.

### La stratégie du "projet par thème"

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#la-strat%C3%A9gie-du-projet-par-th%C3%A8me)

Un pattern que j'utilise au quotidien : créer un dossier projet dédié par activité, même quand il n'y a pas de "vrai" code. On a souvent besoin d'un peu de markdown de toute façon (notes, références, drafts), et ça donne un point d'ancrage pour des configurations ciblées.

L'idée : quand vous changez de thème, vous changez de dossier. Chaque dossier a son propre CLAUDE.md, ses propres plugins activés, ses propres MCP, ses propres skills, ses propres agents. Zéro pollution croisée.

| Projet         | CLAUDE.md                       | Plugins actifs   | Ce qu'on évite     |
| -------------- | ------------------------------- | ---------------- | ------------------ |
| api-backend/   | Conventions Hono + Drizzle      | GitHub           | Playwright, Notion |
| articles/      | Style guide, workflow rédaction | context7, Notion | GitHub, Playwright |
| infra-gcp/     | Conventions Terraform           | GCP, GitHub      | Notion, Playwright |
| documentation/ | Style doc interne               | Notion, Wiki.js  | GitHub, Playwright |

Un exemple de `.claude/settings.json` pour un projet infra :

```json
{
  "enabledPlugins": ["github"],
  "disabledMcpServers": ["notion", "playwright"]
}
```

Combiné avec un CLAUDE.md léger et ciblé, chaque projet ne charge que le strict nécessaire. Le switch d'un projet à l'autre se fait naturellement en changeant de répertoire, et Claude Code adapte automatiquement son contexte.

## Étape 4 : Automatiser

Deux types de hooks peuvent réduire votre consommation et le premier que je vais aborder n'a même rien à voir avec Claude !

- les **hooks git** : qui empêchent Claude de faire du travail inutile
- les **hooks *Claude Code*** : qui contrôlent ce que Claude voit

### Les hooks git : éviter à Claude de le faire

Avant même de parler de *Claude Code*, il y a les **hooks git**. Le framework [pre-commit](https://github.com/pre-commit/pre-commit?ref=sfeir.dev), par exemple, permet d'exécuter des formateurs et linters automatiquement à chaque commit.

L'avantage FinOps : si `terraform fmt` passe à chaque commit, Claude n'a **jamais besoin** de formater lui-même. Pas d'instruction dans le CLAUDE.md (tokens à chaque message), pas de demande manuelle (tokens par action). Le formatage est garanti par git, zéro token.

```yaml
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.105.0
    hooks:
      - id: terraform_fmt

```

```bash
pre-commit install

```

Le même principe s'applique à Prettier, Black, gofmt, rustfmt...

👍

Si vos ****hooks git** ****gèrent** déjà le ****formatage**, ****inutile** de demander à ****Claude** de ****s'en charger**.

### Les hooks Claude Code : intercepter et filtrer

*Claude Code* a son propre système de hooks : des scripts shell déclenchés à des moments précis du cycle de vie (`PreToolUse`, `PostToolUse`, `Notification`...). Contrairement aux instructions CLAUDE.md, ils sont **déterministes** : exécution garantie, zéro token consommé pour la décision.

Un use case FinOps : **tronquer les outputs volumineux**. Un `brew install`, un `npm install`, un build Docker — ces commandes produisent des centaines de lignes que Claude n'a pas besoin de voir intégralement. Un hook `PreToolUse` sur `Bash` peut **wrapper la commande avant exécution** grâce à `updatedInput` :

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "truncate-output.sh"
          }
        ]
      }
    ]
  }
}

```

Le hook reçoit sur stdin un JSON contenant `tool_input.command` (la commande que Claude veut exécuter). Le script peut alors la wrapper — par exemple transformer `npm install` en `npm install 2>&1 | tail -n 20` — et retourner la commande modifiée via `updatedInput`. Claude ne voit que la sortie tronquée.

💡

Un hook `PostToolUse` intervient ****après** l'exécution. Il peut ajouter du contexte supplémentaire (`additionalContext`) ou signaler un problème (`decision: "block"`), mais il ****ne peut pas remplacer** l'output que Claude a déjà reçu. Le champ `updatedMCPToolOutput` qui permet de substituer une réponse ne fonctionne que pour les outils MCP, pas pour les outils natifs comme `Bash`. Pour réellement réduire les tokens d'output, il faut agir ****avant** avec un `PreToolUse` qui wrappe la commande.

⚠️

****Attention** : filtrer les outputs peut masquer des erreurs importantes (stack traces tronquées, warnings avant crash). Réservez cette approche aux commandes dont vous ****connaissez la structure de sortie** : installations de packages, builds, formatage.

### Hooks vs CLAUDE.md & Skills

| Besoin                                    | CLAUDE.md & Skills | Hook git | Hook Claude Code |
| ----------------------------------------- | ------------------ | -------- | ---------------- |
| Formater les éditions                     |                    | ✅        |                  |
| Linter les fichiers                       |                    | ✅        |                  |
| Filtrer les outputs volumineux            |                    |          | ✅                |
| Bloquer l'écriture dans certains fichiers |                    |          | ✅                |
| Convention de code, framework utilisé     | ✅                  |          |                  |
| Notification quand Claude attend          |                    |          | ✅                |

La règle : si ça doit arriver **à chaque fois sans exception**, c'est un hook. Si c'est une information que Claude doit **garder en tête**, c'est le CLAUDE.md & Skills.

## Étape 5 : Adopter les bons réflexes

## Les réflexes qui sauvent la mise

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#les-r%C3%A9flexes-qui-sauvent-la-mise)

Au-delà de l'architecture (CLAUDE.md, skills, hooks), ce sont vos habitudes quotidiennes qui font la différence.

### /clear entre les tâches

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#clear-entre-les-t%C3%A2ches)

C'est le réflexe le plus rentable. Quand vous passez d'une tâche à une autre, le contexte de la tâche précédente n'a plus aucune valeur. Pire : il occupe de la place et peut induire Claude en erreur.

```
# Vous venez de finir un bugfix
> /rename fix-pagination
> /clear

# Nouvelle tâche, contexte propre
> Ajoute un système de tags sur les tâches...

```

💡

Utilisez `/rename` avant `/clear` pour retrouver facilement la session avec `--resume` si vous en avez besoin plus tard.

### /compact avec des instructions ciblées

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#compact-avec-des-instructions-cibl%C3%A9es)

Quand vous êtes en pleine session et que le contexte gonfle, `/compact` résume la conversation. Par défaut, Claude résume ce qu'il juge pertinent. Mais vous pouvez guider la compaction :

```
/compact Garde uniquement les modifications de fichiers et les résultats de tests

```

Ou configurez-le directement dans votre CLAUDE.md :

```markdown
# Instructions de compaction
Lors d'une compaction, conserve la liste complète des fichiers modifiés,
les commandes de test utilisées, et les décisions d'architecture prises.
```

### Choisir le bon modèle et ajuster l'effort

Avec Sonnet 4.6, le conseil a changé. Les benchmarks parlent d'eux-mêmes :

| Benchmark                   | Sonnet 4.6 | Opus 4.6 | Écart   |
| --------------------------- | ---------- | -------- | ------- |
| SWE-bench Verified (coding) | 79.6%      | 80.8%    | 1.2 pts |
| OSWorld (computer use)      | 72.5%      | 72.7%    | 0.2 pts |

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#choisir-le-bon-mod%C3%A8le-et-ajuster-leffort)

Pour **presque 2x moins cher** (3 $/15 $ vs 5 $/25 $), Sonnet 4.6 est quasi au niveau Opus sur les tâches de coding. Le bon réflexe FinOps : **Sonnet 4.6 par défaut**, Opus uniquement pour les tâches où il fait encore la différence — architecture complexe multi-fichiers, debug de problèmes subtils, raisonnement sur de très gros contextes. Changez en cours de session avec `/model`.

Les deux modèles intègrent l'**Adaptive Thinking** : ils décident dynamiquement quand et combien réfléchir. Pour un simple rename, pas de budget thinking gaspillé. Vous pouvez aller plus loin en ajustant le **reasoning effort** :

- **low** : réflexion minimale, moins de tool calls, réponses plus courtes — idéal pour les tâches simples en série
- **medium** : équilibre par défaut
- **high** : réflexion approfondie — pour l'architecture et le debug complexe

Configuration : slider dans `/model`, variable d'environnement `CLAUDE_CODE_EFFORT_LEVEL`, ou `effortLevel` dans `settings.json`. L'impact du `low` est multiplicatif : moins de thinking **et** moins de tool calls **et** des réponses plus courtes.

💡

Les tokens de thinking sont facturés au tarif ****output** ($25/MTok sur Opus, $15/MTok sur Sonnet). Pour un contrôle plus fin, vous pouvez poser un cap dur : `MAX_THINKING_TOKENS=8000`. Attention : cette variable force le thinking sur toutes les requêtes, même celles qui n'en auraient pas eu besoin naturellement. À utiliser avec précaution.

### Écrire des prompts précis

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#%C3%A9crire-des-prompts-pr%C3%A9cis)

Un prompt vague comme *"améliore ce code"* déclenche une exploration large : Claude va lire de nombreux fichiers, analyser la structure, chercher des patterns... Beaucoup de tokens pour un résultat... incertain.

Un prompt précis comme *"ajoute la validation des inputs sur la fonction loginUser dans @src/auth/login.ts"* permet à Claude de cibler directement le bon fichier, faire le changement, et passer à la suite.

| Prompt vague              | Prompt précis                                                                                                                            |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| "Corrige le bug de login" | "Le login échoue après expiration du token. Vérifie le refresh dans src/auth/. Écris un test de régression."                             |
| "Ajoute des tests"        | "Écris un test pour la fonction validateEmail dans @src/utils/validation.ts, couvrant les cas : email valide, chaîne vide, email sans @" |
| "Refactorise ce fichier"  | "Extrais la logique de parsing de @src/api/handler.ts dans un module séparé src/utils/parser.ts"                                         |

### Plan mode pour les tâches complexes

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#plan-mode-pour-les-t%C3%A2ches-complexes)

**Avant d'implémenter** une feature conséquente, passez en **Plan Mode** (Shift+Tab). Claude explore la codebase et propose un plan sans modifier de fichiers. Vous validez le plan, puis passez en mode normal pour l'implémentation.

L'avantage pour les tokens : un plan mal orienté détecté tôt coûte quelques milliers de tokens. Une implémentation mal orientée qu'on doit refaire, c'est des dizaines de milliers de tokens jetés.

👍

****Et le bonus** : quand vous validez le plan, Claude Code propose l'option ****"clear context and auto-accept edits"**. Le contexte est vidé, seul le plan est conservé comme base pour l'implémentation. Toute l'exploration faite pendant la planification ne pollue pas la phase d'édition — vous repartez avec un contexte propre !

### Les sous-agents : isoler le contexte

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#les-sous-agents--isoler-le-contexte)

Chaque sous-agent tourne dans sa propre fenêtre de contexte, **isolée** du parent. Il ne hérite pas de l'historique de votre conversation. Seul le résumé ou le résultat final remonte dans le contexte principal.

**Quand les utiliser :**

- Tâche qui produit du **verbose output** (audit, analyse de couverture, rapport de dépendances)
- Travail autonome qui **ne dépend pas** du contexte courant
- Tâches **indépendantes** et parallélisables

**Le coût :** chaque sous-agent a son propre overhead (system prompt, outils). Si le sous-agent doit relire des fichiers que le parent connaît déjà pour comprendre le contexte, c'est du travail dupliqué. Le surcoût est réel quand la tâche déléguée dépend fortement du contexte courant.

En revanche, pour des **tâches indépendantes**, les sous-agents sont souvent **plus économes au total**. En séquentiel dans votre conversation, chaque étape ajoute ses fichiers au contexte, et tout est renvoyé à chaque message suivant — le coût croît à chaque tour. Avec des sous-agents parallèles, chacun travaille dans son coin et seul le résumé remonte.

**Exemple concret :** vous voulez auditer la couverture de tests de 5 modules. En séquentiel, Claude lit \~15 fichiers par module et le contexte grossit à chaque étape : au 5e module, il traîne les 4 précédents. Avec 5 sous-agents en parallèle, chacun ne lit que ses 15 fichiers et remonte un résumé de \~500 tokens. Résultat : 2 500 tokens dans votre contexte principal, un contexte propre pour la suite — et c'est plus rapide.

😈

Qui a dit que le multi-agent consomme plus ? Après attention quand même : vous allez plus vite, vous consommez peut-être moins sur la tâche unitairement, mais si vous continuez de travailler sur une heure vous consommez plus !

## Récapitulatif : les leviers d'optimisation

[](https://github.com/Thomgrus/articles/blob/main/drafts/finops-tokens-claude-code.md?ref=sfeir.dev#r%C3%A9capitulatif--les-leviers-doptimisation)

## Conclusion

**Optimiser sa consommation** de tokens sur Claude Code, **ce n'est pas être radin**. C'est du FinOps appliqué : **chaque token** **doit servir à produire de la valeur**.

Plusieurs leviers ont été abordés dans cet article :

![](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/02/finops-tokens-claude-code_diagram-leviers-optimisation-1.png)

- **Structurel** (à faire une fois, fort impact) : alléger le CLAUDE.md, utiliser des rules conditionnelles, créer des skills à la demande, organiser les configurations par projet
- **MCP** (à revoir régulièrement) : ajuster le Tool Search, remplacer les MCP par des CLI quand c'est possible, désactiver l'inutile par projet
- **Automatisation** (hooks) : formateurs automatiques, hooks git pre-commit, filtres d'output sur les commandes répétitives éventuellement
- **Quotidien** (réflexes) : `/clear` entre les tâches, `/compact` avec instructions ciblées, prompts précis, bon modèle + effort adapté, sous-agents pour isoler le contexte

Le setup initial prend une heure ou deux. Le retour sur investissement, c'est la première semaine. Et au-delà de l'économie financière, un contexte propre, c'est aussi un Claude qui performe mieux : moins de contexte inutile = des réponses plus pertinentes.

Commencez par lancer `/context` dans votre prochaine session. Regardez ce qui consomme. Agissez en conséquence.

---

**Sources :**

- [Manage costs effectively - Claude Code Docs](https://code.claude.com/docs/en/costs?ref=sfeir.dev)
- [Extend Claude with skills - Claude Code Docs](https://code.claude.com/docs/en/skills?ref=sfeir.dev)
- [Automate workflows with hooks - Claude Code Docs](https://code.claude.com/docs/en/hooks-guide?ref=sfeir.dev)
- [Best Practices for Claude Code - Claude Code Docs](https://code.claude.com/docs/en/best-practices?ref=sfeir.dev)
- [Configuration hierarchy - Claude Code Docs](https://code.claude.com/docs/en/settings?ref=sfeir.dev)
- [Manage Claude's memory - Claude Code Docs](https://code.claude.com/docs/en/memory?ref=sfeir.dev)
- [Plugins - Claude Code Docs](https://code.claude.com/docs/en/plugins?ref=sfeir.dev)
- [Sub-agents - Claude Code Docs](https://code.claude.com/docs/en/sub-agents?ref=sfeir.dev)
- [Model configuration - Claude Code Docs](https://code.claude.com/docs/en/model-config?ref=sfeir.dev)
- [Pricing - Claude API Docs](https://platform.claude.com/docs/en/about-claude/pricing?ref=sfeir.dev)
- [Stop Wasting Tokens: How to Optimize Claude Code Context by 60% - Jpranav (Medium)](https://medium.com/@jpranav97/stop-wasting-tokens-how-to-optimize-claude-code-context-by-60-bfad6fd477e5?ref=sfeir.dev)
- [Token Optimization Techniques - claude-code-ultimate-guide (DeepWiki)](https://deepwiki.com/FlorianBruniaux/claude-code-ultimate-guide/10.4-token-optimization-techniques?ref=sfeir.dev)
- [Optimising MCP Server Context Usage - Scott Spence](https://scottspence.com/posts/optimising-mcp-server-context-usage-in-claude-code?ref=sfeir.dev)