Das Gedächtnis

Fangen wir mit der unangenehmen Hälfte an: Ein Sprachmodell hat kein Gedächtnis. Es erinnert sich an keine einzige vergangene Sitzung, und daran ändert auch das beste Werkzeug nichts.

Was es gibt, ist etwas anderes, und es funktioniert überraschend gut: Der Agent sieht zu Beginn jeder Sitzung an denselben Stellen nach. Was dort steht, weiß er. Was nicht dort steht, ist weg.

Damit wird aus einer Frage über Erinnerung eine Frage über Orte.

Fünf Orte

Das Gespräch selbst. Alles, was Sie in dieser Sitzung gesagt haben, steht im Kontextfenster und wirkt sofort. Es ist der schnellste Ort und der einzige flüchtige: Beim nächsten Start ist er leer.

Die Projektanweisung. Was Sie einmal hineingeschrieben haben, steht in jeder Sitzung wieder da, wortgleich. Sie ist der Ort für alles, was immer gilt, und Gegenstand von Kapitel 03.

Die Notizen des Werkzeugs. Neuere Agenten schreiben sich selbst auf, was ihnen aufgefallen ist: wie Sie arbeiten, welche Korrekturen Sie gegeben haben, was im Projekt gerade entschieden ist und wo etwas außerhalb davon zu finden ist. Was sich aus dem Code ablesen lässt oder schon in der Projektanweisung steht, lassen sie weg. Der Hersteller nennt das automatisches Gedächtnis, und Sie füllen es nicht selbst.

Das Projekt. Der Code steht ohnehin da und lässt sich lesen. Dazu kommt die Historie: Branch, Zustand und die letzten Commits gehören in der Voreinstellung zu dem, was der Agent beim Start vor sich hat, ohne dass jemand danach fragt. Warum das mehr ist als eine Formalie, steht in Kapitel 04.

Was daneben liegt. Notizen, Entscheidungen, eine Wissensbasis: alles, was Sie außerhalb des Projekts führen und ihm zugänglich machen. Der Ort mit der größten Reichweite und dem meisten Aufwand, siehe Kapitel 06.

Wer welchen Ort füllt

Die Aufteilung ist der praktisch wichtigste Teil dieses Kapitels, weil sie darüber entscheidet, wo Sie etwas hinschreiben.

Zwei Spalten lohnen einen zweiten Blick. Die Notizen des Werkzeugs sind maschinenlokal: Sie liegen außerhalb des Projekts und gehen an keinen Kollegen. Die Historie dagegen ist geteilt, weshalb eine Commit-Nachricht auch für andere lesbar sein sollte.

Was das Verdichten damit macht

Das gilt für eine Sitzung, die im Gespräch wächst, so wie es dieser Kurs durchgehend voraussetzt. Ein Agent, der stattdessen einmalig für eine Aufgabe aufgerufen wird und sich danach beendet, so wie es in einer Automatisierung üblich ist, beginnt jedes Mal mit leerem Gespräch. Verdichtet wird bei ihm nur, wenn dieser eine Lauf selbst lang genug wird.

Lange Sitzungen werden irgendwann zusammengefasst, damit das Kontextfenster nicht überläuft. Das geschieht von selbst, kurz bevor es voll ist, oder von Hand, wenn Sie es anstoßen. Kurz vor der Grenze räumt das Werkzeug laut Funktionsweise-Doku (externe Seite, code.claude.com) zuerst ältere Werkzeugausgaben ab und fasst erst danach das Gespräch zusammen, wenn das noch nötig ist. In der Voreinstellung fasst das Werkzeug auch eine lange Sitzung zusammen, die eine knappe Stunde unberührt liegen bleibt. Das Gespräch wird dabei ersetzt und geht durch die Hand desjenigen, der die Zusammenfassung schreibt.

Für die fünf Orte heißt das:

