Wachsen, messen – und der Blick von außen

Nach den ersten fünf Tagen lief Kettenhemd in allen meinen Projekten, lieferte gute Ergebnisse, und das Regelwerk wuchs und wuchs. Zahlen hatte ich keine, und im Issue zur Kostenfrage stand später als Ausgangslage nur, es „fühlt sich gut an“.

Am 23. Oktober war dieses Gefühl weg – es war der Tag, an dem ich zweifelte, ob sich das alles noch lohnt. Ich beschäftigte mich an diesem Tag so ausdrücklich mit den Grenzen, die Claude Code für Regelwerke setzt, während ich schon an und über diesen Grenzen lag. Mittags eröffnete ich das Issue „Lohnt sich Kettenhemd? Kosten und Nutzen“.

Wohin das Geld fließt

Bevor es um die Beträge in diesem Beitrag geht, sei gesagt, dass ich Claude Code über das Abo Claude Ultra nutze und nicht je Session zahle. Alle Beträge sind der Richtwert, den Claude Code je Session mitliefert, und keine echte Rechnung.

Am 26. Oktober lag die erste Auswertung vor, mit 89 Untersessions seit dem 24. Oktober. Eine Untersession ist bei mir eine eigene Claude-Session für genau eine Aufgabe, gestartet vom Hauptchat, mit dem ich spreche, und im Median kostete eine davon 5 $. Ich saß am Rechner und hatte viele Zweifel an dem Ganzen – die Ergebnisse waren gut, nur wusste ich nicht, ob sie zu teuer waren. Dann kam die nächste Zahl, und die hat gebrannt. 85 Prozent der Kosten gingen ins Vorlesen und Merken des Verlaufs, während fürs Schreiben von Code der Rest blieb.

Das liegt an der Bauweise, bei der ein Agent mit jedem Werkzeugaufruf den ganzen bisherigen Verlauf erneut ans Modell schickt. Damit das nicht jedes Mal voll bezahlt wird, gibt es den Prompt-Cache. Neues im Verlauf wird einmal zum 1,25-fachen Eingabepreis in den Cache geschrieben und danach bei jedem Aufruf wieder gelesen, bei Opus 5.5 zum 0,05-fachen (Anthropic-Doku zu Prompt-Caching). Das ist wenig, aber bei hundert Aufrufen wird der Verlauf hundertmal gelesen, und die 46 von 89 Sessions, die über 200.000 Token Kontext kamen, verursachten 82 Prozent der Kosten.

Umbauen nach Zahlen

Bis dahin hatte jede Session alle Regeln geladen, während sie seit Version 14 einen Kern von höchstens 12.000 Byte und dazu das Paket ihrer Rolle lädt. Dabei kam heraus, dass meine Regeln nur 11.000 bis 12.000 von 66.500 Token Grundlast ausmachten und Claude Code selbst den Rest mitbrachte. Eine Untersession startet seitdem mit rund 37.000 statt 67.000 Token.

Für die langen Verläufe kam die Staffel. Wird eine Untersession zu groß, schreibt sie eine Übergabe ins Issue und startet selbst eine frische Nachfolgerin, die nur das Issue und den Code liest. Am 28. Oktober rechnete ich an 232 Untersessions nach, wo sich der Schnitt lohnt. Bei 150.000 Token sparte er 2 Prozent, bei 200.000 Token 6 Prozent und darüber kaum mehr, weil auch ein Neustart rund 0,45 $ kostet. Seitdem misst ein Hook, also ein Befehl, den Claude Code nach jedem Werkzeugaufruf selbst ausführt, den Kontext und meldet ab 200.000 Token, dass es Zeit für die Übergabe ist. Anthropic beschreibt in „Effective harnesses for long-running agents“ einen ähnlichen Weg; dort heißt es knapp „compaction isn’t sufficient“, und eine neue Session liest stattdessen eine Fortschrittsnotiz sowie die Git-Historie.

Dazu kam ein Sucher, ein kleiner Subagent, der nur liest, Suchen über das ganze Repo sowie lange Testausgaben übernimmt und nur das Ergebnis zurückgibt. Die automatischen Prüfungen vor dem Reviewer, die im Testlauf 41 bis 52 Prozent der Kosten trugen, laufen seit Version 16 sparsamer, und die Sicherheitsprüfung läuft nur noch einmal je Aufgabe.

Ein Graph, der nichts findet

Eine Idee schien alles abzukürzen. Werkzeuge wie Graphify bauen aus dem Code einen Wissensgraphen und beantworten Fragen wie „Was hängt an dieser Datei?“. Genug YouTube-Shorts hatten es angepriesen, die Werbung sprach von „71,5x“, es klang gut, und ich war davon überzeugt.

Am 24. Oktober habe ich es an meiner App anhand von drei abgeschlossenen Aufgaben gemessen. Die Frage lautete, welche Dateien bei einer Änderung mitgeändert werden müssen und welche dann tatsächlich geändert wurden. Graphify fand 0 von 42, während eine einfache Textsuche mit git grep 19 fand. Der Graph kannte zwar Importe zwischen TypeScript-Dateien, aber keine Aufrufe über HTTP, kein YAML, kein CSS und keine Doku – und genau diese Dateien wurden am häufigsten mitgeändert.

