10 Claude Code Mods getestet: 3 bleiben, 7 fliegen

Claude Code Mods sind TypeScript-Funktionen in Plugins, die die Oberfläche von Claude Code neu zeichnen oder umschreiben können, was es tut. Innerhalb eines Tages nach ihrem Launch Anfang Oktober forderten drei verschiedene Video-Touren Entwickler auf, zehn davon zu installieren. Zwei dieser Creator geben vor der Kamera zu, dass manche Mods nichts einsparen, und keiner von ihnen hat auch nur einen einzigen gemessen. Dieser Test tut es: Alle zehn gehypten Mods liefen auf einer echten Arbeitswoche, mit einer Zahl für Overhead, Ersparnis und einem Behalten-oder-Löschen-Urteil. Das Ergebnis vorab: Nur drei der zehn verdienen einen Platz auf dem Rechner eines arbeitenden Entwicklers, und einer davon verbraucht bei jeder einzelnen Antwort still Tokens.

Anthropics eigene Definition passt in einen Atemzug: Ein Mod ist eine Funktion, die sich in ein Event einklinkt und davor, danach oder stattdessen laufen kann. Ein Event ist ein Tool-Call, ein abgeschickter Prompt oder ein Teil der Oberfläche beim Zeichnen. Mods sind reines TypeScript, ausgeliefert in einem Plugin, das du wie jedes andere installierst.

Der Launch-Tweet knackte in etwa einem Tag vier Millionen Views, mit zwanzigtausend Likes und mehr Lesezeichen als Antworten und Reposts zusammen. Zwei Tage nach dem Launch hatte ein Community-Katalog bereits mehr als tausend öffentliche Mods in Hunderten von Repositories gescannt.

Der Prüfstand für diesen Test ist eine echte Arbeitswoche: 85 Sessions in vier Projekten, fast 900 Prompts und knapp 6.000 Tool-Calls. Jeder Mod durchlief den Audit des Validators, der auflistet, worin er sich einklinkt und was er berühren kann, und jeder Mod führte dieselbe Aufgabe gegen eine saubere Baseline aus, auf dem aktuellen Release, auf derselben Maschine.

Die Kernaufteilung: Sechs der zehn kosten zur Laufzeit nichts Messbares, drei kosten echte Zeit oder echte Tokens, und einer bricht das einzige Versprechen, das er macht.

Die stillen sechs liegen im Rauschen der Verbindung. Die Zielanzeige, die Repo-Heatmap, der Flight Recorder, der Modell-Router, die Session-Lesezeichen und der Auto-Handoff liegen alle zwischen einer Viertelsekunde gespart und einer Fünftelsekunde zusätzlich, bei einer Baseline-Aufgabe von etwa vier Sekunden.

Mod	Laufzeit-Delta	Anmerkungen
Zielanzeige	im Rauschen	Deko-Panel
Repo-Heatmap	im Rauschen	lässt Dateien aufleuchten, sobald sie gelesen werden
Flight Recorder	im Rauschen	Live-Timeline des Turns
Modell-Router	im Rauschen	zahlt sich bei Subagents aus, siehe Urteil
Session-Lesezeichen	im Rauschen	große Berechtigungsreichweite
Auto-Handoff	~70 ms im Leerlauf	schreibt einen Handoff bei einem Kontext-Schwellenwert

Sie sehen großartig aus, und nichts ist kaputtgegangen: Jeder Lauf jeder Konfiguration hat die Aufgabe korrekt beendet. Headless kosten sie nichts, weil es nichts zu zeichnen gibt; in einem Terminal zeichnen sich diese Panels bis zu dreißigmal pro Sekunde neu, die ehrlichen Kosten der Deko-Stufe sind also Aufmerksamkeit statt Tokens.