• Projektanweisung und Notizen des Werkzeugs werden neu von der Platte gelesen. Sie stehen danach wieder vollständig da.
• Code und Historie liegen ohnehin auf der Platte. Gleich nach dem Verdichten liest das Werkzeug den Git-Zustand neu, dazu bis zu fünf Dateien aus der Sitzung, die zuletzt geändert wurden.
• Das Gespräch hängt an der Zusammenfassung. Was für wichtig gehalten wurde, überlebt.

Daraus folgt die Gewohnheit, die diesem Kapitel zugrunde liegt: Wenn Sie dieselbe Sache zum zweiten Mal erklären, gehört sie an einen der vier dauerhaften Orte.

Ein Hebel, den viele nicht kennen

Das Verdichten lässt sich lenken. Man kann dem Befehl mitgeben, worauf die Zusammenfassung achten soll, und die Dokumentation (externe Seite, code.claude.com) beschreibt den Unterschied nüchtern: Die Zusammenfassung behält dann, was Sie auswählen, statt dessen, was der automatische Durchgang für wichtig hält.

Wer eine lange Fehlersuche hinter sich hat und gleich weiterarbeiten will, sollte diesen Zusatz benutzen. Er kostet fünf Wörter.

Die fünf Orte aus Ebene 1 verhalten sich technisch verschieden, und der Unterschied läuft entlang einer einzigen Frage: Steht es beim Start schon im Fenster, oder muss es erst geholt werden?

Geladen oder nachschlagbar

Beim Start füllt sich das Kontextfenster ohne Ihr Zutun. Hinein gehen die Systemanweisung, die Pro­jekt­an­wei­sungen in voller Länge, die Selbstnotizen des Werkzeugs bis zu einer Grenze, Angaben zur Umgebung samt Git-Zustand, die Namen der verfügbaren Tools und die Kurz­be­schrei­bungen der Skills.

Das ist der Teil, der jeden Schritt der Sitzung mitbezahlt wird. Alles andere liegt daneben und kommt erst herein, wenn es gebraucht wird: eine Datei, die gelesen wird, eine pfadgebundene Regel, deren Muster passt, ein Skill, der aufgerufen wird.

Naheliegende Rückfrage an dieser Stelle: Geschieht das wirklich immer, oder holt sich das Modell die Dinge, sobald es sie für nützlich hält? Der Hersteller ist da eindeutig: Noch bevor Sie etwas eintippen, liegen laut Dokumentation (externe Seite, code.claude.com) die Projektanweisung CLAUDE.md, die Selbstnotizen, die Namen der MCP-Tools und die Kurz­be­schrei­bungen der Skills im Kontext.

Die Umgebungsangaben gehören dazu und stehen dort als eigener Posten: Arbeits­ver­zeichnis, Plattform, Kommandozeile, Fassung des Betriebssystems und die Auskunft, ob überhaupt ein Git-Repository vorliegt. Die Simulation setzt dafür rund 280 Token an. Ihre Zahlen sind nach eigener Angabe Beispielwerte. Branch, Zustand und die letzten Commits kommen als eigener Block dazu. Gefragt wird vorher nichts davon.

Die Trennlinie läuft mitten durch einzelne Posten. Von angebundenen Tools kommen die Namen mit, damit der Agent weiß, was es gibt; die vollständigen Beschreibungen bleiben standardmäßig liegen und werden einzeln nachgeholt. Von einem Skill kommt die Kurzbeschreibung, der Inhalt erst beim Aufruf. Und ein Skill, den das Modell von sich aus gar nicht aufrufen darf, steht nicht einmal im Verzeichnis und kostet bis zum Aufruf nichts.

Daraus folgt die Kostenregel dieses Kapitels: Ein Ort ist umso teurer, je weiter oben in dieser Liste er steht. Eine Regel in der Projektanweisung zahlt sich bei jedem Schritt, eine Notiz in der Wissensbasis nur, wenn jemand nachsieht.

Zwei Gedächtnisse nebeneinander