Ich wollte das nicht glauben und machte das Thema danach mehrmals wieder auf, bis ich mich wirklich mit git grep auseinandergesetzt hatte. Graphify kam nicht ins Regelwerk, doch fair bleibt, dass die Messung klein war und ich die Suchbegriffe für git grep mit Kenntnis der Änderung gewählt habe.

Was die Urteile verraten

Beim Lesen der Befunde fiel mir etwas anderes auf. Ähnliche Befunde der Stufen MITTEL und HOCH kamen in vielen Projekten immer wieder vor. Ich wollte Werkzeuge oder Regeln bauen, damit weniger Aufgaben eine zweite Reviewer-Runde brauchen, also eine zweite Prüfung durch den Reviewer-Agenten nach der Nachbesserung. Dafür brauchte ich die Daten an einem Ort, und so entstand am 24. Oktober KettenhemdDaten, das die Urteile aller Prüfungen aus allen Projekten sammelt, sie in einzelne Befunde zerlegt und dazu die Kosten jeder Session aus den Protokollen von Claude Code liest.

Am 28. Oktober kam die erste große Auswertung mit 3.114 Befunden aus 934 Urteilen. 65 Prozent der ersten Reviewer-Runden waren bestanden. 37 Prozent aller Befunde hatten keine Folge für Nutzer oder Betrieb, und fast die Hälfte der als HOCH eingestuften hatte eine geringe oder keine. 47 durchgefallene Runden enthielten nur solche Befunde – dagegen standen 207 Befunde, deren Folge ein echter Schaden gewesen wäre. Seitdem gilt ein Befund nur noch als HOCH, wenn er eine konkrete Folge nennt, und eine fehlende Angabe wird nachgetragen, statt eine ganze Runde zu kosten. Die Zahlen sind Richtwerte, denn 83 Prozent der Befunde hat ein Modell nachträglich eingeordnet.

Das Ziel, das ich nicht erreicht habe

Für Version 14 hatte ich mir ein Kostenziel von 1,57 $ je Aufgabe im Testlauf an einem erfundenen Projekt gesetzt, doch der Median lag bei 2,23 $, eine Version später bei 2,36 $ und mit Version 16 bei 2,20 $. Am Abend des 30. Oktober hielt ich den Umbau für Version 15 mit drei Worten an: „Erst nur messen.“ Später stand im Issue der Befund, dass das Ziel selbst ohne zweite Prüfung nicht erreichbar gewesen wäre.

Manchmal bin ich an diesen Zielen verzweifelt. Man muss nicht super günstig sein, die Arbeit muss gut sein, und um die Ziele zu erfüllen, hätte ich Qualität abschneiden müssen. Man kann nicht einfach nur die Kosten senken, egal was es kostet. Man muss den Prozess beibehalten und verstehen, was passiert – es gibt so viel mehr als die reinen Kosten. Im Testlauf zu Version 16 bestand die erste Reviewer-Runde in sechs von sechs Aufgaben.

Unbequem fällt auch eine andere Rechnung aus. In diesen Tagen besprach ich alles, was mir einfiel, mit dem Agenten und schaute mit vielen kleinen Proben und ohne gleich nein zu sagen, wohin es führt. Von 20 Ideen hatten gefühlt vielleicht ein, zwei wirklich Sinn. Über den Rest habe ich im Hauptchat gequatscht und ihn wieder verworfen.

Ein frischer Blick

Am 2. November wusste ich nicht genau, wo ich anfassen musste; ich hatte grobe Gedanken, aber das war’s. Also startete ich eine frische Claude-Session von außen, ohne Regelwerk, ohne irgendwas, und bat sie nur, sich Kettenhemd von außen anzuschauen. Ihr erster Satz lautete: „Kettenhemd ist handwerklich stark, aber in 15 Tagen so gewachsen, dass die Größe selbst zum Risiko wird.“ Der Regeltext war vom 19. Oktober bis dahin von 62 KB auf 259 KB gewachsen, in 645 Commits.

Mein erster Gedanke war, am liebsten alles abzuschneiden und neu anzufangen, doch dann hätte ich sicher nicht so viel gelernt wie jetzt. Die Session schlug einen anderen Weg vor, aus dem ein Plan in drei Schritten entstand: erst Linux, dann eine Bewährung an echter Arbeit, dann kürzen. Gemessen hatte sich Kettenhemd bis dahin vor allem an sich selbst und an dem erfundenen Projekt – von 26 Aufgaben, die seit dem 26. Oktober in meinen Produktprojekten erledigt wurden, kamen 17 von Kettenhemd selbst.

Wer morgen anfängt, die Kosten seiner Agenten zu messen, dem rate ich, nicht einfach die Rechnung zu akzeptieren. Frag nach, wohin die Kosten fließen, wie sie entstehen und ob es hilft – und wenn du es nicht weißt, teste es. Bau dir ein Test-Repo und lass denselben Lauf immer wieder unter anderen Bedingungen laufen. Wie es mit Linux weiterging, erzählt Teil 3.

Diesen Beitrag hat mein Agent aus einem Interview mit mir geschrieben; Zahlen und Abläufe stammen aus Kettenhemd. Gelesen und freigegeben habe ich ihn selbst.