Disziplin beim Lesen — der unsichtbare Token-Hebel

Nach dem ersten ernsthaften Aufräumen an der CLAUDE.md und dem Memory war ich ehrlich gesagt zufrieden. Die Datei war schlank, das Memory verdichtet, die Sitzungsstarts spürbar schneller. Dann habe ich einen Nachmittag lang einfach mal mitgeschaut, was der Assistent im Verlauf einer typischen Coding-Sitzung tatsächlich tut — und gemerkt, dass mein Zielbild von „optimiert“ weit vom tatsächlichen Token-Fluss entfernt war. Memory und CLAUDE.md sind die auffälligen Posten. Die stillen Kosten liegen woanders, und sie sind größer. Eine einzige Datei, die im Laufe einer Sitzung vollständig gelesen wird, obwohl nur ein Abschnitt nötig gewesen wäre, kostet mehr Tokens, als eine ganze Woche aufgeräumtes Memory jemals einsparen kann.

Read ist der eigentliche Hebel

Die Mathematik ist unangenehm klar. Das Memory wird pro Sitzung einmal geladen — wenige hundert Tokens im Schnitt, bei gut gepflegten Dateien eher am unteren Ende. Die CLAUDE.md wird pro Sitzung einmal geladen — ebenfalls wenige hundert Tokens, wenn sie vernünftig geführt ist. Beide Posten sind Einmalkosten pro Sitzung. Jede einzelne Datei, die der Assistent im Verlauf der Sitzung zusätzlich liest, kostet dagegen so viele Tokens, wie sie Inhalt hat — und bei einer aktiven Coding-Sitzung sind das fünf, zehn, zwanzig Dateien, manche davon mehrere tausend Zeilen lang.

Das ist der Punkt, an dem das Token-Budget tatsächlich entschieden wird. Wenn der Assistent in einer Sitzung zehn Dateien zu je zweihundert Zeilen liest, zahlst du etwa so viele Tokens wie für eine aufgeräumte CLAUDE.md, die zehn Mal geladen wurde. Wenn er dagegen eine Datei mit zweitausend Zeilen vollständig durchliest, weil er nicht wusste, dass nur der Abschnitt von Zeile dreihundert bis dreihundertfünfzig relevant war, kostet dieser eine Lesevorgang mehr als die gesamte Sitzungseröffnung. Read-Kosten dominieren das Budget einer aktiven Coding-Sitzung, und fast niemand denkt an sie, weil sie sich auf dutzende kleine Operationen verteilen.

Senior-Disziplin beim Lesen

Nach einigen Wochen bewusstem Mitschauen haben sich drei Regeln herauskristallisiert, die zusammen den größten Teil der Read-Kosten einsparen. Sie klingen trivial, bis man sie wirklich einhält.

Niemals eine Datei vollständig lesen, wenn die exakte Stelle bekannt ist. Fast alle Werkzeuge bieten einen Offset- oder Range-Modus beim Lesen an — bei Claude Codes Read-Tool etwa über offset und limit. Wenn klar ist, dass die relevante Funktion in einer Datei mit zweitausend Zeilen bei Zeile vierhundert beginnt, dann gibt es keinen Grund, die Zeilen eins bis vierhundert und die Zeilen fünfhundert bis zweitausend auch zu laden. Das ist nicht Optimierung, das ist Präzision. Vollständige Reads auf große Dateien sind die mit Abstand häufigste Token-Verschwendung, die ich bei mir selbst gefunden habe.

Vor jedem Read überlegen, ob Grep reicht. Ein Großteil der Fragen, die zu einem Read führen, ließe sich genauso gut mit einer gezielten Suche beantworten. „Wo wird diese Funktion aufgerufen?“ ist kein Read, das ist ein Grep mit Kontext-Zeilen drumherum. „In welchen Dateien steht use Monolog?“ genauso. Ein Grep im Content-Modus liefert die treffenden Zeilen plus ein paar Zeilen Umgebung, nicht mehr. Das spart gegenüber einem vollständigen Lesevorgang einer großen Datei eine Größenordnung. Der Reflex, bei Unsicherheit erst zu greppen und erst bei Treffer gezielt zu lesen, ist der wichtigste Umbau, den man sich angewöhnen kann.