Die Projektanweisung und die Selbstnotizen sehen von außen ähnlich aus und haben verschiedene Aufgaben. Der Hersteller stellt sie in einer Tabelle gegenüber, und die fünf Zeilen sind es wert, sie zu kennen:

Die dritte Zeile ist die, die im Alltag überrascht. Die Selbstnotizen liegen außerhalb des Projekts, in einem eigenen Verzeichnis pro Repository, und sie werden nicht mit anderen geteilt. Sie gehen also nicht in die Ver­si­ons­ver­wal­tung und stehen auf einem zweiten Rechner nicht zur Verfügung.

Das ist eine Entscheidung mit Absicht. Was ein Agent sich selbst notiert, ist seine Beobachtung, nicht die Vereinbarung mit dem Team.

Der Index und die Themendateien

Die Selbstnotizen sind zweistufig aufgebaut, und wer das nicht weiß, wundert sich über den Umfang.

Es gibt eine Indexdatei, die bei jedem Start geladen wird, und daneben Themendateien, die es nicht werden. Der Index ist ein Inhalts­ver­zeichnis: eine Zeile je Sache, ein Verweis auf die Datei mit den Einzelheiten. Die Details holt sich der Agent, wenn er sie braucht.

Für den Index gilt eine harte Grenze: die ersten 200 Zeilen oder 25 Kilobyte, je nachdem, was zuerst erreicht ist. Was darüber steht, wird beim Start nicht geladen.

Diese Grenze ist bemerkenswert, weil sie beim Laden leise ist. Eine zu lange Indexdatei wird stillschweigend abgeschnitten, und der abgeschnittene Teil verhält sich genau wie eine Notiz, die nie geschrieben wurde. Gewarnt wird beim Schreiben: Nähert sich der Index einer der beiden Grenzen, erinnert das Werkzeug den Agenten ans Kürzen. Liegt er darüber, gelingt das Schreiben, und der Agent bekommt einen Fehler mit dem Auftrag, den Index neu zu fassen.

Die Grenze gilt nur für diesen Index. Eine Projektanweisung, die beim Start lädt, liest das Werkzeug bis zu einer Größe von 4 MiB vollständig, eine größere überspringt es ganz.

Wann Verdichten nötig wird

Verdichtet wird automatisch, wenn das Gespräch eine Schwelle erreicht. Ohne eigene Einstellung hängt sie am Modell: Die aktuellen Modelle mit einem Fenster von einer Million Token verdichten bei rund 967.000 Token (externe Seite, code.claude.com), ältere Modelle ohne erweitertes Fenster an der Grenze von 200.000. Die Schwelle lässt sich auch selbst setzen, zwischen 100.000 Token und einer Million, mit dem Befehl /autocompact. Ein größeres Fenster schiebt den automatischen Zeitpunkt nur nach hinten.

Ein zweiter Anlass hängt an der Pause. Laut Ein­stel­lungs­re­fe­renz (externe Seite, code.claude.com) verdichtet das Werkzeug eine lange Sitzung, die Sie liegen lassen, kurz bevor ihr Prompt-Cache verfällt. In der Voreinstellung geschieht das nach rund 54 Minuten ohne Anfrage, wenn der Kontext 200.000 Token erreicht hat. Dazu muss die Sitzung interaktiv im Terminal laufen, einen Cache mit einer Stunde Laufzeit haben und Feature Flags beim Hersteller abrufen können. Wer zurückkommt, sieht im Verlauf einen Hinweis darauf. Die Einstellung idleCompaction schaltet das ab. Was eine Pause sonst kostet, steht in Claude Code, Kapitel 05.

Verlässlich ist das Fenster ohnehin nur bis zu einem Punkt vor dieser Grenze. Ein Modell berücksichtigt die Mitte eines langen Kontexts schlechter als Anfang und Ende, ausführlich in Grundkurs, Kapitel 05. Eine Vereinbarung aus der Mitte einer langen Sitzung kann deshalb schon nicht mehr zuverlässig befolgt werden, während die Füllstandsanzeige des Fensters noch die Hälfte frei zeigt.