Beim Audit des Validators hört der Spaß auf. Der Lesezeichen-Mod kann das Modell aufrufen, Prozesse auf deiner Maschine starten und Dateien schreiben, und er liest deine Konfigurationspfade aus der Umgebung. Nichts davon ist versteckt, und nichts davon ist bösartig, aber es ist sehr viel Reichweite für ein Lesezeichen. Vier Mods scheiden hier aus: die Zielanzeige, die Heatmap und der Flight Recorder als Deko ohne gemessenen Nutzen, und der Lesezeichen-Mod, weil er mehr verlangt, als er einbringt.

Die Vorschlags-Engine ist der Mod, den jedes Video zuerst vorführt: Deine Antwort ist fertig, drei Prompt-Vorschläge erscheinen über dem Eingabefeld, du drückst eine Zahl, und der Entwurf füllt sich von selbst. Der Mechanismus ist von seinem eigenen Autor dokumentiert: Wenn dein Turn abgeschlossen ist, forkt er die Session, um ein Modell nach diesen Vorschlägen zu fragen, und der Fork teilt sich den Prompt-Cache der Session, kostet also etwa eine kurze Antwort. Diese Zeile erwähnen die Touren nie.

Auf dem Prüfstand gemessen sind das etwa 250 zusätzliche Output-Tokens pro qualifizierender Antwort und fast drei Sekunden zusätzliche Wartezeit, und eine qualifizierende Antwort ist fast jede Antwort: alles, was länger als etwa achtzig Zeichen ist. Der Fork hat außerdem keine Oberflächenprüfung. Die Vorschläge werden nur in einem Terminal gezeichnet, aber der Fork feuert überall, auch in Headless-Läufen, in denen gar nichts gezeichnet werden kann.

Mod	Gemessene Kosten	Wann er feuert
Vorschlags-Engine	~250 Output-Tokens + ~2,9 s pro qualifizierender Antwort	jede Antwort über ~80 Zeichen, auch headless
Cache Keeper	~1,5 s pro Turn, plus Modellaufrufe im Warming-Modus	jeder Turn, stundenlang Warming

Der Cache Keeper hat dieselbe Form: etwa anderthalb Sekunden pro Turn, mit einem Warming-Modus, der stundenlang kleine Modellaufrufe verbraucht, damit dein Prompt-Cache nicht kalt wird. Bei einem Abo-Tarif beträgt das Cache-Fenster ohnehin schon eine Stunde, du zahlst also Pings, um ein Problem zu lösen, das der Tarif größtenteils schon gelöst hat. Beide sind ehrliche Designs mit dokumentierten Kosten, beide sind Steuern auf jeden Turn, die die Installationslisten nie beziffern, und beide fliegen von der Maschine.

Claude Code hatte schon vorher Hooks: ein Shell-Skript in deinen Settings, das bei denselben Events feuert. Die Dokumentation beantwortet die Wahl in einer Tabellenzeile: Ein Mod ist für die Oberfläche und für das Umschreiben von Events; ein Hook ist zum Blocken, Erlauben oder Loggen mit einem Skript, das du schon hast.

Der messbare Unterschied ist der Prozessstart. Ein Settings-Hook startet bei jedem Tool-Call einen frischen Prozess. Auf dieser Maschine gemessen kostet ein Shell-Hook, der nichts tut, etwa 8 ms und ein Hook, der Node startet, etwa 43 ms, bei jedem einzelnen Call, bevor das Skript irgendetwas macht. Über die 5.993 Tool-Calls der Prüfstandswoche sind das mehr als vier Minuten reiner Interpreter-Start. Ein Mod zahlt nichts davon: Sein Handler läuft im eigenen Prozess der Engine, und das Log der Engine zeigt, dass der Sprung sich bei etwa einer Millisekunde einpendelt.

Handler	Kosten pro Call	Eine Woche mit 5.993 Calls
Shell-Hook (No-op)	~8 ms	~48 s
Node-Hook (No-op)	~43 ms	~4,3 min
Mod (im selben Prozess)	~1 ms	~6 s

