Huit repos Claude Code mesurés sur un projet : coût de session, ablations, verdicts

TL;DR

• Huit repos Claude Code populaires ont été installés au niveau projet sur une même vraie base de code et mesurés : tokens au démarrage de session, tokens de sortie sur trois tâches de code, et ce que chacun écrit en dehors du projet.
• Un seul des huit a changé un résultat : anti-slop, utilisé comme linter, a repéré le même cast dangereux dans les 3 runs T3 pour +95 tokens de session et rien par tour.
• Les jeux de règles qui rendent la sortie concise n'ont pas tenu sur le travail avec outils : les 52% de la base annoncés par Chisle sont devenus 94% des tokens de sortie de la base, et son bras a coûté plus que la base sur deux tâches sur trois une fois l'entrée comptée.
• Les trois serveurs MCP n'ont jamais été appelés une seule fois en 63 runs. Installé ne veut pas dire utilisé.
• La pile est additive : les huit ensemble ont ajouté +6,804 tokens au démarrage, soit 63 tokens de moins que la somme des parties.
• Deux installations sont sorties du projet. Un codemod s'est enregistré dans les configs globales de 8 autres agents ; un outil force --dangerously-skip-permissions et copie le fichier d'identifiants, il n'a donc jamais été lancé.

Ce que disent les mesures

Les tokens au démarrage de session sont reproductibles, le coût en dollars non : chaque condition a renvoyé exactement le même total de tokens d'entrée sur les deux runs, alors que le coût de la même condition variait de $0.0183 à $0.0035 selon l'état du cache de prompt. Le nombre de tokens est donc la métrique utilisée partout. Le projet de base démarre à 17,378 tokens s4.

Les schémas d'outils MCP sont différés sur cette version de Claude Code, et le coût dépend désormais du nombre de noms d'outils annoncés par un serveur, pas de la taille des schémas. Les 39 outils d'ouroboros coûtent +1,642 tokens, les 19 de reticle +895, les 2 de ui-skills +37 : environ 42 à 47 tokens par nom d'outil. Par défaut, tous les outils MCP sont différés et chargés à la demande, et le mode auto de ENABLE_TOOL_SEARCH les diffère dès que leurs définitions atteignent 10% de la fenêtre de contexte s4. img2threejs fournit un SKILL.md de 32,902 octets et 352 fichiers, et coûte +107 tokens au démarrage, car seule la description du frontmatter est chargée. La doc des skills plafonne chaque description listée à 1,536 caractères et raccourcit les descriptions pour tenir dans un budget de listing quand il y a beaucoup de skills ; après compaction, les skills invoqués sont rattachés à nouveau à 5,000 tokens chacun dans un budget partagé de 25,000 tokens s5. Ce budget de listing explique pourquoi 40 skills peuvent coûter 3,060 tokens par tour dans une configuration qui n'en invoque aucun s10, et pourquoi ce sont les descriptions qui sont coupées plutôt que les skills retirés s11.

Le hook UserPromptSubmit de Chisle ajoute 287 octets d'additionalContext à chaque tour ; sur une tâche de 22 tours, c'est ce qui explique que son bras ait coûté +41,539 tokens d'entrée au total sur T3 par rapport à la base. caveman, mesuré comme référence, n'injecte rien sauf si le prompt commence par /caveman. Quand plusieurs hooks sur le même événement renvoient chacun de l'additionalContext, Claude reçoit le tout concaténé, avec un plafond de 10,000 caractères par hook s15. Avec Chisle, caveman et ouroboros branchés ensemble, il y avait 3 enregistrements sur SessionStart, 3 sur UserPromptSubmit et 2 sur PostToolUse, pour +4,269 tokens au démarrage s15.

Le README de Chisle annonce une facture sur 20 tâches à 52% de la base, et le README lui-même limite ce chiffre aux prompts à un seul tour sans outils s3. Sur trois tâches contre un vrai repo, 3 runs chacune, les moyennes de sortie cumulées de Chisle étaient de 9,007 tokens contre 9,615 pour la base, soit 94% ; celles de caveman de 10,820, soit 113%, sur un échantillon dont l'écart sur T3 était de 2,014 tokens, donc aucun des deux sens ne dépasse le bruit s3. Le compresseur de sortie de Chisle n'a jamais écrit d'enregistrement d'économies en 63 runs.