Was das Verdichten überlebt, vollständig

Ebene 1 hat die Kurzfassung gebracht. Hier die Tabelle des Herstellers in voller Länge, weil zwei Zeilen darin regelmäßig für Verwirrung sorgen:

Die Zeilen zur Pfadbindung und zu den Unter­ver­zeich­nissen sind die Falle. Eine pfadgebundene Regel ist genau deshalb attraktiv, weil sie den Kontext schont, und genau deshalb ist sie nach dem Verdichten weg. Pfadgebundene Regeln und CLAUDE.md-Dateien in Unter­ver­zeich­nissen landen laut Dokumentation (externe Seite, code.claude.com) im Gesprächsverlauf, sobald Claude die Datei liest, schreibt oder bearbeitet, an der sie hängen. Deshalb gehen sie beim Verdichten mit allem anderen in der Zusammenfassung auf.

Praktisch heißt das: Eine Regel, die unbedingt gelten muss, gehört in die Stammdatei oder in eine Regel ohne Pfadbindung, auch wenn sie dort teurer ist. Beide lädt das Werkzeug beim Start und nach dem Verdichten neu. Eine Regel, die nur beim Anfassen bestimmter Dateien zählt, ist pfadgebunden richtig aufgehoben, weil sie mit der Datei wiederkommt.

Hooks stehen zweimal in der Tabelle

Was ein Hook früher in den Verlauf geschrieben hat, ist Text und wird mit dem Rest zusammengefasst. Der Hook selbst ist ein Programm und läuft nach dem Verdichten wie davor. Einer am Sitzungsstart, der auf den Auslöser compact hört, läuft sogar gezielt danach und bringt seinen Text zurück ins Fenster.

Das ist der Grund, warum Hooks in diesem Kurs ein eigenes Kapitel bekommen: Kapitel 12. Sie wirken unabhängig von der Länge des Gesprächs, weil sie selbst kein Kontext sind.

Alles andere in dieser Tabelle ist Text, der gelesen wird oder eben nicht.

Woran man merkt, dass etwas fehlt

Ein Verdacht, der sich prüfen lässt: Wenn ein Agent mitten in einer langen Sitzung oder nach einer längeren Pause anfängt, etwas anders zu machen als vorher, war meistens eine Verdichtung dazwischen.

Die Prüfung dauert eine halbe Minute, und dafür gibt es zwei Befehle. /memory zählt die Orte auf, an denen eine Projektanweisung liegen kann, auch die leeren, und öffnet die Selbstnotizen. /context schlüsselt die Belegung des Fensters auf und nennt dabei, welche Pro­jekt­an­wei­sungen und Selbstnotizen geladen sind. Nur der zweite beantwortet die Frage, was wirklich angekommen ist. Steht dort, was Sie erwarten, liegt es an der Formulierung. Steht es nicht dort, liegt es am Ort.

Wenn man länger mit Agenten arbeitet, kommt irgendwann diese Frage: Was von dem, was gerade im Kopf des Systems ist, kann ich für die nächste Sitzung retten, und wie?

Die Antwort besteht aus drei Hebeln. Zwei davon kennt jeder, der dritte ist der interessante.

Hebel eins: die Zusammenfassung lenken

Der billigste Eingriff. Beim Verdichten lässt sich mitgeben, worauf zu achten ist, und der Unterschied ist genau der zwischen Auswahl und Vermutung: Laut Dokumentation (externe Seite, code.claude.com) behält die Zusammenfassung dann, was Sie auswählen, statt dessen, was der automatische Durchgang für wichtig hält.