Bei großflächiger Recherche: Subagenten. Wenn die Aufgabe „finde heraus, wie das Login-System in diesem Projekt funktioniert“ lautet und dafür ein Dutzend Dateien durchgearbeitet werden müssen, hat das Hauptgespräch diese Last nicht nötig. Ein Explore- oder Research-Subagent durchsucht das Projekt, sammelt die Fakten, schickt einen kurzen Bericht zurück — und der Hauptkontext sieht nur das Ergebnis, nicht die rohen Dateien. Die gelesenen Tokens landen im Subagenten-Kontext, nicht im deinen, und der Subagent endet, sobald sein Bericht geschrieben ist. Das ist weniger ein Trick und mehr eine Arbeitsteilung: Wer alles selbst im eigenen Kontext lesen will, bezahlt die volle Rechnung. Wer delegiert, bekommt eine Zusammenfassung.

Diese drei Regeln zusammen sparen nach meiner Erfahrung in einer typischen aktiven Coding-Sitzung rund achtzig Prozent der Read-Kosten gegenüber einem Setup, in dem jede Datei reflexartig vollständig gelesen wird. Keine exakte Zahl, aber die Größenordnung stimmt — und sie ist der Grund, warum alle anderen Token-Optimierungen im Vergleich blass aussehen.

Der Cache-Präfix als zweiter Hebel

Der zweite große Hebel ist technisch anspruchsvoller und zahlt sich erst über die Sitzungsdauer aus, dafür kostet er nichts, wenn man ihn einmal richtig aufgesetzt hat: Prompt-Caching.

Anbieter wie Anthropic erlauben es, stabile Prompt-Präfixe zu cachen. Solange sich der Anfang eines Prompts über mehrere Requests hinweg nicht ändert, zahlst du für diesen Teil nur einen Bruchteil des normalen Input-Preises. Die genauen Werte — Cache-Read-Kosten, Cache-Write-Kosten, TTLs und die Bedingungen, unter denen der Cache greift — stehen in der offiziellen Anthropic-Dokumentation zu Prompt Caching und verschieben sich gelegentlich. Als Größenordnung reicht: Cache-Reads sind deutlich günstiger als normale Input-Tokens, in der Praxis typischerweise etwa auf ein Zehntel reduziert. Cache-Writes sind einmalig teurer. Der Cache hat eine begrenzte Haltbarkeit — standardmäßig im Bereich weniger Minuten, optional eine längere Variante, die mehr kostet aber länger hält.

Für die Praxis bedeutet das: Wenn der Anfang deines Prompts über viele Requests hinweg identisch bleibt, greift der Cache zuverlässig, und du zahlst für diesen stabilen Teil nur noch Bruchteile. Das Verlockende daran ist, dass der Cache nichts von dir verlangt, außer dass du ihn nicht aktiv zerstörst. Das Ärgerliche ist, dass genau das Zerstören in vielen Setups unbemerkt passiert, und zwar systematisch.

Was den Präfix bricht

Der Cache-Präfix bindet sich an den unveränderten Anfang deines Prompts. Sobald sich am Anfang auch nur ein Zeichen ändert, bricht der Cache ab diesem Punkt. Alles dahinter, egal wie stabil es selbst ist, wird wieder zum Volltarif gelesen. Das heißt: Eine einzige flüchtige Zeile am falschen Ort kostet den gesamten nachfolgenden Cache-Vorteil.

Die typischen Täter sind unscheinbar und stehen fast überall. Datumsstempel in Memory- oder Status-Dateien, die bei jeder Sitzung aktualisiert werden. „Stand 2026-04-10: aktiver Brief 211, 576 Tests grün“ — vier Wörter mit einem Datum, die beim nächsten Sitzungsstart auf etwas anderes umgeschrieben werden, vielleicht „Stand 2026-04-11: aktiver Brief 212, 584 Tests grün“. Inhaltlich trivial, technisch ein Cache-Killer. Jede solche Aktualisierung verschiebt den Anfang des Prompts, der Cache verfällt, jeder Folge-Request zahlt für alles dahinter wieder den vollen Preis.

