Sommaire

« Trop de Skills installés et le contexte est saturé » — on l'entend sans arrêt. C'est à moitié vrai et à moitié faux.

D'après la documentation officielle, la liste des Skills puise dans un budget fixe de 1 % de la fenêtre de contexte du modèle, et vous aurez beau ajouter des Skills, elle s'arrête là. Elle ne gonfle pas. Ce qui arrive à la place, c'est que les Skills cessent d'être appelés : lorsque la liste déborde du budget, Claude Code supprime les descriptions en commençant par les Skills les moins souvent invoqués et ne garde que leur nom. Un Skill privé de sa description ne se raccroche plus à ce que vous demandez.

Aucune erreur n'apparaît. Rien ne ralentit. Le Skill cesse simplement d'être utilisé, en silence. Cet article explique comment voir ce qui occupe réellement votre contexte, avec des chiffres plutôt qu'avec des suppositions, et par quoi commencer à couper une fois la mesure faite.

Ce qui se passe vraiment quand vous ajoutez des Skills

Le budget de la liste est fixé à 1 % de la fenêtre de contexte. Ce qui déborde vous coûte des descriptions, pas des tokens

DANS LE BUDGET
Chaque Skill garde sa description

Le nom et la description se chargent en entier. Même si votre formulation tombe un peu à côté, les mots-clés retrouvent le Skill

JUSTE APRÈS LE DÉBORDEMENT
Les descriptions partent par ordre d'usage

Les Skills fréquents gardent leur texte intégral. Ceux dont vous vous servez rarement perdent leur description en premier

NOM SEUL
Présent, mais jamais choisi

Il reste dans la liste. Mais plus rien ne dit à quoi il sert, donc il ne se raccroche à aucune demande

Source : documentation officielle Claude Code, Skills

1. Les Skills ne gonflent pas à l'infini : la liste plafonne à un budget de 1 %

Pour que Claude sache quels Skills sont disponibles, Claude Code charge dans le contexte une liste des noms et des descriptions de Skills. C'est là que le budget entre en jeu. La documentation officielle indique que la liste contient toujours tous les noms de Skills, mais que lorsqu'il y en a beaucoup, Claude Code raccourcit les descriptions pour tenir dans le budget de caractères de la liste, et elle fixe ce budget à 1 % de la fenêtre de contexte du modèle.

Les chiffres rendent la chose concrète. Sur un modèle doté d'une fenêtre de contexte d'un million de tokens, la liste des Skills reçoit 1 % de ce total. Les 99 % restants sont là pour la conversation, les fichiers et les résultats d'outils. Que vous installiez 50 Skills ou 100, ce 1 % ne bouge pas.

Où passe alors le surplus ? Dans des descriptions raccourcies. La documentation précise jusqu'à l'ordre du rognage : quand la liste déborde, Claude Code supprime les descriptions en commençant par les Skills les moins souvent invoqués, de sorte que ceux dont vous vous servez le plus gardent leur texte intégral.

C'est là que se niche le vrai danger en pratique. Les Skills qui encaissent le coup sont ceux dont vous ne vous servez qu'occasionnellement, et ce sont généralement les mêmes que ceux dont vous avez besoin juste après les avoir oubliés. Une procédure de migration trimestrielle, une opération de release lancée quelques fois par an : exactement celles-là perdent leur description en premier.

Le budget est réglable. Inscrivez dans skillListingBudgetFraction une fraction de la fenêtre de contexte (par exemple 0.02 pour 2 %) et la liste gagne de la place. Il existe aussi un plafond par Skill : 1 536 caractères couvrant la description et ses conditions de déclenchement par défaut (modifiable via skillListingMaxDescChars). Si la documentation conseille de placer les cas d'usage principaux en tête, c'est parce que ce plafond coupe par la fin.

2. Trois outils pour mesurer, chacun avec son rôle

Trois outils permettent de remplacer les suppositions par des chiffres. /context existe depuis un moment, mais la ligne de cache de prompt de /usage est arrivée en v2.1.251 (28 août 2026) et /skill-doctor en v2.1.252 (31 août). Leurs rôles diffèrent, ils méritent donc tous les trois d'être gardés en tête.