Verdichten lässt sich auch nur ein Teil des Gesprächs. Mit /rewind wählt man eine Nachricht und fasst ab dort oder bis dorthin zusammen. Laut Doku zu den Checkpoints (externe Seite, code.claude.com) bleiben dabei etwa die ersten Anweisungen unverändert stehen, wenn man ab der Mitte einer langen Fehlersuche zusammenfasst. Auch hier lässt sich mitgeben, worauf die Zusammenfassung achten soll.

Der Haken: Eine solche Vorgabe wirkt nur für diese eine Verdichtung. Beim nächsten Mal fängt die Frage von vorn an, und wird das Verdichten automatisch ausgelöst, bleibt dafür gar keine Gelegenheit.

Für diesen Fall gibt es eine dauerhafte Form. Laut Funktionsweise-Doku (externe Seite, code.claude.com) bekommt die CLAUDE.md dafür einen eigenen Abschnitt „Compact Instructions“, der festlegt, was beim Verdichten erhalten bleibt. Er steht in der Projektanweisung und liegt damit auch dann im Kontext, wenn das Werkzeug von selbst verdichtet. Wer das automatische Verdichten früher haben will, setzt seine Schwelle herunter, siehe Ebene 2.

Hebel zwei: auf die Platte schreiben

Der einzige Hebel, der ohne Wiederholung auskommt. Was in der Projektanweisung steht, wird nach jedem Verdichten neu gelesen und steht wortgleich wieder da. Dasselbe gilt für die Selbstnotizen des Werkzeugs.

Praktisch ist damit alles gelöst, was dauerhaft gilt. Ungelöst bleibt der Zwischenfall: der Arbeitsstand einer laufenden Sitzung, die halbfertige Entscheidung, die drei Sackgassen, in die man heute schon gelaufen ist. Das gehört nicht in die Projektanweisung, weil es morgen nicht mehr stimmt.

Hebel drei: eine Übergabe, die wieder eingelesen wird

Hier wird es interessant, und hier setzen die meisten an der falschen Stelle an.

Der naheliegende Gedanke lautet: Es gibt ein Ereignis „vor dem Verdichten“, also hängt man dort ein Programm ein, das eine Übergabe schreibt und wieder einspeist. Die erste Hälfte davon geht. Die zweite nicht.

Ein Programm am Ereignis vor dem Verdichten kann das Verdichten anhalten. Beisteuern kann es nichts. Was es ausgibt, landet im Protokoll des Werkzeugs: Bei den meisten Ereignissen schreibt Claude Code die Standardausgabe laut Hook-Referenz (externe Seite, code.claude.com) ins Debug-Protokoll und zeigt sie im Gesprächsverlauf nicht an.

Den Kontext danach erreicht dieser Text nie. Wer anderes annimmt, baut eine Übergabe, die nie ankommt, und merkt es nicht, weil alles fehlerfrei durchläuft.

Einspeisen kann ein anderes Ereignis: der Sitzungsstart. Es kennt fünf Auslöser, und einer davon ist ausdrücklich der Start nach einer Verdichtung. Ein Programm, das dort hängt, darf Text zurückgeben, der in den Kontext übernommen wird.

Die Übergabe läuft damit über zwei Stellen:

1. Schreiben, bevor verdichtet wird. Das kann ein Programm tun, das an das Ereignis vor dem Verdichten gehängt ist, oder schlicht der Agent selbst, wenn Sie ihn darum bitten.
2. Einlesen, nachdem verdichtet wurde, über das Ereignis am Sitzungsstart.

Was in eine Übergabe gehört

Eine Übergabedatei ist etwas anderes als eine Projektanweisung, und sie wird schlecht, wenn man sie wie eine behandelt. Brauchbar sind vier Dinge:

Woran gerade gearbeitet wird, in einem Satz, mit dem Ziel dahinter.

Was schon entschieden ist, damit es nicht neu verhandelt wird. Das ist der Teil, den eine automatische Zusammenfassung am häufigsten verliert, weil eine Entscheidung im Verlauf oft nur ein Halbsatz war.