Die weiteren Klassiker: Test-Zähler im Memory-Header, BRIEF-Fortschritts-Snapshots in der Indexzeile, Tageszustände in der Projektbeschreibung, aktuelle Zeitangaben in der Einleitung einer Regeldatei. Alles Dinge, die sich bei jedem Sitzungsstart verändern, und alles Dinge, die in die stabile Präfix-Zone geraten sind, obwohl sie dort nichts zu suchen haben. Wer seine CLAUDE.md zu Recht als größten sichtbaren Hebel aufgeräumt hat und dann Datumsstempel in einem Memory-Index stehen lässt, hat sich gegenseitig neutralisiert — der Aufräumungseffekt verpufft, weil der Cache nicht greift.

Das konkrete Audit-Beispiel

Aus der realen Aufräumung, die diesen Serien-Artikeln zugrunde liegt: eine MEMORY.md, deren Indexzeile den Text „Stand 2026-04-10: aktiver Brief 211, 576 Tests grün“ direkt unter der Kopfzeile hatte. Die Datei wurde bei jedem Sitzungsstart geladen, sie stand früh im Prompt, sie war damit genau in der Zone, die für das Prompt-Caching interessant ist — und sie hat den Cache systematisch zerbrochen, weil ihr Anfang sich fast täglich verändert hat.

Die Aufräumung war eine Sache von Minuten. Datum raus. Brief-Nummer raus. Test-Zähler raus. Die Indexzeile wurde auf eine stabile Beschreibung der referenzierten Datei reduziert — so etwas wie „Projektstand und aktiver BRIEF: siehe status.md„. Zwei Zeilen, und seit diesem Tag waren sie über Wochen exakt identisch. Die Volatiles sind in status.md gewandert, die nur dann geladen wird, wenn der Status für die konkrete Aufgabe wirklich relevant ist. Für die meisten Aufgaben ist er das nicht.

Der Effekt war messbar, ohne dass ich groß gemessen hätte. Der Cache-Präfix blieb über Sitzungen hinweg stabil. Die Folge-Requests einer Sitzung waren spürbar billiger — weil das lange stabile Stück am Anfang des Prompts jetzt zum Cache-Preis geladen wurde und nicht mehr zum Volltarif. Eine einzige Zeile, und der größte Effekt, den ich in dem ganzen Audit gesehen habe. Wer an dieser Stelle nicht aufräumt, kann sich die anderen Optimierungen fast schenken.

Memory als Verdichtung, nicht als Speicher

Ein verwandter Punkt, der im ersten Teil der Serie nur gestreift wurde: Memory-Dateien haben die Aufgabe zu verdichten, nicht zu speichern. Sie sollen das enthalten, was zusätzlich zum Projekt gewusst werden muss, um produktiv zu arbeiten. Nicht das Projekt selbst. Verzeichnisbäume, Klassenlisten, Test-Statistiken, Stack-Beschreibungen — all das steht im Projekt selbst und ist mit einem einzigen Glob oder einem Blick in den Code lesbar. Es hat in einer Memory-Datei nichts zu suchen.

Das Beispiel aus dem Audit, das ich auch in anderen Artikeln dieser Serie zitiere: Eine Memory-Index-Datei war über die Zeit auf 165 Zeilen angewachsen und enthielt eine vollständige Stack-Beschreibung, eine Liste aller Test-Projekte, ein Architektur-Abriss. Alles davon stand bereits im Projekt selbst — in einer Architektur-Datei, einer Status-Übersicht, im Quellcode. Nach der Aufräumung hatte das Memory vierzehn Zeilen. Reiner Index. Kein Informationsverlust, weil alles, was gestrichen wurde, an seinem eigentlichen Ort sauberer dokumentiert war. Ein gutes Memory zeichnet sich nicht durch Vollständigkeit aus, sondern durch Verdichtung. Wer das einmal verstanden hat, fängt an, Memory-Einträge daran zu messen, wie unvermeidlich sie sind, und nicht daran, wie hilfreich sie theoretisch sein könnten.

Die vier Hebel, nach Wirkung sortiert

Am Ende des Audits hatte ich vier Hebel identifiziert, die sich in ihrer Wirkung und in ihrem Aufwand stark unterscheiden. Hier sortiert nach tatsächlicher Wirkung, nicht nach Sichtbarkeit.

Platz eins: Read-Disziplin. Der größte Hebel, weil jede aktive Sitzung viele Reads hat, und jeder einzelne davon das Potenzial hat, so viel zu kosten wie eine ganze Sitzungseröffnung. Wer sich angewöhnt, vor jedem Read kurz zu überlegen, ob ein Grep oder ein Range-Read reicht, spart den größten Posten ein. Diese Regel kostet dich nichts, sie wirkt ab der nächsten Aktion, und sie ist die einzige, die wirklich skaliert mit der Größe des Projekts.