/context
Ce qui est chargé en ce moment

Détaille ce qui occupe la fenêtre. La ligne Skills indique la taille après application du budget, elle correspond donc à ce que le modèle reçoit réellement

/usage
Ce que cela a consommé

Les tokens et le coût de la session, plus l'état du cache de prompt et une répartition de la consommation par Skill, par sous-agent et par serveur MCP

/skill-doctor
Lesquels sont rentables

Indique le coût et la fréquence d'invocation de chaque Skill et signale ceux qui n'ont jamais été appelés. Il pointe jusqu'à l'endroit où couper

Il y a un ordre. Lisez la répartition avec /context, vérifiez ce qu'elle a réellement dépensé avec /usage, puis identifiez les candidats à la coupe avec /skill-doctor. Commencez par l'autre bout et vous supprimerez des choses sans rien pour justifier la décision.

Au sujet de la ligne Skills de /context, la documentation consigne aussi le comportement passé de la commande : avant la v2.1.196, elle comptait la longueur en caractères de toutes les descriptions et pouvait afficher une valeur plusieurs fois supérieure au budget configuré. Si votre impression que les Skills dévorent votre contexte vient d'un souvenir ancien, ce chiffre lui-même était peut-être plus gros que la réalité.

3. Faire nommer les Skills que personne n'utilise

/skill-doctor est disponible à partir de Claude Code v2.1.252 (31 août 2026). La description officielle tient en une phrase : vous pouvez consulter le coût et la fréquence d'invocation de chaque Skill et décider lesquels couper. Quatre points de son comportement méritent d'être connus.

Ce que /skill-doctor suppose

  • En session interactive, il ouvre l'onglet Stats du gestionnaire /plugin. En mode non interactif avec -p, il affiche du texte à la place
  • Les Skills fournis d'origine et ceux distribués par l'organisation sont hors périmètre. Seul ce que vous avez ajouté vous-même apparaît
  • Les Skills jamais invoqués sont signalés, avec l'endroit où les couper
  • Il ne peut pas s'exécuter en pilotage à distance depuis un téléphone ou un navigateur, et renvoie une erreur

Gardez une seule chose à l'esprit en lisant les résultats et vous ne vous tromperez pas. « Jamais invoqué » n'est pas synonyme d'« inutile ». Comme la section précédente l'a montré, l'une des raisons pour lesquelles un Skill n'est jamais appelé est que sa description a été rognée, si bien que plus rien ne permet de le trouver.

