Si le gaspillage de tokens ne se voit pas, c’est parce qu’il ne s’agit pas d’échecs mais de doublons : relire deux fois le même fichier, réessayer avec les mêmes arguments, rappeler le même outil. J’ai donc créé un CLI qui lit une trace terminée et indique quelles étapes ont refait un travail déjà effectué !
[Essayer]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Cela tourne en local, sans inscription. torch n’est pas installé, donc l’installation prend seulement quelques secondes. Python 3.12 ou plus récent. Les fichiers de session Claude Code se trouvent sous ~/.claude/projects/.
Voici une sortie réelle obtenue sur une session publique Claude Code (258 tours) :
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[Comment le jugement est fait]
Contrairement à Langfuse ou Phoenix, cela ne stocke ni ne visualise les traces. Cela lit une trace déjà terminée pour ne relever que le gaspillage.
Le procédé se fait en 2 étapes. D’abord, on regroupe les appels au même outil avec les mêmes arguments, puis on vérifie si le sha256 de la sortie est exactement identique. Si la sortie diffère, cela signifie que l’état a changé, donc ce n’est pas détecté.
Il n’y a aucun jugement par LLM. Si vous fournissez la même trace, vous obtenez toujours le même résultat.
Le gaspillage détecté est classé en quatre catégories. Répétition d’erreur (nouvelle tentative avec la même erreur sans corriger la cause), réexécution avec effet de bord (rappel d’un outil qui modifie l’état avec les mêmes arguments), zone grise (répétition en lecture seule — pas d’effet de bord, mais consommation de tokens), et non classable. Les outils comme Bash ou PowerShell, dont l’effet peut changer complètement selon le contenu des arguments, ne sont pas jugés sur leur seul nom et sont laissés en non classable.
[Qu’a-t-on trouvé dans les données publiques ?]
En l’exécutant tel quel sur le benchmark Toolathlon (22 modèles frontier × 3 exécutions, 6 780 traces, 176 270 tool spans), j’ai trouvé 8 042 appels en double.
Prendre ce chiffre tel quel serait exagéré. 47 % relèvent de la zone grise (répéter l’annonce de fin de tâche, recréer un répertoire déjà existant, etc.) ; une fois retirés, il reste 4 251 cas. Soit 2,41 % des tool spans.
Le point marquant était 1 343 réexécutions d’outils qui modifient l’état, dont 459 envois d’e-mails répétés avec les mêmes arguments. Cela dit, cette détection signifie seulement que « le même outil a été appelé deux fois avec les mêmes arguments » ; il est impossible de confirmer à partir de la seule trace si l’e-mail est effectivement parti deux fois.
[Ce qui m’a surpris]
Claude Code lui-même était plus efficace que prévu. J’ai mesuré six fois des motifs candidats comme la relecture de fichiers ou les nouvelles tentatives inutiles, et cinq d’entre eux étaient pratiquement absents des sessions réelles de CC. Le cache et la conservation du contexte les bloquent déjà.
Le gaspillage était plus important dans les environnements connectés à plusieurs serveurs MCP. L’écart était d’un facteur 3 entre CC avec 20 outils (0,80 %) et Toolathlon avec 523 outils (2,41 %).
[Limites]
Aucun cas de réduction mesurée n’existe encore. On peut détecter et estimer, mais il n’y a encore aucune donnée montrant qu’une personne a vu cela, corrigé quelque chose, et réellement réduit sa facture.
Les 47 % de zone grise ne sont pas filtrés : ils sont simplement classés et affichés. Déterminer si une répétition en lecture seule constitue un vrai gaspillage dépend du contexte d’exécution, et ce n’est pas à moi d’en juger.
Cursor et Codex ne sont pas encore pris en charge.
Les détecteurs qui échouent à la validation sont abandonnés. J’ai créé un détecteur de relecture de fichiers, mais sur un échantillon de 30 cas sa précision est restée bien en dessous du seuil de 70 % (même avec une lecture généreuse : 3,3 %, et en version stricte : 0 %), donc je l’ai supprimé ; j’ai également laissé les prédictions et les résultats ensemble dans le document de préenregistrement.
[Conclusion...]
Je compte continuer à faire de la recherche et de la validation dans ce domaine !
Désolé, le readme est en anglais…
Si vous l’utilisez, j’aimerais beaucoup recevoir vos retours sur ce qui devrait être amélioré ou ajouté.
Merci de continuer à vous intéresser à clew…!!
1 commentaires
[Pour vous éviter une lecture inconfortable, j’ai ajouté une traduction française du README !]
Clew
Un détecteur déterministe qui repère le travail gaspillé dans les traces d’agents.
Clew lit les traces d’exécutions terminées d’agents IA et repère les étapes qui répètent un travail déjà effectué : rappeler le même outil avec les mêmes arguments, réessayer un appel échoué avec les mêmes arguments, ou rechercher à nouveau des informations déjà présentes dans le contexte. Comme il fonctionne sans jugement par LLM, la même trace donne toujours le même résultat.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Exemple de sortie réelle obtenue sur une session Claude Code publique :
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsPourquoi c’est important
Dans les sessions d’agents IA de code, le gaspillage n’apparaît que sur la facture. Tous les appels d’outils renvoient 200 et rien ne produit d’erreur, donc le gaspillage n’est pas visible. Mais dans la trace, l’agent lit deux fois le même fichier, réessaie un appel échoué avec les mêmes arguments, et rappelle le même outil avec le même payload.
Comme les opérations de lecture représentent 65 à 90 % des tokens dans les sessions d’agents de code, ce gaspillage s’accumule sans se faire remarquer. Les outils d’observabilité montrent les traces, mais n’indiquent pas quelle étape était redondante.
Ce qui est détecté
Clew recherche trois schémas de duplication :
repeat — le même outil/nœud est appelé à plusieurs reprises
requery — le même outil est rappelé avec la même entrée (sortie identique)
pingpong — deux agents s’échangent en substance le même contenu (multi-agent)
Chaque découverte est classée en quatre catégories :
error_repeat — la sortie est une erreur, mais le même appel est répété
side_effect — réexécution d’un outil qui modifie l’état (envoi/écriture/création, etc.)
idempotent — répétition d’un outil en lecture seule/déclaratif (pas d’effet de bord, mais consomme des tokens)
unclassified — outil absent du mapping. L’effet dépend du payload, donc il n’est pas déduit du seul nom de l’outil (Bash/PowerShell, etc.)
[Comment ça fonctionne]
C’est une cascade en 2 étapes :
Porte structurelle — regroupe les appels du même outil avec les mêmes arguments (normalisés)
Porte d’identité — vérifie que le sha256 de la sortie correspond exactement. Si ce n’est pas le cas, l’état a changé, donc ce n’est pas signalé
Un contrôle structurel peu coûteux réduit d’abord les candidats, et le contrôle sémantique coûteux (embeddings + cosinus) n’est exécuté que lorsque c’est nécessaire. Comme il n’y a pas de jugement par LLM, le résultat est déterministe — un point important si vous voulez l’intégrer à la CI.
[Formats d’entrée]
Claude Code — analyse directe du JSONL de session
LangGraph — détection des duplications de chaînes dans les traces
LangChain·CrewAI·AutoGen·LlamaIndex, etc. — parsing des traces instrumentées aux formats standards OpenTelemetry/OpenInference (support du format ; la validation empirique par framework est en cours)
Traces de benchmarks publics (Toolathlon, RedundancyBench)
Les sessions Cursor et Codex ne sont pas encore prises en charge — les formats locaux sont à l’étude.
[Résultats de validation]
Benchmark public (Toolathlon, 6 780 traces, 176 270 tool spans) :
8 042 appels redondants détectés. Parmi eux, 47 % relèvent d’une zone grise (opérations idempotentes, déclarations d’achèvement) ; en les excluant, il reste 4 251 cas (2,41 % des tool spans). C’est environ 3× plus que dans les sessions Claude Code (0,80 %).
1 343 réexécutions d’outils modifiant l’état, dont 459 envois d’e-mails répétés avec les mêmes arguments. Il s’agit toutefois d’une détection d’appels redondants au même outil avec les mêmes arguments ; il n’a pas été vérifié si un effet de bord s’est réellement produit.
Benchmark labellisé (RedundancyBench) :
precision 0.826 (estimation basse pour les doublons au sein d’un fichier). Une grande partie des labels RB concerne des doublons entre fichiers (cross-file), hors du périmètre d’une analyse conçue au niveau session. Le recall est faible, à 0.157.
[Limites honnêtes]
Il n’y a pas encore de cas mesuré d’économies. L’outil peut détecter et estimer, mais il existe 0 donnée before/after montrant qu’un utilisateur réel a corrigé quelque chose et que sa facture a effectivement baissé.
47 % des éléments signalés dans le benchmark relèvent d’une zone grise (réexécutions idempotentes). Ils ne sont pas filtrés, seulement classés — car déterminer si une réexécution en lecture seule était du gaspillage dépend d’un contexte qui n’est pas visible.
Une correspondance sha256 exacte est requise, donc la moindre différence dans la sortie empêche le signalement. C’est la raison du faible recall ; la conception privilégie la précision.
Claude Code est exceptionnellement bien optimisé. Sur six schémas candidats de gaspillage mesurés dans de vraies sessions CC, cinq n’y existaient pas. Le gaspillage intéressant est apparu non pas dans CC lui-même, mais dans des environnements MCP multi-outils.
L’estimation de coût (amplification) n’est pas une mesure mais une estimation, et elle n’est possible qu’avec le format Claude Code.
Ce qui n’est pas validé est abandonné
J’avais créé un détecteur de relecture de fichiers, puis je l’ai abandonné après qu’une annotation humaine sur un échantillon de 30 cas a montré une précision très inférieure au seuil préenregistré (70 %) : 3,3 % dans une lecture généreuse, 0 % dans une lecture stricte. Les prédictions et les résultats ont été conservés ensemble dans le document de préenregistrement.