Qu’est-ce que Chisel ?
Chisel répond à trois questions qu'un agent de code se pose après avoir modifié du code : quels tests lancer, quels fichiers sont risqués et qui connaît ce code. Il parcourt les fichiers suivis du dépôt avec son propre extracteur (sans tree-sitter), relie chaque test aux fonctions et classes qu'il appelle, exploite l'historique git pour la fréquence des changements, le couplage par modifications conjointes et la paternité, et range le résultat dans un unique instantané JSON sous `.chisel/store`. Les agents y accèdent par MCP sur stdio ou via une CLI JSON.
Il enregistre 29 outils MCP en six groupes ; seuls les sept outils core (analyze, update, diff_impact et consorts) sont toujours actifs, et `CHISEL_DISABLE` ou une ligne dans le AGENTS.md du projet masque le reste. Un hook Claude Code peut transmettre chaque exécution de tests à `chisel capture`, qui consigne les échecs comme des tickets, classe le code modifié depuis le dernier passage réussi du test et ferme le ticket avec le commit correctif. Chisel est sous licence MIT, construit avec la seule bibliothèque standard de Rust, sans crates, et a publié la v0.23.0 le 11 novembre 2026.
Installer Chisel
chisel serve-mcp (release binary from GitHub, with CHISEL_PROJECT_DIR set)Chisel vaut-il le coup ?
La plupart des serveurs MCP de graphe de code aident un agent à lire moins de code. Chisel vise l'étape d'après : l'agent appelle diff_impact, reçoit une liste classée des tests qui appellent les fonctions modifiées puis des tests de leurs appelants, deux niveaux plus haut par défaut, et lance ceux-là au lieu de toute la suite ou d'une supposition. Le benchmark du mainteneur sur le paquet Django, environ 1000 fichiers de code, donne une analyse à froid d'à peu près 8 secondes et une mise à jour à chaud d'environ 69 millisecondes.
Le journal des échecs est la partie la plus originale. Avec le hook PostToolUse installé, chaque exécution de tests de l'agent (cargo test, pytest, Jest, Vitest, go test, node:test) est analysée sans dépenser de tokens de modèle, les doublons sont regroupés et chaque ticket liste les changements suspects avec une raison d'une ligne. La session suivante démarre avec au plus deux lignes qui nomment les tickets ouverts, ce qui aide un agent qui a oublié ce qui a cassé la veille.
Le hic : l'adoption est quasi nulle. Le dépôt compte 7 étoiles sur GitHub et un fork, et 115 de ses 120 commits viennent d'un seul auteur ; vous pariez donc sur le rythme de cette personne. Le projet évolue vite, avec 30 versions depuis la v0.5.4 en mars 2026, et la description GitHub annonce encore 15 outils MCP alors que le README en liste 29. La correspondance est heuristique et non vérifiée par les types, le README prévient que ses scores de risque sont des heuristiques et, au-delà de 2000 fichiers de code, la fréquence de changement par fonction est ignorée. L'API HTTP optionnelle (`chisel serve`) écoute sur 127.0.0.1 par défaut et, d'après notre lecture du code source, n'a aucune authentification ; ne l'exposez donc pas au-delà de la machine.
Notre avis : Chisel est un outil d'appoint affûté, pas une plateforme d'intelligence de code. Si votre agent dispose déjà de GitNexus ou de codebase-memory-mcp pour naviguer, la sélection de tests et le suivi des échecs de Chisel comblent un manque qu'ils laissent ; désactivez ses groupes locks et history pour éviter les doublons.
Là où il fait la différence
Un développeur backend avec une suite pytest lente
Empêcher l'agent de lancer tous les tests après chaque petite modification
Appeler analyze une fois, puis faire appeler diff_impact à l'agent après chaque changement pour ne lancer que les tests classés, avec une exécution complète avant la fusion. Gratuit ; le gain, ce sont les minutes de suite par modification.
Une mainteneuse seule qui utilise Claude Code sur plusieurs sessions par jour
Savoir quels tests l'agent a cassés et ce qui les a réparés
Lancer `chisel hook-install --write` pour ajouter les hooks de capture et SessionStart ; les échecs deviennent des tickets dédoublonnés qui se ferment d'eux-mêmes avec le commit correctif quand le test repasse.
Un responsable technique qui relit la pull request d'un agent
Voir quels fichiers modifiés sont risqués et qui devrait les relire
Lancer `chisel triage` et `who_reviews` sur la branche pour la fréquence des changements, le couplage, le code non testé et les responsables actuels. Les scores sont des heuristiques : une liste de départ, pas un verrou.
Avant de vous engager
- Mise en route
- Télécharger un binaire de version pour Linux, macOS ou Windows (ou `cargo build --release`), le placer dans le PATH avec git installé, ajouter `chisel serve-mcp` avec CHISEL_PROJECT_DIR à .mcp.json, puis appeler analyze une fois.
- Intégrations
- Tout client MCP stdio, dont Claude Code, Cursor, Windsurf et Cline ; une CLI JSON ; une API HTTP locale distincte ; des hooks Claude Code pour capturer les tests ; un SKILL.md fourni. Extrait le code de 12 familles de langages et reconnaît pytest, Jest, Go test, les tests Rust, JUnit et d'autres.
- Données et confidentialité
- Tourne en local et stocke son instantané dans `<project>/.chisel/store` ; aucun service hébergé. L'API HTTP écoute sur 127.0.0.1 par défaut, sans authentification. Les extracteurs personnalisés désignés dans un fichier du dépôt ne s'exécutent que s'ils sont explicitement autorisés avec --allow-repo-extractor.
- Coût à grande échelle
- Gratuit sous MIT, sans édition payante. Les grands dépôts peuvent être découpés en shards, chacun avec son propre instantané.
- Limites
- Les scores sont des heuristiques ; la fréquence par fonction est ignorée au-delà de 2000 fichiers de code ; la mise à jour automatique ne se fait en ligne qu'avec 50 fichiers modifiés ou moins ; les réponses pour les worktrees ne sont pas prises en charge avec des shards configurés.
Les points forts
- Classe les tests qu'atteint une modification, en remontant deux niveaux d'appelants
- Consigne les échecs de tests de l'agent comme tickets avec suspects, sans tokens de modèle
- Un binaire Rust sans dépendances ; seul git est requis
- Les groupes d'outils réduisent les 29 outils à 7 outils core
Les points faibles
- 7 étoiles et un seul auteur principal
- Correspondance heuristique, sans résolution de types
- La fréquence par fonction s'arrête au-delà de 2000 fichiers de code
- L'API HTTP n'a pas d'authentification
Idéal pour
Les développeurs qui laissent un agent de code modifier un dépôt bien testé et veulent qu'il lance les bons tests, pas tous.
Alternatives à Chisel
Chisel : questions fréquentes
- Chisel vaut-il le coup ?
- Chisel fait une chose utile que les grands graphes de code négligent, choisir les tests qu'une modification touche vraiment, mais c'est un projet d'une seule personne que très peu d'équipes ont essayé. Nous lui donnons 3.5 sur 5.
- Combien coûte Chisel ?
- Gratuit et open source (MIT).
- Quels sont les inconvénients de Chisel ?
- 7 étoiles et un seul auteur principal; correspondance heuristique, sans résolution de types; la fréquence par fonction s'arrête au-delà de 2000 fichiers de code; l'API HTTP n'a pas d'authentification.
- À qui s’adresse Chisel ?
- Les développeurs qui laissent un agent de code modifier un dépôt bien testé et veulent qu'il lance les bons tests, pas tous.
- Combien coûte Chisel pour une équipe ou en production ?
- Gratuit sous MIT, sans édition payante. Les grands dépôts peuvent être découpés en shards, chacun avec son propre instantané.
- Chisel est-il sûr pour les données de l’entreprise ?
- Tourne en local et stocke son instantané dans `<project>/.chisel/store` ; aucun service hébergé. L'API HTTP écoute sur 127.0.0.1 par défaut, sans authentification. Les extracteurs personnalisés désignés dans un fichier du dépôt ne s'exécutent que s'ils sont explicitement autorisés avec --allow-repo-extractor.
- Quelles sont les meilleures alternatives à Chisel ?
- Les alternatives les plus proches que nous avons testées sont code-review-graph, codebase-memory-mcp et GitNexus.
Réponses vérifiées le 13 nov. 2026.