Der einzige echte Migrationsbericht da draußen sagt dasselbe: siebenundzwanzig Shell-Hooks wurden zu fünf Mods zusammengelegt, und der Prozessstart bei jedem Call verschwand damit. Die Regel, die bleibt: Oberfläche oder Event-Umschreiben, Mod; blocken, erlauben oder loggen mit einem Skript, dem du traust, Hook — der Spawn-Aufwand fällt erst bei tausenden Calls ins Gewicht; Wissen, das du ständig wiederholst, Skill. Ein Hook, den du gelesen hast, schlägt einen Mod, den du nicht gelesen hast.

Der einfachste denkbare Sicherheits-Mod ist ein Wächter, der jeden Shell-Befehl beobachtet — und dieser hier wurde geschrieben, um abzustürzen. Claude Code sollte eine Marker-Datei anlegen; der Wächter warf einen Fehler; der Befehl lief trotzdem, und die Datei erschien. Das ist kein Bug, sondern das dokumentierte Standardverhalten: Wenn ein Hook einen Fehler wirft, in ein Timeout läuft oder das falsche Format zurückgibt, überspringt Claude Code ihn und macht weiter. Eine kaputte Deko soll eine Session nicht lahmlegen, aber ein kaputter Wächter ist fail-open, still, mit einer einzigen Zeile in einem Debug-Log, das niemand liest.

Die Lösung ist ein Catch-Handler, der ein Deny zurückgibt. Derselbe abstürzende Wächter mit dem Catch verweigert den Befehl und benennt den Fehler. Eine Zeile entscheidet, ob ein Wächter fail-open oder fail-closed ist, die Dokumentation liefert genau dieses Muster mit, und fast niemand installiert es.

Ein Community-Team hat die Fälle auf dem aktuellen Release erneut durchgespielt und nach Marker-Dateien statt nach dem geurteilt, was das Modell sagte. Das Catch-Muster war drei von drei Läufen fail-closed — und ein Pfad ist weiterhin still kaputt: Ein Deny, das zurückgegeben wird, nachdem der Call schon weitergeleitet wurde, stoppt das Tool nicht. Die Datei landete dreimal von dreimal auf der Platte, während dem Modell gesagt wurde, das Schreiben sei fehlgeschlagen.

Der Erfahrungsbericht, der dieses Problem benannt hat, betrieb tagelang einen Wächter, der aktiviert, geladen und wirkungslos war, weil ein veraltetes Flag ihn darunter ausgeschaltet hatte: drei grüne Status-Chips über einem Zähler, der auf null feststeckte. Stille, die genau wie Gesundheit aussieht.

Der Kollisionswächter verdient das erste Behalten. Er löst ein echtes Problem — zwei offene Chats, die dieselbe Datei bearbeiten — und seine Fehlerart ist laut: Er fragt in einem Dialog und erlaubt nie still. Er kostet etwa eine halbe Sekunde bei Edits und fügt dem Prompt nichts hinzu. Installiere ihn und gib ihm trotzdem den Catch-Handler.

Anthropic sagt es am Launch-Tag in klaren Worten: Mods laufen mit demselben Zugriff auf deine Maschine wie Claude Code selbst. Sie sind nicht gesandboxt; installiere sie so, wie du jeden Code auf deinem Computer installieren würdest. Konkret kann ein Mod auf deiner Maschine als du handeln: deine Umgebung und Settings lesen, wo API-Keys liegen; jeden Prompt und jeden Tool-Call sehen; sie umschreiben; einen Tool-Call freigeben, bevor du überhaupt gefragt wirst; und das Nutzungskontingent deines Tarifs für eigene Modellaufrufe ausgeben.

Zwei Fallen erwischen selbst vorsichtige Nutzer. Permission-Regeln gelten für Claudes Tool-Calls, nicht für die eigenen Calls des Mods: Verweigere Claude eine Env-Datei, und ein Mod kann diese Datei trotzdem direkt mit seinem eigenen Dateizugriff lesen oder ein Programm starten, das es tut. Die Netzwerk-Policy hat dieselbe Kante: Schaltest du den Web-Traffic ab, werden die eigenen Fetch-Calls des Mods abgelehnt, aber ein Kindprozess, den der Mod startet, erreicht das Netzwerk mit vollem Zugriff. Es gibt einen eingebauten Wächter-Mod, der vor allem anderen lädt, aber nur auf verwalteten Maschinen und für Team- oder Enterprise-Seats; ein Solo-Seat mit privatem Abo bekommt davon nichts.

