Der Grund, warum Token-Verschwendung nicht sichtbar ist: Es sind keine Fehler, sondern Duplikate. Dieselbe Datei zweimal lesen, mit denselben Argumenten erneut versuchen, dasselbe Tool noch einmal aufrufen. Deshalb habe ich ein CLI gebaut, das abgeschlossene Traces liest und zeigt, welcher Step etwas wiederholt hat, was bereits erledigt war!
[Ausprobieren]
pip install "clew-custos[detect]" python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Es läuft lokal und ohne Anmeldung. Da kein torch heruntergeladen wird, ist die Installation in wenigen Sekunden erledigt. Python 3.12 oder höher. Claude-Code-Session-Dateien liegen unter ~/.claude/projects/.
Das ist eine echte Ausgabe, ausgeführt auf einer öffentlichen Claude-Code-Session (258 Turns):
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)
[Wie wird das bewertet?]
Es speichert und visualisiert keine Traces wie Langfuse oder Phoenix. Es liest bereits abgeschlossene Traces und markiert nur die Verschwendung.
Es läuft in zwei Schritten. Zuerst werden Aufrufe desselben Tools mit denselben Argumenten gruppiert, danach wird geprüft, ob der sha256 der Ausgabe exakt gleich ist. Wenn die Ausgabe anders ist, hat sich der Zustand geändert, und es wird nicht als Verschwendung gewertet.
Es gibt keine LLM-Bewertung. Gibt man denselben Trace hinein, kommt immer dasselbe Ergebnis heraus.
Gefundene Verschwendung wird in vier Arten eingeteilt: Fehlerwiederholung (denselben Fehler erneut versuchen, ohne die Ursache zu beheben), erneute Ausführung mit Seiteneffekt (ein zustandsveränderndes Tool mit denselben Argumenten noch einmal aufrufen), Graubereich (Read-only-Wiederholung — keine Seiteneffekte, aber Tokenverbrauch) und nicht klassifizierbar. Tools wie Bash oder PowerShell, deren Effekt sich je nach Argumentinhalt vollständig ändern kann, werden nicht allein anhand des Namens bewertet, sondern als nicht klassifizierbar belassen.
[Was wurde in öffentlichen Daten gefunden?]
Direkt ausgeführt auf dem Toolathlon-Benchmark (22 Frontier-Modelle × 3 Läufe, 6.780 Traces, 176.270 Tool-Spans) ergaben sich 8.042 doppelte Aufrufe.
Diese Zahl direkt zu verwenden, wäre aufgebläht. 47 % sind Graubereich (wiederholte Erklärungen zur Aufgabenerledigung, erneutes Anlegen bereits vorhandener Verzeichnisse usw.). Zieht man sie ab, bleiben 4.251 Fälle. Das sind 2,41 % der Tool-Spans.
Auffällig waren 1.343 doppelte Ausführungen von Tools, die den Zustand verändern; darunter waren 459 wiederholte E-Mail-Versendungen mit denselben Argumenten. Allerdings ist das nur die Erkennung, dass „dasselbe Tool mit denselben Argumenten zweimal aufgerufen wurde“; ob die E-Mail tatsächlich zweimal verschickt wurde, lässt sich allein aus dem Trace nicht bestätigen.
[Was überraschend war]
Claude Code selbst war effizienter als erwartet. Kandidatenmuster wie erneutes Lesen von Dateien oder sinnlose Retries wurden sechsmal gemessen; fünfmal waren sie in echten CC-Sessions praktisch nicht vorhanden. Caching und Kontextbeibehaltung verhindern das offenbar bereits.
Mehr Verschwendung gab es in Umgebungen mit mehreren angebundenen MCP-Servern. Zwischen CC mit 20 Tools (0,80 %) und Toolathlon mit 523 Tools (2,41 %) lag ein Faktor von 3.
[Einschränkungen]
Es gibt noch keine gemessenen Einsparungsfälle. Man kann erkennen und schätzen, aber es gibt 0 Datenpunkte, bei denen jemand daraufhin etwas geändert hat und die Rechnung tatsächlich kleiner wurde. Der Graubereich von 47 % wird nicht herausgefiltert, sondern nur klassifiziert und angezeigt. Ob eine Read-only-Wiederholung wirklich Verschwendung ist, hängt vom Ausführungskontext ab, und das kann ich nicht beurteilen. Cursor und Codex werden noch nicht unterstützt. Detectoren, die die Validierung nicht bestehen, werden verworfen. Ich hatte einen Detector für erneutes Dateilesen gebaut, ihn aber nach einer Stichprobe von 30 Fällen wieder entfernt, weil die Präzision deutlich unter der 70-%-Schwelle lag (wohlwollend 3,3 %, streng 0 %). Vorhersage und Ergebnis habe ich gemeinsam im Preregister-Dokument festgehalten.
[Zum Schluss...]
Ich werde dieses Gebiet weiter erforschen und validieren! Entschuldigung, dass das README auf Englisch ist.. Wenn ihr es ausprobiert, freue ich mich über Feedback dazu, was verbessert oder ergänzt werden sollte! Bitte schenkt clew auch künftig viel Aufmerksamkeit. Vielen Dank...!!
1 Kommentare
[Damit es leichter zu lesen ist, habe ich euch eine koreanische Übersetzung des README aufgeschrieben!]
Clew
Ein deterministischer Detektor, der verschwendete Arbeit in Agent-Trace-Dateien findet.
Clew liest abgeschlossene Ausführungs-Traces von KI-Agenten und findet Schritte, die bereits erledigte Arbeit wiederholen — denselben Aufruf desselben Tools mit denselben Argumenten, Wiederholungen fehlgeschlagener Aufrufe mit identischen Argumenten oder erneutes Abfragen von Informationen, die bereits im Kontext vorhanden sind. Da es ohne LLM-Bewertung arbeitet, liefert derselbe Trace immer dasselbe Ergebnis.
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdBeispiel einer tatsächlichen Ausgabe aus einer öffentlichen Claude-Code-Session:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsWarum das wichtig ist
Bei KI-Coding-Agent-Sessions wird Verschwendung nur auf der Rechnung sichtbar. Alle Tool-Aufrufe liefern 200 zurück und nichts wirft einen Fehler, deshalb ist die Verschwendung nicht direkt erkennbar. Im Trace sieht man aber, dass der Agent dieselbe Datei zweimal liest, fehlgeschlagene Aufrufe mit denselben Argumenten erneut versucht und dasselbe Tool mit derselben Payload noch einmal aufruft.
Da Lesevorgänge in Coding-Agent-Sessions 65–90 % der Tokens ausmachen, summiert sich solche Verschwendung unauffällig. Observability-Tools zeigen zwar den Trace, sagen aber nicht, welche Schritte dupliziert waren.
Was erkannt wird
Clew sucht nach drei Redundanzmustern:
repeat — dasselbe Tool/derselbe Node wird wiederholt aufgerufen
requery — dasselbe Tool wird mit derselben Eingabe erneut aufgerufen (Ausgabe identisch)
pingpong — zwei Agenten tauschen inhaltlich praktisch dasselbe aus (Multi-Agent)
Jeder Fund wird in vier Kategorien eingeordnet:
error_repeat — die Ausgabe ist ein Fehler und derselbe Aufruf wird wiederholt
side_effect — ein zustandsveränderndes Tool (Senden/Schreiben/Erzeugen usw.) wird erneut ausgeführt
idempotent — ein schreibgeschütztes/deklaratives Tool wird wiederholt (keine Nebenwirkungen, aber Token-Verbrauch)
unclassified — Tool nicht im Mapping. Die Wirkung hängt von der Payload ab, daher wird nicht allein aus dem Tool-Namen geschlossen (Bash/PowerShell usw.)
[Wie es funktioniert]
Es ist eine zweistufige Kaskade:
strukturelles Gate — gruppiert Aufrufe desselben Tools mit denselben (normalisierten) Argumenten
Identitäts-Gate — prüft, ob die sha256 der Ausgabe exakt übereinstimmt. Falls nicht, hat sich der Zustand geändert und es wird nichts markiert
Die günstige Strukturprüfung filtert zuerst Kandidaten heraus, und die teure semantische Prüfung (Embeddings + Cosine) wird nur bei Bedarf ausgeführt. Da es keine LLM-Bewertung gibt, sind die Ergebnisse deterministisch — wichtig, wenn man es in CI einsetzen will.
[Eingabeformate]
Claude Code — analysiert Session-JSONL direkt
LangGraph — erkennt Ketten-Redundanz im Trace
LangChain·CrewAI·AutoGen·LlamaIndex usw. — parst instrumentierte Traces im OpenTelemetry/OpenInference-Standardformat (Format wird unterstützt, framework-spezifische Validierung anhand realer Messungen läuft noch)
öffentliche Benchmark-Traces (Toolathlon, RedundancyBench)
Cursor- und Codex-Sessions werden noch nicht unterstützt — lokale Formate werden derzeit geprüft.
[Validierungsergebnisse]
Öffentliche Benchmarks (Toolathlon, 6.780 Traces, 176.270 Tool-Spans):
8.042 redundante Aufrufe erkannt. Davon sind 47 % Grauzone (idempotente Operationen, Abschlusserklärungen); ohne diese bleiben 4.251 Fälle (2,41 % bezogen auf Tool-Spans). Das ist etwa dreimal so viel wie bei Claude-Code-Sessions (0,80 %).
1.343 doppelte Ausführungen zustandsverändernder Tools, darunter 459 wiederholte E-Mail-Sendungen mit denselben Argumenten. Dabei wurde allerdings nur erkannt, dass dasselbe Tool mit denselben Argumenten doppelt aufgerufen wurde; ob tatsächlich Nebenwirkungen auftraten, wurde nicht bestätigt.
Labeling-Benchmark (RedundancyBench):
Precision 0.826 (untere Schätzung für Redundanz innerhalb einer Datei). Ein erheblicher Teil der RB-Labels betrifft dateiübergreifende Redundanz und liegt damit außerhalb des Geltungsbereichs eines auf Sessions ausgelegten Designs. Recall ist mit 0.157 niedrig.
[Ehrliche Grenzen]
Es gibt noch keine gemessenen Einsparungsfälle. Erkennen und schätzen kann man es, aber es gibt 0 Before/After-Datenpunkte von echten Nutzern, die etwas geändert und dadurch ihre Rechnung tatsächlich gesenkt haben.
47 % der auf Benchmarks markierten Fälle sind Grauzone (idempotente Wiederholungsausführungen). Es wird nicht herausgefiltert, sondern nur klassifiziert — denn ob eine schreibgeschützte Wiederholung Verschwendung war, hängt vom nicht sichtbaren Kontext ab.
Da eine exakte sha256-Übereinstimmung verlangt wird, wird schon bei kleinen Unterschieden in der Ausgabe nichts markiert. Daher ist der Recall niedrig; das Design priorisiert Präzision.
Claude Code ist ungewöhnlich gut optimiert. In realen CC-Sessions wurden sechs potenzielle Verschwendungsmuster gemessen, aber fünf davon existierten dort nicht. Interessante Verschwendung zeigte sich nicht in CC selbst, sondern in Multi-Tool-MCP-Umgebungen.
Die Kostenschätzung (amplification) ist keine Messung, sondern eine Schätzung und nur im Claude-Code-Format möglich.
Was nicht validiert ist, wird verworfen
Ich habe einmal einen Detektor für erneutes Dateilesen gebaut, ihn dann aber verworfen, weil die Precision in einer Stichprobe von 30 manuell annotierten Fällen deutlich unter dem vorab registrierten Schwellenwert (70 %) lag (großzügig gerechnet 3,3 %, streng gerechnet 0 %). Vorhersagen und Ergebnisse habe ich zusammen im Vorregistrierungsdokument festgehalten.