Avant de couper, le geste sûr consiste à appeler le Skill par son nom. S'il fonctionne quand on le nomme mais n'est jamais choisi automatiquement, il n'est pas inutile : sa description perd face au budget. Le remède n'est pas la suppression mais la réécriture de la description (les cas d'usage principaux en tête) ou le relèvement du budget.

4. Les défauts de cache coûtent plus cher que la taille

À partir d'ici, le sujet quitte l'axe de la taille du contexte. Deux conversations de même taille peuvent se facturer très différemment selon que le cache fonctionne ou non.

Depuis Claude Code v2.1.251 (28 août 2026), le panneau de session de /usage comporte une ligne de cache de prompt. Voici l'exemple que donne la documentation.

Prompt cache (main):   14 requests · 91% of input tokens from cache ·
2 misses (last 6m 10s ago, 310.2k tokens re-cached) ·
1 expected rebuild (compaction or tool-result clearing) ·
warm (1h TTL, last activity 40s ago)

Trois choses comptent à la lecture.

MISSES
5 % et 2 000 tokens

Une requête compte comme un défaut quand elle relit plus que ce volume de contenu que le cache aurait pu servir. Un petit remplacement ne suffit pas

EXPECTED REBUILD
Ce que vous avez cassé vous-même

Quand Claude Code réécrit lui-même la conversation par compaction ou par effacement d'anciens résultats d'outils, cela est compté à part comme une reconstruction attendue, pas comme un défaut

WARM / COLD
Dans la durée de vie, ou au-delà

Le préfixe déjà mis en cache est-il encore vivant. S'il a refroidi, la ligne indique depuis combien de temps vous l'avez laissé inactif

À partir de la v2.1.260, lorsqu'une explication plausible existe pour un défaut récent, la ligne la nomme (par exemple likely cause: tool definitions changed). Ajouter un serveur MCP ou remplacer un Skill réécrit une portion proche du début de la conversation, ce qui invalide le cache de tout ce qui suit. C'est pour cette raison que modifier sa configuration avant de commencer à travailler revient moins cher.

Une réserve. Cette ligne ne regarde que la conversation principale et n'inclut pas les sous-agents. Si votre façon de travailler pousse les traitements lourds vers des sous-agents, ces chiffres ne donnent pas le tableau complet. Pour comparer ce que chaque session a consommé, sous-agents compris, vous pouvez en faire le total à partir des journaux de conversation (Claude Code : mesurer la consommation par session).

5. Le cache ne vit pas toujours une heure

Ce point touche directement à la facture et reste pourtant peu connu. La durée de vie du cache de prompt varie selon votre formule et selon la situation.

Abonnement
1 heure

Partez déjeuner : à votre retour, le cache est encore vivant

Après le passage aux crédits d'usage, ou via une clé API et les fournisseurs cloud
5 minutes

Éloignez-vous un instant et il refroidit. Le message suivant relit tout le contexte

Source : documentation officielle Claude Code, Manage costs effectively (les règles de durée de vie du cache)

La documentation indique que la durée de vie est d'une heure sur abonnement et tombe à cinq minutes dès que vous commencez à consommer des crédits d'usage (usage credits), et qu'elle vaut cinq minutes par défaut via une clé API ou un fournisseur cloud. À l'instant où vous atteignez votre limite et basculez sur les crédits supplémentaires, la durée de vie du cache est divisée par douze : autrement dit, « après la limite », ce n'est pas seulement le prix unitaire qui change, c'est aussi la façon dont le cache agit. La documentation indique par ailleurs un moyen de conserver une durée de vie d'une heure tout en consommant des crédits d'usage : définir le TTL soi-même.

6. MCP est chargé à la demande par défaut, et les CLI restent pourtant plus légers

« Installer des serveurs MCP dévore le contexte » repose aussi sur des prémisses qui ont changé. D'après la documentation, les définitions d'outils MCP sont chargées à la demande par défaut, et tant que Claude n'utilise pas un outil précis, seuls les noms d'outils et la description du serveur entrent dans le contexte.

Malgré cela, la documentation affirme que les outils en ligne de commande comme gh, aws, gcloud et sentry-cli restent plus efficaces côté contexte. La raison est limpide : un CLI n'ajoute aucune liste d'outils. Claude peut exécuter la commande directement, il n'y a donc même pas de noms à charger.

La conclusion pratique en découle. Si un CLI fait le même travail, votre raison de choisir MCP doit se situer en dehors du budget de contexte (authentification centralisée, résultats structurés, contrôle des permissions). Un serveur installé « parce qu'il avait l'air pratique » devient un candidat à la coupe, et /mcp vous en donne la liste.

7. Ce qui se charge à chaque tour : CLAUDE.md et la conversation elle-même

Les Skills et MCP se chargent sous condition, mais deux choses se chargent sans condition, à chaque fois.

La première est CLAUDE.md. Il est lu dans le contexte au démarrage de la session, si bien que les procédures de travail que vous y avez écrites restent installées dans la fenêtre pendant tout le temps où vous travaillez sur autre chose. Comme remède, la documentation recommande de déplacer vers des Skills les instructions détaillées propres à un flux de travail, et elle va jusqu'à donner un objectif chiffré : garder CLAUDE.md sous les 200 lignes, à l'essentiel. Le raisonnement est qu'un Skill n'est chargé que lorsqu'il est appelé, si bien que le même contenu cesse d'être une charge permanente.

La seconde est la conversation elle-même. La documentation le formule précisément : Claude Code envoie la conversation entière à chaque requête, et chaque fois que Claude utilise un outil, il envoie une nouvelle requête portant ce résultat d'outil. Ainsi, une question d'une seule ligne dans une session ouverte toute la journée déclenche malgré tout la consommation correspondant à la conversation entière. Le cache fait baisser le prix unitaire, mais pas jusqu'à zéro.

C'est exactement là que se joue le choix entre /clear et /compact. La documentation écrit que /compact lit la conversation qu'il résume, si bien que compacter un gros contexte constitue en soi une grosse requête, et que si vous voulez repartir de zéro plutôt que poursuivre, /clear ne coûte rien. « Compacter, au cas où » n'est pas gratuit. Le choix du bon moment est traité en détail dans Faut-il lancer /compact régulièrement dans Claude Code ?

8. La consommation grimpe alors que vous ne faites rien

« Je me suis juste absenté et ma consommation a grimpé » — il y a des raisons concrètes à cela, et la documentation les énumère. Toutes ont la même forme : un nouveau tour démarre et envoie tout le contexte, même pendant que la session est inactive.

Ce qui fait avancer la consommation pendant votre inactivité

  • Les tâches planifiées : elles se déclenchent à leur intervalle même quand la session ne fait rien, et chaque déclenchement envoie tout le contexte
  • Les messages venus d'autres sessions : ils sont livrés comme un nouveau tour pendant l'inactivité. Réglez crossSessionInbound sur hold pour les mettre en attente
  • Les vérifications d'avancement d'un objectif : pendant qu'un travail de fond est en cours, un tour de vérification s'exécute, jusqu'à trois fois entre deux prompts
  • Chaque membre d'une équipe d'agents : ils continuent de consommer des tokens jusqu'à la fin de leur travail
  • L'expiration du cache : le premier message après une pause relit tout le contexte

Les équipes d'agents viennent avec un multiplicateur chiffré. La documentation dit qu'une équipe d'agents consomme environ 7 fois les tokens d'une session normale lorsque ses membres travaillent en mode plan. Chaque membre dispose de sa propre fenêtre de contexte, si bien que cela évolue à peu près proportionnellement à l'effectif. Le conseil officiel est tout aussi net : utilisez Sonnet pour les membres, gardez l'équipe petite, et arrêtez-la une fois le travail terminé.

Comme ordre de grandeur, la documentation situe la moyenne des déploiements en entreprise à environ 13 $ par personne et par jour ouvré, soit 150 à 250 $ par mois, et indique que 90 % des utilisateurs restent sous 30 $ par jour ouvré. Si vos propres chiffres sortent nettement de cette fourchette, l'un des points ci-dessus est probablement en jeu.

9. Une fois la mesure faite, par quoi couper en premier

Une fois les chiffres en main, commencez là où l'effet est le plus grand. En réordonnant les mesures que liste la documentation, du gain le plus rapide au plus lent, on obtient ceci.

GRATUIT, TOUT DE SUITE
/clear en passant à un travail sans rapport

Le vieux contexte continue d'être facturé sur chaque message qui suit. Lancez /rename avant d'effacer et vous pourrez revenir plus tard avec /resume

CORRIGER LA CONFIGURATION UNE FOIS
Passer CLAUDE.md sous les 200 lignes

Déplacez vers des Skills les procédures propres à une tâche. Moins de choses se chargent en permanence, et cela vaut pour toutes les sessions

RESSERRER LA SORTIE
Hooks et sous-agents

Au lieu de faire lire un journal de 10 000 lignes, laissez un hook ne renvoyer que les lignes utiles. Enfermez les traitements verbeux dans un sous-agent

BAISSER LE PRIX UNITAIRE
Adapter le modèle et l'effort au travail

Sonnet suffit pour l'essentiel du code. Pour les tâches simples, baissez la réflexion avec /effort

L'ordre a un sens. Le premier point agit dès aujourd'hui, et il est gratuit. Le deuxième se corrige une fois et vaut pour toutes les sessions. Les troisième et quatrième relèvent de la configuration et des habitudes, ils mettent donc un peu de temps à se voir. La suppression de Skills n'arrive pas en tête parce que, comme les sections précédentes l'ont montré, c'est rarement le facteur principal.

En revanche, un point ne bouge pas : on mesure avant de toucher à quoi que ce soit. Le /usage officiel signale tout comportement représentant 10 % ou plus de la consommation récente (un contexte trop long, des défauts de cache, etc.). Couper quelque chose qui ne porte aucune marque ne changera rien à ce que vous ressentez.

FAQ

Q1. Combien de Skills peut-on avoir sans risque ?
Il n'existe pas de plafond sur le nombre. Ce qui compte, c'est de tenir dans le budget de caractères de la liste, soit 1 % de la fenêtre de contexte. Les mêmes dix Skills déborderont avec des descriptions longues et tiendront avec des descriptions courtes. Lire la ligne Skills de /context et lancer /skill-doctor est plus exact que compter.

Q2. Puis-je supprimer un Skill qui n'a jamais été invoqué ?
Appelez-le par son nom avant de le supprimer. S'il fonctionne quand on le nomme mais n'est jamais choisi automatiquement, il n'est pas inutile : sa description perd face au budget. Dans ce cas, le remède n'est pas la suppression mais la réécriture de la description (les cas d'usage principaux en tête) ou le relèvement du budget.

Q3. Appuyer souvent sur /compact revient-il moins cher ?
Non. La compaction lit la conversation qu'elle résume, donc sur un gros contexte elle constitue en soi une grosse requête. Quand la continuité ne vous est pas nécessaire, /clear est moins cher (il ne coûte rien) et plus sûr.

Q4. Quel taux de succès du cache faut-il viser ?
La documentation ne donne pas de seuil, alors observez la variation plutôt que la valeur absolue. Si le taux chute alors que vous travaillez de la même façon, vous avez probablement modifié votre configuration (MCP, Skills, définitions d'outils) juste avant. À partir de la v2.1.260, la ligne affiche son hypothèse sur la cause.

Q5. Faut-il réduire le nombre de serveurs MCP ?
Les définitions d'outils sont chargées à la demande par défaut, donc le simple fait d'en avoir un installé pèse moins qu'avant. Cela dit, si un CLI comme gh fait le même travail, le CLI est plus léger (il n'ajoute aucune liste d'outils). Les serveurs dont vous ne vous servez pas se coupent avec /mcp.

Q6. Les sous-agents permettent-ils d'économiser du contexte ?
Oui. La documentation recommande d'ailleurs de confier les traitements verbeux (exécution de tests, récupération de documentation, dépouillement de journaux) à un sous-agent, de garder les détails dans son contexte et de ne renvoyer qu'un résumé. Notez toutefois que la ligne de cache de /usage ne regarde que la conversation principale, si bien que dans un usage centré sur les sous-agents ces chiffres ne donnent pas le tableau complet.

Q7. Je n'arrive pas à lancer /skill-doctor.
Il faut Claude Code v2.1.252 ou une version ultérieure. Il ne peut pas non plus s'exécuter en pilotage à distance depuis un téléphone ou un navigateur, où il renvoie une erreur. En session interactive, il ouvre l'onglet Stats du gestionnaire /plugin ; si vous voulez une sortie texte, lancez-le en mode non interactif avec -p.

Sources

  • Claude Code Docs — Skills (le budget de la liste à 1 % de la fenêtre de contexte, le plafond de 1 536 caractères par description, l'ordre de rognage en cas de débordement, la ligne Skills de /context)
  • Claude Code Docs — Manage costs effectively (la répartition de /usage, la ligne de cache de prompt, la définition d'un défaut, la durée de vie du cache, l'objectif de 200 lignes pour CLAUDE.md, le facteur d'environ 7 des équipes d'agents, le coût moyen en entreprise)
  • Claude Code Docs — Slash commands (le comportement et les prérequis de /skill-doctor)
  • Claude Code Changelog (v2.1.251 la ligne de cache, v2.1.252 /skill-doctor, v2.1.260 l'estimation de la cause, v2.1.261 le réglage des limites de sortie)