anti-slop vendorisé dans tools/oxlint/ avec ses 18 règles génériques plus oxc/no-accumulating-spread a trouvé 109 problèmes dans le projet intact de 4,775 lignes, dont 83% viennent de deux règles de style maison (require-readable-spacing 50, require-safety-comment-for-type-assertion 41) s8. Sur le code écrit par Claude, il a relevé maxLength={field.maxLength as number} dans les 3 runs T3, Claude recopiant le cast dangereux de la base de code elle-même s8. Le plugin est en ESM, donc le projet hôte a besoin de "type": "module" sinon oxlint échoue avec Cannot use import statement outside a module.

Le codemod init de Reticle, lancé avec RETICLE_STATE_DIR défini et la télémétrie coupée, a indiqué avoir enregistré le serveur MCP auprès de 8 autres agents (VS Code portée utilisateur, GitHub Copilot CLI, Warp, Factory Droid, Kiro, Amazon Q Developer CLI, Cline CLI, Amp) et pré-approuvé ses outils dans Gemini CLI ; l'appairage a ensuite échoué avec ERR_OSSL_EVP_UNSUPPORTED s6. Caliper a été refusé : claude_code.py:106 force --dangerously-skip-permissions et seed_files() copie ~/.claude/.credentials.json avec un repli sur le Keychain s2. Le hook UserPromptSubmit d'ouroboros répond à un prompt ordinaire comme write prd for reading time par REQUIRED SKILL: /ouroboros:setup, une étape qu'une installation au niveau projet ne peut pas satisfaire s7.

Un article portant sur 2,545 trajectoires avec des bibliothèques de 52, 102 et 202 skills rapporte des baisses de taux de réussite cumulées de .08, .14 et jusqu'à 21%, les descriptions similaires se masquant entre elles et expliquant une part croissante de la perte s20.

Mesures

Protocole : un vrai projet TypeScript, chaque repo installé uniquement au niveau projet. Démarrage de session : le prompt Reply with OK en mode JSON -p avec des flags identiques, 2 runs par condition, chiffre = input_tokens + cache_creation_input_tokens + cache_read_input_tokens du premier tour. Ablation : trois tâches de code (T1 courte, T2 moyenne, T3 longue sur une UI) avec contrôles de réussite et une barrière de vérification des types, 3 runs par cellule, conditions = base, chaque repo toujours actif seul, les huit empilés. anti-slop : oxlint 1.78.0 avec le jeu de règles vendorisé sur le projet intact et sur le code écrit dans les 9 runs de base.

63/63 runs réussis et 0/63 ont introduit une nouvelle erreur de type. Seules deux cellules dépassent leur propre écart d'un run à l'autre : Chisle sur T1 (−234, −14.0%) et la pile sur T1 (−206, −12.3%). Sur T2 et T3, tous les écarts restent dans la dispersion ; les runs T3 d'ouroboros allaient de 4,324 à 7,093 tokens de sortie pour un prompt identique, soit 64% d'écart.

À faire lundi

• Lance /context all dans une session neuve de ton projet principal et note le chiffre de départ.
• Lance claude plugin details <name> sur chaque plugin installé ; la ligne always-on est le seul chiffre facturé à chaque tour.
• Liste tes hooks par événement. Tout hook qui renvoie additionalContext sur UserPromptSubmit pour chaque prompt est une taxe par tour ; garde uniquement ceux qui se déclenchent sur un mot-clé ou un matcher.
• Compte les noms d'outils annoncés par chaque serveur MCP, prévois environ 42 à 47 tokens par nom, puis vérifie dans tes transcripts combien ont déjà été appelés.
• Avant d'installer quoi que ce soit avec un script init ou de setup, lis-le pour repérer les écritures hors du repo : ~/.claude/settings.json, les dossiers de config d'autres agents, les fichiers d'identifiants, --dangerously-skip-permissions.
• Branche les contrôles de qualité du code généré comme un linter dans l'étape de vérification, pas comme un skill dans le contexte : une règle de lint ne coûte rien par tour.
• Avant de croire une promesse d'économie de tokens, lance la même tâche 3 fois avec et sans l'outil et compare l'écart à ta propre dispersion min à max.
• Archive ce que tu retires au lieu de le supprimer, pour qu'un workflow qui en a besoin puisse le récupérer.

Pour aller plus loin

