Was ist Chisel?
Chisel beantwortet drei Fragen, die ein Coding-Agent nach einer Codeänderung hat: welche Tests laufen sollten, welche Dateien riskant sind und wer diesen Code kennt. Es liest die versionierten Dateien eines Repositorys mit einem eigenen Extraktor (ohne tree-sitter), verknüpft jeden Test mit den Funktionen und Klassen, die er aufruft, wertet die Git-Historie nach Änderungshäufigkeit, gemeinsamer Änderung und Autorschaft aus und legt das Ergebnis in einem einzigen JSON-Snapshot unter `.chisel/store` ab. Agenten erreichen es über MCP auf stdio oder über eine JSON-CLI.
Es registriert 29 MCP-Tools in sechs Gruppen; nur die sieben Core-Tools (analyze, update, diff_impact und Co.) sind immer aktiv, und `CHISEL_DISABLE` oder eine Zeile in der AGENTS.md des Projekts blendet den Rest aus. Ein Claude-Code-Hook kann jeden Testlauf an `chisel capture` weiterreichen, das Fehlschläge als Issues erfasst, den seit dem letzten erfolgreichen Lauf geänderten Code nach Verdacht ordnet und das Issue mit dem behebenden Commit schließt. Chisel steht unter MIT-Lizenz, ist nur mit der Rust-Standardbibliothek ohne Crates gebaut und erschien am 11. November 2026 in Version v0.23.0.
Chisel installieren
chisel serve-mcp (release binary from GitHub, with CHISEL_PROJECT_DIR set)Lohnt sich Chisel?
Die meisten Code-Graph-MCP-Server helfen einem Agenten, weniger Code zu lesen. Chisel zielt auf den Schritt nach der Änderung: Der Agent ruft diff_impact auf, erhält eine geordnete Liste der Tests, die die geänderten Funktionen aufrufen, und danach der Tests ihrer Aufrufer, standardmäßig zwei Ebenen nach oben, und führt diese statt der ganzen Suite oder einer Vermutung aus. Der Benchmark des Maintainers auf dem Django-Paket mit rund 1000 Codedateien nennt für eine kalte Analyse etwa 8 Sekunden und für ein warmes Update etwa 69 Millisekunden.
Ungewöhnlicher ist das Fehlerprotokoll. Mit installiertem PostToolUse-Hook wird jeder Testlauf des Agenten (cargo test, pytest, Jest, Vitest, go test, node:test) ohne Modell-Tokens auf Fehlschläge ausgewertet, Duplikate werden zusammengefasst, und jedes Issue nennt verdächtige Änderungen mit einer einzeiligen Begründung. Die nächste Sitzung beginnt mit höchstens zwei Zeilen zu offenen Issues, was einem Agenten hilft, der vergessen hat, was gestern kaputtging.
Der Haken: Die Verbreitung ist nahe null. Das Repository hat 7 GitHub-Sterne und einen Fork, und 115 seiner 120 Commits stammen von einer Person; du wettest also auf deren Tempo. Es bewegt sich schnell, mit 30 Releases seit v0.5.4 im März 2026, und die GitHub-Beschreibung wirbt noch mit 15 MCP-Tools, während die README 29 aufführt. Der Abgleich ist heuristisch statt typgeprüft, die README warnt, dass ihre Risikowerte Heuristiken sind, und oberhalb von 2000 Codedateien entfällt die Änderungshäufigkeit pro Funktion. Die optionale HTTP-API (`chisel serve`) bindet standardmäßig an 127.0.0.1 und hat nach unserer Lektüre des Quelltexts keine Authentifizierung; gib sie also nicht über den Rechner hinaus frei.
Unser Fazit: Chisel ist ein scharfes Zusatzwerkzeug, keine Code-Intelligence-Plattform. Hat dein Agent schon GitNexus oder codebase-memory-mcp für die Navigation, füllen Chisels Testauswahl und Fehlerverfolgung eine Lücke, die diese lassen; schalte seine Lock- und History-Gruppen ab, damit sich nichts überschneidet.
Wo es sich lohnt
Ein Backend-Entwickler mit einer langsamen pytest-Suite
Verhindern, dass der Agent nach jeder kleinen Änderung alle Tests ausführt
Einmal analyze aufrufen, dann den Agenten nach jeder Änderung diff_impact aufrufen und nur die geordneten Tests ausführen lassen, mit einem vollständigen Lauf vor dem Merge. Kostenlos; die Ersparnis sind die Minuten Suite-Laufzeit pro Änderung.
Eine Solo-Maintainerin, die Claude Code in mehreren Sitzungen am Tag nutzt
Nachhalten, welche Tests der Agent kaputt gemacht hat und was sie repariert hat
Mit `chisel hook-install --write` die Capture- und SessionStart-Hooks ergänzen; Fehlschläge werden zu deduplizierten Issues, die sich mit dem behebenden Commit automatisch schließen, sobald der Test wieder besteht.
Ein Tech Lead, der den Pull Request eines Agenten prüft
Sehen, welche geänderten Dateien riskant sind und wer sie reviewen sollte
`chisel triage` und `who_reviews` auf dem Branch ausführen, um Änderungshäufigkeit, Kopplung, ungetesteten Code und aktuelle Verantwortliche zu sehen. Die Werte sind Heuristiken, also eine Startliste, kein Gate.
Bevor du dich festlegst
- Einrichtung
- Release-Binärdatei für Linux, macOS oder Windows herunterladen (oder `cargo build --release`), mit installiertem git in den PATH legen, `chisel serve-mcp` mit CHISEL_PROJECT_DIR in .mcp.json eintragen und einmal analyze aufrufen.
- Integrationen
- Jeder stdio-MCP-Client, etwa Claude Code, Cursor, Windsurf und Cline; eine JSON-CLI; eine separate lokale HTTP-API; Claude-Code-Hooks für die Testerfassung; eine mitgelieferte SKILL.md. Extrahiert Code aus 12 Sprachfamilien und erkennt pytest, Jest, Go test, Rust-Tests, JUnit und weitere.
- Daten und Datenschutz
- Läuft lokal und speichert den Snapshot in `<project>/.chisel/store`; es gibt keinen gehosteten Dienst. Die HTTP-API bindet standardmäßig an 127.0.0.1 ohne Authentifizierung. In einer Repo-Datei genannte eigene Extraktoren laufen nur, wenn sie ausdrücklich mit --allow-repo-extractor erlaubt werden.
- Kosten im großen Maßstab
- Kostenlos unter MIT, ohne Bezahlversion. Große Repositorys lassen sich in Shards aufteilen, jeder mit eigenem Snapshot.
- Grenzen
- Werte sind Heuristiken; die Änderungshäufigkeit pro Funktion entfällt oberhalb von 2000 Codedateien; das automatische Update läuft nur bei höchstens 50 geänderten Dateien inline; Worktree-Antworten werden mit konfigurierten Shards nicht unterstützt.
Was gut ist
- Ordnet die Tests, die eine Änderung erreicht, über Aufrufer zwei Ebenen nach oben
- Erfasst Testfehler des Agenten als Issues mit Verdächtigen, ohne Modell-Tokens
- Eine abhängigkeitsfreie Rust-Binärdatei; nur git wird benötigt
- Tool-Gruppen reduzieren die 29 Tools auf 7 Core-Tools
Was nicht
- 7 Sterne und ein einziger Hauptautor
- Heuristischer Abgleich, keine Typauflösung
- Änderungshäufigkeit pro Funktion endet oberhalb von 2000 Codedateien
- HTTP-API ohne Authentifizierung
Am besten für
Entwickler, die einen Coding-Agenten in einem gut getesteten Repository arbeiten lassen und wollen, dass er die richtigen Tests ausführt, nicht alle.
Alternativen zu Chisel
Chisel: häufige Fragen
- Lohnt sich Chisel?
- Chisel erledigt etwas Nützliches, das größere Code-Graphen auslassen, nämlich die Tests auszuwählen, die eine Änderung tatsächlich berührt, ist aber ein Ein-Personen-Projekt, das kaum ein Team ausprobiert hat. Wir bewerten es mit 3.5 von 5.
- Was kostet Chisel?
- Kostenlos und Open Source (MIT).
- Welche Nachteile hat Chisel?
- 7 Sterne und ein einziger Hauptautor; Heuristischer Abgleich, keine Typauflösung; Änderungshäufigkeit pro Funktion endet oberhalb von 2000 Codedateien; HTTP-API ohne Authentifizierung.
- Für wen eignet sich Chisel?
- Entwickler, die einen Coding-Agenten in einem gut getesteten Repository arbeiten lassen und wollen, dass er die richtigen Tests ausführt, nicht alle.
- Was kostet Chisel für ein Team oder im Produktivbetrieb?
- Kostenlos unter MIT, ohne Bezahlversion. Große Repositorys lassen sich in Shards aufteilen, jeder mit eigenem Snapshot.
- Ist Chisel sicher für Firmendaten?
- Läuft lokal und speichert den Snapshot in `<project>/.chisel/store`; es gibt keinen gehosteten Dienst. Die HTTP-API bindet standardmäßig an 127.0.0.1 ohne Authentifizierung. In einer Repo-Datei genannte eigene Extraktoren laufen nur, wenn sie ausdrücklich mit --allow-repo-extractor erlaubt werden.
- Was sind die besten Alternativen zu Chisel?
- Die nächsten Alternativen, die wir getestet haben, sind code-review-graph, codebase-memory-mcp und GitNexus.
Antworten geprüft am 13. Nov. 2026.