Was nicht funktioniert hat, mit Grund. Ohne diesen Teil läuft die nächste Sitzung in dieselbe Sackgasse, und zwar zuverlässig.

Der nächste Schritt, ausdrücklich benannt.

Was nicht hineingehört: eine Zusammenfassung des Codes. Der steht auf der Platte und lässt sich lesen.

Verdichten und neu anfangen sind zwei Dinge

Ein Unterschied, an dem sich Erwartungen regelmäßig brechen.

Beim Verdichten bleibt eine Zusammenfassung. Der Verlauf ist ersetzt, das Werkzeug hat aber noch eine Vorstellung davon, worum es ging, und die Pro­jekt­an­wei­sungen kommen von der Platte zurück.

Bei einer neuen Sitzung ist der Verlauf vollständig weg. Zurück bleibt ausschließlich, was auf der Platte steht.

Das klingt nach einer Feinheit und ändert die Praxis. Wer weiß, dass er morgen neu anfängt, muss vorher schreiben. Wer nur verdichtet, kann sich auf die Zusammenfassung stützen, sollte ihr aber nichts anvertrauen, das teuer war.

Ein Gedächtnis kann falsch sein

Und jetzt die Eigenschaft, die alle fünf Orte teilen und die keine Technik löst: Was einmal geschrieben wurde, bleibt stehen, auch wenn es nicht mehr stimmt.

Eine Notiz aus dem Mai, die auf eine Datei zeigt, die es seit Juni nicht mehr gibt, ist schlimmer als keine Notiz. Sie sieht aus wie Wissen, sie wird beim Start geladen, und sie ist überzeugend geschrieben, weil eine Maschine sie geschrieben hat.

Daraus folgen zwei Gewohnheiten, die sich bewährt haben:

Eine Notiz, die eine Datei, eine Funktion oder eine Einstellung nennt, wird geprüft, bevor man ihr folgt. Das gilt besonders für die Selbstnotizen, weil niemand sie durchsieht. Sie stehen als gewöhnliches Markdown auf der Platte und lassen sich lesen, ändern und löschen. Hat eine Notiz einen Kopf mit Metadaten, schreibt das Werkzeug bei jedem Speichern den Zeitpunkt ins Feld modified. Laut Gedächtnis-Doku (externe Seite, code.claude.com) zeigt dieser Zeitstempel, wie aktuell der notierte Sachverhalt ist, Ihnen ebenso wie Claude, wenn es die Notiz wieder einliest.

Das Alter einer Notiz ist damit sichtbar. Ob sie noch stimmt, zeigt das Feld nicht.

Widersprüche meldet das Werkzeug nicht von selbst. Wenn eine alte Notiz einer neuen Regel widerspricht, kann Claude sich beliebig für eine der beiden entscheiden. Das ist derselbe Befund wie bei den gestapelten Pro­jekt­an­wei­sungen in Kapitel 03, nur mit dem Zusatz, dass Sie die eine Hälfte nicht selbst geschrieben haben. Die Prüfung auf Anfrage aus jenem Kapitel geht die Pro­jekt­an­wei­sungen durch. Dazu kommen Regeln, Skills, Befehle, Subagenten und Ausgabestile unter .claude/ im Projekt und im Benut­zer­ver­zeichnis. Die Selbstnotizen nennt die Dokumentation in diesem Umfang nicht.

Der Aufräumtakt

Ein Gedächtnis, das nur wächst, wird unbrauchbar. Für die Indexdatei erzwingt die Grenze aus Ebene 2 das Aufräumen; für alles andere braucht es einen Anlass.

Ein brauchbarer: Immer wenn eine Notiz beim Arbeiten auffällt und nicht mehr stimmt, wird sie in derselben Minute korrigiert oder gelöscht. Das ist derselbe Grundsatz, der eine gute Projektanweisung kürzer werden lässt, und er hat denselben Grund. Zwei widersprüchliche Einträge sind schlechter als einer, der fehlt.