• Le budget de listing des skills et le plafond de 1,536 caractères par description expliquent pourquoi une configuration chargée se dégrade sans qu'aucun skill ne cesse de se charger. Lis les sections "Skill descriptions are cut short" et "Skill content lifecycle" s5.
• L'article sur /skill-doctor montre 40 skills à 3,060 tokens par tour et lesquels couper en premier ; son angle mort, les skills coûteux dans un plugin utilisé, est laissé pour une suite s10.
• L'article derrière la règle empirique des "plus de 30 skills" : 2,545 trajectoires avec des bibliothèques de 52, 102 et 202 skills, avec l'effet de masquage isolé s20, et le résumé accessible qui l'a popularisé s12.
• La concaténation des hooks et le plafond de 10,000 caractères d'additionalContext, plus la syntaxe de matcher qui permet de ne déclencher un hook que sur Write|Edit s15.
• Le fil sur les 63% retirés, avec un jeton bearer codé en dur trouvé dans une config MCP supprimée, une digression sécurité que la vidéo a laissée de côté s13.
• Le README de Chisle lui-même, lignes 229 et 262, limite son chiffre de 52% aux prompts à un seul tour sans outils et concède la cellule du code court à caveman. Lis les petites lignes avant de citer le titre s3.
• Les deux repos hors pile n'ont pas été notés parce qu'ils s'invoquent à la main et ne coûtent rien au démarrage : img2threejs pour les scènes Three.js s21 et fwc-swiftui-skills pour les surfaces Liquid Glass s22.

Sources

• Plugins reference, docs Claude Code. Pourquoi la lire : plugin details, les portées d'installation et le chargement différé des outils MCP qui fait du nombre de noms d'outils le vrai coût.
• Extend Claude with skills, docs Claude Code. Pourquoi la lire : le plafond des descriptions, le budget de listing et le budget de rattachement après compaction sur une seule page.
• Hooks reference, docs Claude Code. Pourquoi la lire : ce qui se passe quand deux hooks injectent sur le même événement, et comment les matchers évitent qu'un hook se déclenche à la plupart des tours.
• dmmulroy/anti-slop, GitHub. Pourquoi la lire : le seul repo des huit qui a changé un résultat ; vendorise les règles, saute le skill.
• JayPokale/Chisle, GitHub. Pourquoi la lire : un README qui borne honnêtement sa propre promesse de 52% si on lit au-delà du titre.
• edonadei/caliper, GitHub. Pourquoi la lire : un évaluateur de skills à connaître, et une leçon : lire claude_code.py avant de lancer quoi que ce soit.
• reticlehq/reticle, GitHub. Pourquoi la lire : le codemod init est l'exemple le plus clair d'un installeur qui écrit bien loin de ton projet.
• Q00/ouroboros, GitHub. Pourquoi la lire : un workflow piloté par hooks qui n'a de sens qu'installé globalement, avec une étape de setup qu'une installation projet ne peut pas satisfaire.
• ibelick/ui-skills, GitHub. Pourquoi la lire : l'installation la moins chère ici à +37 tokens, et jamais appelée.
• /skill-doctor: 40 skills, 3,060 tokens a turn, dev.to. Pourquoi la lire : le coût détaillé par skill sur une vraie configuration.
• Too many Claude Code skills? How the listing budget decides, dev.to. Pourquoi la lire : le mécanisme par lequel les descriptions sont tronquées.
• Why More Than 30 Skills Kill Your AI Agent, dev.to. Pourquoi la lire : la version lisible de l'article sur le masquage.
• Skill shadowing paper, arXiv. Pourquoi la lire : les baisses de taux de réussite cumulées par taille de bibliothèque, avec intervalles de confiance.
• I removed 63% of my Claude Code setup, Reddit r/ClaudeCode. Pourquoi la lire : de ~235 composants à ~87, archivés et non supprimés.
• My fresh Claude Code sessions were starting at ~35K tokens, Reddit r/ClaudeCode. Pourquoi la lire : un audit /context all en sept étapes que tu peux copier cet après-midi.
• img2threejs/img2threejs, GitHub. Pourquoi la lire : la preuve qu'un SKILL.md de 32,902 octets coûte 107 tokens tant qu'on ne l'invoque pas.
• FloWritesCode/fwc-swiftui-skills, GitHub. Pourquoi la lire : des skills en Markdown statique, la forme d'une installation qui ne peut entrer en conflit avec rien.

FAQ

Un serveur MCP coûte-t-il encore des milliers de tokens de schéma au démarrage ?

Pas sur la version mesurée. Les schémas sont différés et le coût dépend du nombre de noms d'outils annoncés, environ 42 à 47 tokens chacun. Un serveur de 39 outils a coûté +1,642 tokens ; un serveur de 2 outils, +37.

Pourquoi Chisle a-t-il coûté plus que la base alors qu'il produisait moins de tokens de sortie ?

Son jeu de règles se charge au démarrage de session (+3,496 tokens) et son hook injecte 287 octets à chaque tour. Sur T2 et T3, ce surcoût en entrée a dépassé une économie de sortie qui n'a jamais franchi le bruit d'un run à l'autre.