Nichts davon ist theoretisch. Ein Nutzer veröffentlichte Tage nach dem Launch einen Proof of Concept: ein Mod, dessen Button ein Programm startet und ins Home-Verzeichnis schreibt, installiert aus dem Katalog ohne jede Warnung — und sein Punkt bleibt bestehen: Der Katalog sieht aus wie ein App Store, was eine Prüfung nahelegt, die es nicht gibt. Ein separater Hook-Bug brach einen Tag lang die Subagent-Isolation; der Maintainer nannte es einen großen Schnitzer und behob ihn ein Release später.

Der eigene Scan des Katalogs über mehr als tausend öffentliche Mods: über vierhundert starten Host-Prozesse, fast vierhundert lesen Dateien, und über dreihundert sehen jeden Tool-Call. Der Vorbehalt des Katalogs ist der richtige Rahmen — das ist ein Fußabdruck, kein Urteil; ein PR-Tracker muss git ausführen. Die Disziplin kostet zwei Minuten: Lass den Validator laufen, bevor du irgendetwas aktivierst, und kenne die Ausgänge — Safe Mode für eine Session, eine Einstellung, um jeden installierten Hook dauerhaft zu stoppen.

Von den zehn verdienen drei ihren Platz: der Kollisionswächter, der Modell-Router und der Auto-Handoff.

Mod	Urteil	Die Zahl dahinter
Kollisionswächter	behalten	~0,5 s bei Edits, scheitert laut, nichts im Prompt ergänzt
Modell-Router	behalten	Subagent auf dem günstigen Modell abgerechnet, ein Drittel des Preises
Auto-Handoff	behalten	70 ms Nichts, ein Handoff-Schreibvorgang beim Kontext-Schwellenwert
Vorschlags-Engine	löschen	~250 Output-Tokens + ~2,9 s bei jeder qualifizierenden Antwort
Cache Keeper	löschen	~1,5 s pro Turn, Warming-Pings gegen ein 1-Stunden-Cache-Fenster
Recording-Modus	löschen	maskiert den Bildschirm, aber nicht die Platte
Zielanzeige	löschen	Deko, null gemessener Nutzen
Repo-Heatmap	löschen	Deko, null gemessener Nutzen
Flight Recorder	löschen	Deko, null gemessener Nutzen
Session-Lesezeichen	löschen	Reichweite weit über den Job hinaus

Der Modell-Router hat einen Beleg: Eine Session auf dem großen Modell startete einen Subagent, und die eigene Nutzungsanzeige des Laufs zeigte den Subagent auf dem günstigen Modell abgerechnet, ein Drittel des Preises für denselben kleinen Job. In Wochen mit vielen Subagents ist das echtes Geld. Der Auto-Handoff kostet nichts bis zu dem Moment, in dem er sich auszahlt: siebzig Millisekunden Leerlauf-Overhead, und oberhalb eines Kontext-Schwellenwerts schreibt er einmal den Handoff für den Kaltstart. Einer der Creator der Welle gibt zu, dass der manuelle Handoff-Button nicht wirklich Zeit spart; als automatischer Schwellenwert-Schreibvorgang tut er es tatsächlich.

Die Disziplin, die den Test überlebt: Lies den Audit des Validators, bevor du irgendetwas aktivierst, gib jedem Wächter seinen Catch-Handler, damit er fail-closed ist, und nimm Demos im Safe Mode auf, statt einem maskierenden Mod zu vertrauen. Die Grenzen sind real — eine Woche, eine Maschine, eine Arbeitslast, drei Läufe pro Messpunkt auf dem kleinen Modell. Deine drei können anders aussehen, aber jetzt weißt du, wie du sie findest.