Agent-Blackbox - un outil pour visualiser l’exécution de Claude Code/OpenCode avec une carte de session et une analyse du gaspillage de tokens

J’ai créé Agent-Blackbox, un outil qui enregistre localement les exécutions de Claude Code / OpenCode et les affiche sous forme de carte de session et de score d’efficacité du contexte.

Une étude a montré que si l’on demande à une IA « combien de tokens penses-tu utiliser pour cette tâche ? », la corrélation avec le coût réel n’est que de 0,39.

https://arxiv.org/abs/2604.22750

Après avoir fait tourner Claude Code ou OpenCode longtemps, cela m’a semblé être un problème très concret. Le résumé final paraît plausible, mais en pratique il est difficile de suivre quels fichiers ont réellement été lus, quelles commandes ont échoué et à quels endroits beaucoup de tokens ont été consommés.

Au lieu d’analyser le dernier résumé de l’agent, Agent-Blackbox enregistre les événements réels.

• lecture / modification de fichiers
• exécution bash et code de sortie
• recherche
• mise à jour des todo
• demandes d’autorisation
• délégation à des sous-agents, utilisation de skills
• flux d’utilisation du modèle / des tokens
• flux de correction / nouvelle tentative après un échec, etc.

Il peut être lancé directement avec npx, sans installation.

Enregistrement de Claude Code :
npx @taewooopark/agent-blackbox up --host claude-code

Enregistrement d’OpenCode :
npx @taewooopark/agent-blackbox up --host opencode

Enregistrement des deux :
npx @taewooopark/agent-blackbox up --host all

Claude Code surveille les transcriptions ~/.claude/projects sans installation supplémentaire. OpenCode reçoit les événements via un plugin global. L’enregistrement de base et le dashboard fonctionnent en local, sans API key.

J’y ai aussi ajouté une analyse de l’efficacité du contexte. Par exemple, elle détecte ce type de situations :

• relecture répétée du même fichier
• lecture d’un trop grand nombre de fichiers par rapport au volume réellement modifié
• sorties de commande/tool volumineuses qui occupent une grande partie du contexte
• répétition de commandes en échec sans correction de la cause
• forte consommation de tokens pour très peu de changements réels
• faible utilisation du prompt cache

Comme les problèmes sont affichés au niveau du nom de fichier ou de la commande concernée, il est possible de voir assez concrètement quoi réduire lors de l’exécution suivante. En option, les gaspillages détectés peuvent aussi être consignés dans AGENTS.md ou CLAUDE.md sous forme de bloc de gestion, afin que l’exécution suivante répète moins souvent les mêmes erreurs.

Dans un cas où j’ai relancé la même tâche avec le même modèle, la consommation de tokens est passée de 939k à 521k, et le score d’efficacité est monté de 80 à 99. Ce n’est pas un benchmark validé de manière répétée ; il faut plutôt y voir un exemple montrant qu’il est possible de réinjecter dans la boucle suivante les gaspillages observés pendant une exécution réelle.

Cela s’est particulièrement bien combiné avec des harness multi-agents comme oh-my-openagent ou oh-my-claudecode. Plus une exécution se prolonge, plus il devient difficile de vérifier visuellement qui a touché quel fichier et où les répétitions apparaissent.

GitHub :
https://github.com/TaewoooPark/Agent-Blackbox

npm :
https://www.npmjs.com/package/@taewooopark/agent-blackbox

N’hésitez pas à l’essayer, et si vous avez des retours sur les événements que vous aimeriez voir dans la carte de session, les indicateurs d’efficacité ou un flux d’installation peu pratique, je suis preneur. Merci !

[turtlehwan]

Oh, c’est vraiment fascinant ! Je trouve que c’est une bonne idée.

[theoverstructure]

Merci beaucoup ! J’ai aussi peaufiné l’UI avec soin, donc je pense que vous trouverez ça encore plus intéressant en l’essayant. Merci sincèrement pour vos gentils mots !!

[theoverstructure]

Je l’ai créé surtout parce que, lors de longues exécutions de Claude Code/OpenCode ou de travaux multi-agents, je voulais voir d’un coup d’œil quels fichiers avaient été relus en boucle, quelles commandes avaient échoué et à quels endroits les tokens fuyaient le plus. Comme je le développe encore seul, il y a encore pas mal de points à améliorer. Si vous l’essayez, je vous serais vraiment reconnaissant pour vos retours du type « cet événement mériterait aussi d’être affiché », « cet indicateur d’efficacité est discutable » ou « le flux d’installation/exécution n’est pas pratique » !!