Platz zwei: CLAUDE.md auf Diät. Der größte sichtbare Hebel, weil diese Datei bei jedem Sitzungsstart vollständig geladen wird. Die Umstellung braucht eine Stunde Schreibtischarbeit pro Projekt, der Effekt hält danach dauerhaft. Die Details liegen im zweiten Teil dieser Serie — und wer gerade keinen Nerv für alles hat, aber trotzdem etwas tun will, fängt genau hier an.

Platz drei: Cache-Präfix-Stabilität. Der unauffälligste Hebel, weil er erst über die Sitzungsdauer wirkt und am ehesten übersehen wird. Einmal saubergezogen — Datumsstempel, Zähler und Tagesstände raus aus den Präfix-Dateien, alles Volatile in eine separate Status-Datei — und der Effekt hält sich praktisch kostenlos über Monate. Die Aufräumung selbst ist eine Sache von Minuten.

Platz vier: Memory-Hygiene. Der konstanteste Hebel, weil er pro Sitzungsstart gilt und mit Disziplin verbunden ist — Memory muss regelmäßig gepflegt werden, sonst wandelt es sich unauffällig von einer Hilfe in ein Hindernis. Die Wirkung pro Sitzung ist kleiner als bei den anderen drei Hebeln, aber sie ist gleichzeitig die einzige, die sich auf die Antwortqualität auswirkt — weil ein verdichtetes Memory die Relevanz der Informationen erhöht und das Lost-in-the-Middle-Problem kleiner macht. Wer tiefer einsteigen will, findet im Begleitartikel zum Memory-Management die ausführliche Herleitung.

Alle vier zusammen sind nicht „nice to have“. Sie sind die Senior-Disziplin im Umgang mit einem KI-Assistenten. Einzeln wirken sie, in der Kombination multiplizieren sie sich — und das ist der Grund, warum ein wirklich aufgeräumtes Setup nach meiner Erfahrung mit der gleichen Modellklasse drei- bis fünfmal günstiger und spürbar präziser arbeitet als ein unaufgeräumtes. Ich schreibe bewusst „nach meiner Erfahrung“ — die Zahlen sind illustrativ, nicht repräsentativ. Aber die Richtung stimmt, und sie stimmt bei jedem Projekt, das ich seither angefasst habe.

Die ehrliche Bilanz

Am Ende dieser Serie ist der wichtigste Satz der gleiche wie am Anfang, nur mit einer anderen Gewichtung. Token zu sparen war angenehm. Der eigentliche Gewinn war ein anderer: Das Projektwissen liegt jetzt geordnet. Das Verhalten des Assistenten ist konsistenter. Die Sitzungen sind schneller. Die Antworten sind präziser. Die Rechnung am Monatsende ist niedriger, aber sie ist nur das Symptom.

Die drei Teile dieser Serie haben denselben Grundgedanken aus drei Richtungen beleuchtet. Teil eins hat die Mechanik aufgemacht — warum Kosten, Latenz und Qualität auf einer gemeinsamen Achse sitzen und sich gegenseitig verstärken. Teil zwei hat den sichtbaren Hebel gezeigt — die CLAUDE.md, die bei jedem Sitzungsstart ungefragt geladen wird. Teil drei hat die beiden unsichtbaren Hebel nachgereicht — Read-Disziplin und Cache-Präfix, ohne die alles andere halb so viel bringt.

Was über allem steht: Token-Disziplin ist weniger ein KI-Thema als ein Disziplin-Thema. Wer sein Projektwissen ordentlich aufschreibt, nur das liest, was er wirklich braucht, und den stabilen Teil seines Setups tatsächlich stabil hält, arbeitet besser mit einer KI. Und, wie schon in allen anderen Teilen dieser Serie, ganz zufällig auch besser mit sich selbst in sechs Monaten. Das ist der Punkt, an dem technische Optimierung und handwerkliche Sauberkeit dieselbe Sache sind — nur von verschiedenen Seiten betrachtet. Und genau deshalb lohnt sich diese Art von Aufräumarbeit auch dann, wenn der Rechnungsposten am Ende des Monats egal wäre.