Warum eine memory.md bei KI-Assistenten Tokens spart — und wie man sie richtig aufbaut

Vor ein paar Wochen ist mir aufgefallen, dass ich jedes Gespräch mit meinem Assistenten auf dieselbe Art beginne. Ich erkläre ihm, was wir gerade bauen. Ich erkläre ihm, welche Regeln im Projekt gelten. Ich erkläre ihm, dass der Push auf GitHub nur nach meiner expliziten Freigabe passiert, weil ich dort nicht aus Versehen halbfertigen Code öffentlich machen will. Dann fangen wir an zu arbeiten. Und beim nächsten Morgen erkläre ich dasselbe wieder, weil der Assistent nicht die leiseste Ahnung mehr hat, wer ich bin und was wir vorhaben. Irgendwann wurde das lästig genug, dass ich angefangen habe, es aufzuschreiben. So fängt das Pattern an, das in diesem Artikel steht.

Ein LLM hat zwischen Requests kein Gedächtnis

Der Satz klingt trivial, hat aber Folgen. Ein Sprachmodell ist stateless. Zwischen zwei Requests existiert in ihm kein innerer Zustand, der irgendetwas aus der vorherigen Sitzung weiß. Was deine Sitzungen zusammenhängend wirken lässt, ist ein überraschend simpler Trick: Die Anwendung schickt bei jedem neuen Request den bisherigen Verlauf erneut mit. Was sich wie Gedächtnis anfühlt, ist in Wahrheit eine Wiederholung — jedes Mal aufs Neue, jedes Mal komplett.

Für die Arbeit mit einem KI-Assistenten heißt das: Projektwissen lebt außerhalb des Modells. Entweder in der Anwendung, in der Chat-History, in Dateien im Projekt — irgendwo muss es liegen, sonst ist es weg, sobald die Sitzung endet. Die interessante Frage ist nicht, ob du Projektwissen irgendwo ablegen willst. Die interessante Frage ist, an welcher Stelle, in welcher Form, und wie teuer dich dieser Ort pro Tag zu stehen kommt.

Was eine memory.md ist — und was nicht

Eine memory.md ist eine Textdatei. Mehr steckt nicht dahinter. Kein proprietärer Mechanismus, kein Tool-Feature, kein Plugin. Der Assistent lädt sie beim Start einer Sitzung in seinen Prompt, und von da an weiß er, was drinsteht — weil er sie gelesen hat, nicht weil er sie gelernt hat. Das ist ein wichtiger Unterschied, und er kommt gleich wieder zur Sprache.

Abgrenzung eins: zur CLAUDE.md im Projekt. Die CLAUDE.md enthält statische Projektregeln, die im Repo versioniert sind — Architektur, Coding-Style, Deploy-Pfade. Sie ändert sich selten, sie gehört dem Projekt, sie wandert mit dem Code. Memory ist etwas anderes: dynamisch, wachsend, dokumentiert Erfahrungen und Präferenzen. Zwei verschiedene Arten von Wissen, zwei verschiedene Lebenszyklen, zwei verschiedene Dateien.

Abgrenzung zwei: zu einem echten Langzeitgedächtnis des Modells. Es gibt keines. Was sich nach Gedächtnis anfühlt, ist immer ein Text, den jemand oder etwas in den Prompt gelegt hat. Wenn ein Anbieter „Memory“ als Feature verkauft, steckt fast immer darunter, dass die Anwendung beim Sitzungsstart eine Datei lädt, in der steht, was du in den letzten Wochen für merkenswert erklärt hast. Also genau das, was eine memory.md auch macht — nur unter der Haube und ohne dass du siehst, was wirklich drinsteht.

Abgrenzung drei: zu RAG, also Retrieval-Augmented Generation. RAG ruft Wissen bei Bedarf aus einer Vektordatenbank ab und schiebt nur den relevanten Ausschnitt in den Prompt. Das ist die richtige Wahl, wenn du Hunderte von Dokumenten hast, aus denen pro Frage jeweils nur ein kleiner Teil gebraucht wird. Memory ist etwas anderes: kleiner Umfang, immer im Prompt, keine Vektorsuche, kein Index. Für projektspezifisches Meta-Wissen — Arbeitsweise, Konventionen, laufende Entscheidungen — ist Memory die passendere Ebene. Wer seine eigene Arbeitsweise per RAG lädt, baut eine Bibliothek für etwas, das auf eine Seite passt.

Warum das Pattern Sinn ergibt

Vier Gründe, aus denen ich inzwischen kein Projekt mehr ohne aufsetze. Reproduzierbarkeit ist der erste. Was in der Datei steht, landet zuverlässig im Prompt. Es ist keine trainierte Präferenz, die man nicht mehr loswird, sondern Text, den man lesen, ändern und löschen kann. Wenn der Assistent sich an etwas hält, kann ich nachschauen, warum. Wenn er es nicht tut, kann ich prüfen, ob es überhaupt dort steht. Das klingt banal, aber es ist das Gegenteil von Magie, und Magie ist das Letzte, was man in einer Werkzeugkette haben will.

Der zweite Grund ist die Trennung der Lebenszyklen. Ephemere Aufgaben — „heute noch die Menü-Reihenfolge prüfen“ — haben in derselben Datei nichts zu suchen wie Dinge, die seit einem Jahr gelten — „Push auf GitHub nur nach expliziter Freigabe“. Beides in einen Topf zu werfen bestraft dich später beim Aufräumen. Memory trennt sauber nach Haltbarkeit. Kurzlebiges landet in einem Status oder einer Task-Liste. Memory ist für das, was morgen auch noch gilt.

Der dritte Grund heißt Korrigierbarkeit. Falsche Einträge werden gelöscht wie jeder andere Dateiinhalt. Kein umständliches Umprompten, kein Versuch, eine eingeschliffene Annahme wieder loszuwerden. Wenn sich das Projekt ändert, ändert sich die Memory-Datei. Fertig.

Und der vierte, für mich der eigentlich entscheidende: Transparenz. Der Nutzer kann jederzeit lesen, was der Assistent über das Projekt zu wissen glaubt. Das ist die Gegenthese zu jedem Black-Box-Gedächtnis. Wenn ein Tool mir anbietet, still Vorlieben aus meinen Chats abzuleiten und irgendwo zu speichern, habe ich keine Kontrolle darüber, ob das, was es sich notiert, auch stimmt. Eine sichtbare Datei ist die ehrlichere Lösung. Sie ist die einzige Lösung, bei der ich am Ende sicher weiß, woran mein Assistent morgen ist.

Das Token-Argument, sauber hergeleitet

Jetzt wird es technisch. Der Preis eines Requests skaliert mit der Anzahl der Input-Tokens. Das ist die einfache Seite der Rechnung. Die weniger einfache: Rechenzeit skaliert im Prefill — das ist der erste Verarbeitungsschritt, bei dem der Prompt einmal durch das Modell läuft — überproportional zur Länge. Ein doppelt so langer Prompt ist im Prefill nicht doppelt, sondern rund viermal so aufwendig, weil die Aufmerksamkeit im Modell jedes Token mit jedem anderen vergleicht. Ein großer Prompt kostet dich also zweimal: einmal auf der Rechnung und einmal in Latenz.

Szenario ohne Memory. Die Sitzung startet leer. Der Assistent liest reflexartig eine Handvoll Dateien, nur um zu verstehen, was hier eigentlich läuft: README, zwei bis drei Regeldateien, eine Status-Übersicht, die letzten Commits, oft noch mehrere Quelldateien, weil er nicht weiß, welche für die Aufgabe wirklich relevant sind. Größenordnung: mehrere tausend Tokens pro Sitzungsstart, die keinen Fortschritt erzeugen, sondern nur Kontext herstellen. Das machst du pro Woche vielleicht fünfzig Mal. Die Zahl wird nicht kleiner, nur weil du nicht hinschaust.

Szenario mit Memory. Ein kompakter Index, vielleicht hundert Zeilen. Bei Bedarf ein, zwei gezielt nachgeladene Zusatzdateien. Derselbe Kenntnisstand, deutlich unter tausend Tokens. Der Rest des Kontextfensters — also der maximalen Sequenzlänge, die das Modell pro Request verarbeitet — bleibt frei für die eigentliche Aufgabe. Das ist wichtiger, als es auf den ersten Blick klingt, und dazu gleich ein eigenes Kapitel.

Der eigentliche Hebel liegt aber nicht im Unterschied zwischen dreitausend und tausend Tokens. Er liegt woanders, bei einem Feature, das bei vielen API-Anbietern mittlerweile Standard ist: Prompt-Caching. Anthropic erlaubt es, stabile Prompt-Präfixe zu cachen. Solange sich der Anfang des Prompts nicht ändert, zahlst du für diesen Teil nur noch einen Bruchteil des normalen Input-Preises. Die genauen Werte — Cache-Read-Kosten, Cache-Write-Kosten, TTLs und die Bedingungen, unter denen der Cache überhaupt greift — stehen in der offiziellen Anthropic-Dokumentation zu Prompt Caching. Sie verschieben sich gelegentlich, und deshalb schreibe ich sie hier nicht fest. Als Größenordnung reicht: Cache-Reads sind deutlich günstiger als normale Input-Tokens, Cache-Writes einmalig teurer, und der Cache hat eine begrenzte Haltbarkeit im Bereich weniger Minuten.

Eine memory.md ist für dieses Pattern wie gemacht. Sie ändert sich selten. Sie steht früh im Prompt. Sie wird in jeder Sitzung gebraucht. Wenn ihr Inhalt stabil bleibt, greift der Cache in fast jedem Request. Eine chaotische Ad-hoc-Kontextsuche, bei der der Assistent bei jedem Start andere Dateien lädt, ist das genaue Gegenteil: jeder Request sieht anders aus, der Cache greift nie, du zahlst jedes Mal den vollen Preis. Nicht weil der Cache defekt ist, sondern weil er sich an den Anfang des Prompts bindet und dein Anfang nie gleich aussieht.

Und jetzt das Entscheidende: Die drei Effekte — weniger Tokens, günstigere Tokens durch Cache-Reads, schnelleres Prefill durch kürzere Prompts — addieren sich nicht linear. Sie multiplizieren sich. Wenn du dein Setup von „lies dich überall rein“ auf „lade zuerst das Memory, dann arbeite“ umstellst, sinkt dein Tagesverbrauch oft um einen Faktor, nicht um einen Prozentsatz. Das ist kein Marketing-Versprechen, das ist die Summe aus drei unabhängigen Hebeln, die in dieselbe Richtung ziehen.

Der Nebeneffekt, den niemand auf dem Zettel hat — Qualität

Tokens sparen ist eine Sache. Der Effekt, der mich wirklich überzeugt hat, ist ein anderer, und er hat einen Namen: „Lost in the Middle“. Eine Untersuchung von Liu und Kollegen aus dem Jahr 2023 hat gezeigt, dass Modelle Inhalte am Anfang und am Ende eines Prompts stärker gewichten als Inhalte in der Mitte. Je länger der Prompt wird, desto stärker verdünnen sich relevante Informationen irgendwo dazwischen. Das ist kein kleiner Effekt. Er ist messbar, und er hat Konsequenzen für alles, was du mit langen Kontexten machst.

Die praktische Folge: Ein Prompt, in dem Projektregeln, Nutzerprofil und aktuelle Aufgabe in zwanzigtausend Tokens Code-Dump eingebettet sind, liefert messbar schlechtere Antworten als derselbe Prompt mit zweitausend Tokens Kontext plus einem oder zwei gezielten Dateilesern, wenn sie gebraucht werden. Das Modell hat in beiden Fällen denselben theoretischen Kontext zur Verfügung, aber im zweiten Fall treten die relevanten Stellen klarer hervor, weil ihre Nachbarschaft weniger Rauschen enthält. Weniger Kontext ist manchmal mehr Kontext.

Noch wichtiger ist aber, was auf deiner Seite des Schreibtischs passiert, sobald du anfängst, eine Memory-Datei zu pflegen. Du musst dich entscheiden. Was bleibt drin, was fliegt raus, was kommt in einen eigenen Abschnitt, was ist für eine Zeile im Index zu unwichtig. Diese Verdichtung ist der eigentliche Qualitätsgewinn. Tokens zu sparen ist angenehm. Aber eine memory.md zwingt dich dazu, dir über deine eigene Arbeitsweise so klar zu werden, dass sie in einem kurzen Absatz Platz findet. Damit wird sie nicht nur für den Assistenten verständlicher, sondern auch für dich selbst in einem halben Jahr, wenn du dich fragst, warum damals eigentlich bestimmte Entscheidungen so und nicht anders gefallen sind.

Wie man Memory strukturiert

Nach zwei Jahren mit dem Pattern haben sich ein paar Prinzipien durchgesetzt, die ich inzwischen nicht mehr diskutiere. Den Index schlank halten. Eine Zeile pro Eintrag, unter zweihundert Zeilen insgesamt. Kein Fließtext im Index, nur Verweise auf die eigentlichen Memory-Dateien. Das klingt pedantisch, hat aber einen harten Grund: Der Index wird bei jedem Sitzungsstart geladen, alle anderen Dateien nur bei Bedarf. Jede Zeile, die du in den Index schreibst, zahlst du hundert- oder tausendfach. Jede Zeile, die du in eine Einzeldatei schreibst, zahlst du nur, wenn sie wirklich gebraucht wird.

Splitting nach Typ. Nutzerprofil, Arbeitsweise-Regeln, Projektstand, Referenzen. Jeder Typ hat eine andere Halbwertszeit. Projektstand veraltet in Wochen. Nutzerprofil hält Monate bis Jahre. Wenn beides in einer Datei landet, löschst du beim nächsten Wartungsdurchgang reflexartig das Falsche mit. Getrennte Dateien erlauben gezieltes Löschen und Aktualisieren, ohne den Rest anzufassen. Es ist die Datenbank-Normalisierung des Memory-Patterns.

Frontmatter pro Memory-Datei. Ein kurzer Kopf mit Name, Beschreibung und Typ — damit der Assistent beim Indexlesen schon weiß, welche Datei für eine konkrete Frage relevant sein könnte, ohne sie laden zu müssen. Das ist der eigentliche Grund, warum Frontmatter sich lohnt, nicht Ordnungsliebe um ihrer selbst willen. Eine gute Beschreibung spart einen vollständigen Lese-Request.

Semantische Gruppierung, keine chronologische. „Nutzer bevorzugt knappe Antworten“ hat in einer Datei mit „Deployment läuft über GitHub Actions“ nichts zu suchen. Andere Lebenszyklen, andere Leser, andere Gründe für Änderungen. Ich habe am Anfang alles in eine einzige Datei gepackt und nach ein paar Wochen gemerkt, dass ich beim Editieren ständig nach einem bestimmten Abschnitt gesucht habe. Das ist das Signal, nach dem getrennt werden muss.

Das Präfix-Prinzip. Je weiter vorn im Prompt ein Textblock steht und je seltener er sich ändert, desto höher die Cache-Trefferquote. Memory gehört an den Anfang, nicht ans Ende. Wer es ans Ende hängt, verschenkt den wichtigsten Vorteil — und holt sich nebenbei auch noch das „Lost in the Middle“-Problem zurück, weil der relevante Kram mitten im Code-Dump landet. Zwei Fliegen, eine Klappe, beide falsch rum geworfen.

Was nicht ins Memory gehört

Genauso wichtig wie das, was hineinkommt, ist das, was draußen bleibt. Ableitbares aus dem Code. Dateipfade, Funktionssignaturen, Projektstruktur, Klassenlisten — der Assistent kann sie lesen, wenn er sie braucht. Ein Memory, das die Verzeichnisstruktur des Projekts auflistet, ist doppelte Haltung: einmal im Dateisystem, einmal in der Memory-Datei. Und sobald der Code sich ändert, hast du zwei Wahrheiten, von denen nur eine korrekt ist. Welche das ist, merkst du meistens erst, wenn der Assistent sich auf die falsche verlässt.

Ephemere Aufgaben. „Heute noch X machen“ gehört in einen Plan, in ein Task-System, meinetwegen in eine TODO-Liste — aber nicht ins Memory. Memory ist für Dinge, die morgen auch noch gelten. Wenn du dein Memory mit Aufgaben füllst, hast du in ein paar Wochen einen Friedhof erledigter Punkte, durch den du dich beim nächsten Aufräumen kämpfen musst, und du wirst die falschen Dinge löschen.

Debug-Lösungen. Die Begründung eines Fixes steht in der Commit-Message. Dort wird sie später gesucht, dort gehört sie hin. Das Memory ist nicht die Stelle für „damals hatten wir mal ein Problem mit X, die Lösung war Y“ — das ist das, wofür ein Versionskontrollsystem existiert, und es macht es besser als jede Markdown-Datei.

Duplikate aus der CLAUDE.md. Was schon in den Projektregeln steht, muss nicht zusätzlich als Memory existieren. Zwei Quellen derselben Wahrheit sind eine Quelle zu viel, und zwar genau die, die als erstes veraltet. Ich habe mir angewöhnt, bei jedem neuen Memory-Eintrag ganz kurz zu prüfen, ob die Aussage nicht eigentlich eine statische Projektregel ist, die einfach noch nicht aufgeschrieben wurde. Wenn ja, gehört sie in die CLAUDE.md, nicht in die Memory-Datei.

Wartung — die unangenehme Wahrheit

Hier wird es unangenehm, weil es nicht um Mechanik geht, sondern um Disziplin. Veraltetes Memory ist schlimmer als fehlendes Memory. Der Assistent handelt auf Grundlage überholter Informationen und erzeugt Fehlverhalten, das schwer zu diagnostizieren ist, weil die Ursache nicht im Code liegt, sondern im Prompt. Ich habe einmal über eine Stunde damit zugebracht, ein mysteriöses Verhalten zu debuggen, von dem sich am Ende herausstellte, dass es aus einer drei Monate alten Memory-Zeile stammte, die ich nie aktualisiert hatte. Der Code war in Ordnung. Das Memory war es nicht.

Projekt-Snapshots altern schnell. Ein Eintrag wie „Stand 2026-04-06: 38 von 43 BRIEFs done“ ist nach zwei Wochen wertlos und nach zwei Monaten irreführend. Solche Einträge brauchen entweder ein Ablaufdatum, das sie unbrauchbar macht, oder sie gehören überhaupt nicht ins Memory. Ich habe mir angewöhnt, Zähler und Tagesstände konsequent in eine separate Status-Datei auszulagern, die wie ein Logbuch neben dem Memory liegt. Das Memory bleibt dadurch so stabil, wie ich es brauche, und der Status ist dort, wo Volatiles hingehört.

Die Konfliktregel. Wenn ein Memory-Eintrag zum aktuellen Code im Widerspruch steht, gewinnt der Code. Immer. Das Memory wird gelöscht oder korrigiert, nicht der Code um das Memory herum gebogen. Diese Regel klingt selbstverständlich, aber sie ist es nicht — es ist erstaunlich verlockend, einen Eintrag zu retten, nur weil man ihn einmal für richtig gehalten hat. Wer das zulässt, baut technische Schulden in sein KI-Setup, die niemand im Code findet, weil sie gar nicht im Code stehen.

Review-Rhythmus. Ein kurzer Blick auf den Index alle paar Wochen reicht. Was ist in der letzten Zeit nicht mehr aufgetaucht? Was davon darf verschwinden? Welche Einträge klingen nach einem Kontext, den es so nicht mehr gibt? Zehn Minuten, die dir Stunden Fehlersuche ersparen. Kein großes Ritual, keine Meeting-Serie — einfach hinsetzen, drüberlesen, wegstreichen.

Wo das Memory liegen sollte — und wo nicht

Diese Sektion ist die direkte Lehre aus einem Audit über fast zwanzig meiner eigenen Projekte. Ich bin aus Schaden klug geworden, und der Schaden war größer, als ich zugeben wollte.

Viele Werkzeuge bringen ihr eigenes Memory-System mit. Claude Code zum Beispiel legt Memory unter ~/.claude/projects/<slug>/memory/ ab. Das ist bequem, hat aber zwei harte Nachteile. Erstens liegt es im User-Profil, also außerhalb des Projekts. Wenn du das Projekt auf einen anderen Rechner kopierst, wandert das Memory nicht mit. Zweitens — und das ist der härtere Punkt — wenn gleichzeitig eine projektinterne Memory-Datei existiert, hast du zwei Quellen. Beide werden geladen, beide werden gepflegt, beide entwickeln sich auseinander, und eine davon ist irgendwann falsch. Meistens die, die außerhalb des Projekts lebt, weil man sie vergisst, sobald man sich an die im Projekt gewöhnt hat.

Die Regel, an die ich mich jetzt halte: Memory gehört dorthin, wo der Code liegt. In meinem Fall unter <projekt>/.ai/memory.md, versioniert im Repo. Es wandert mit dem Projekt, es ist nachvollziehbar über die Git-History, es gehört dem Projekt und nicht der Maschine. Ich habe meine gesamte Regelarchitektur für KI-gestützte Entwicklung so umgebaut, dass alles, was für das Projekt wichtig ist, auch im Projekt liegt. Kein Ort außerhalb, in dem sich heimlich Wissen ansammelt. Single Source of Truth — eine Quelle, nicht zwei.

Was wird aus der externen Memory-Quelle, wenn ich sie nicht mehr pflege? Ich habe sie nicht gelöscht, sondern zum Wegweiser gemacht. Fünf bis acht Zeilen, in denen steht, wo das echte Memory liegt. Beim nächsten Sitzungsstart sieht der Assistent diesen Wegweiser, versteht die Absicht und weiß, dass er die Projekt-Datei lesen soll, nicht den Wegweiser pflegen. Das Tool-Feature bleibt funktional, es hat nur eine neue Aufgabe bekommen: nicht mehr selbst die Wahrheit sein, sondern auf die Wahrheit zeigen.

Das konkrete Beispiel aus dem Audit. In einem Projekt war die externe Memory-Index-Datei über die Monate auf 165 Zeilen angewachsen. Sie enthielt eine komplette Verzeichnisstruktur. Eine Liste aller Test-Projekte mit Zählern. Architektur-Notizen. Stack-Beschreibungen. BRIEF-Historie. Alles davon stand bereits im Projekt selbst — in einem Architektur-Dokument, einer Status-Datei, im Quellcode, in den Commit-Messages. Doppelte Haltung an zwei Orten, mit der unausweichlichen Konsequenz, dass eine der beiden Versionen veraltet ist. Hier war es die externe. Eine Stunde Aufräumarbeit hat das Memory auf vierzehn Zeilen reduziert, ohne dass ein einziger Informationspunkt verlorengegangen wäre. Alles davon war an einer anderen Stelle bereits sauberer dokumentiert. Ein gutes Memory zeichnet sich dadurch aus, wie wenig es enthält, nicht wie viel.

Und dann gibt es noch den unauffälligsten, aber teuersten Fehler: Cache-Präfix-Stabilität. Ein Memory mit „Stand 2026-04-10: aktiver Brief 211, 576 Tests grün“ in Zeile sieben ist ein Cache-Killer. Jede neue Sitzung schreibt ein anderes Datum an dieselbe Stelle, jede Änderung verschiebt den Anfang des Prompts, und weil Prompt-Caching auf dem stabilen Anfang aufsetzt, greift ab dieser Zeile kein Cache mehr. Du zahlst ab Zeile sieben wieder den vollen Preis, und zwar für den gesamten restlichen Kontext. Das Datum gehört in die referenzierte Status-Datei, nicht in die Indexzeile. Diese eine Änderung — Datumsstempel raus aus dem stabilen Präfix — ist die billigste Token-Sparmaßnahme, die ich kenne, und die meisten Setups haben sie noch nicht gemacht.

Was sich im Alltag ändert

Weniger Wiederholung. Was einmal erklärt wurde, bleibt erklärt. Ich muss dem Assistenten nicht in jeder neuen Sitzung erklären, dass der Push auf GitHub nur nach Freigabe erfolgt — es steht in zwei Zeilen im Memory, und er handelt danach. Das ist keine große Sache, wenn man es einmal macht. Es ist eine große Sache, wenn man es fünfzig Mal pro Woche nicht mehr machen muss.

Konsistenteres Verhalten über Sitzungen hinweg, weil bei jedem Start dieselben Grundlagen geladen werden. Keine „heute versteht er mich, morgen nicht“-Effekte. Wenn zwei Sitzungen unterschiedlich verlaufen, liegt es jetzt am Thema, nicht am Kontext-Zufall, und ich kann tatsächlich lernen, woran ein Ergebnis hängt.

Schnellere Einstiege. Statt „lies erst mal alles“ reicht „lies das Memory und dann den aktuellen BRIEF“. Der Kontext ist minimal, aber vollständig. Das erste sinnvolle Codeergebnis landet nicht nach dreizehn Minuten im Editor, sondern nach drei.

Bessere Priorisierung, weil der Assistent den Rahmen kennt. Er fragt nicht mehr jedes Mal nach, ob man jetzt committen darf oder nicht, weil die Antwort im Memory steht. Dinge, die konstant sind, werden konstant behandelt. Fragen werden dann gestellt, wenn sie wirklich neu sind — und genau dort will man sie auch haben.

Ganz nebenbei wird der Umgang mit dem eigenen Projekt strukturierter. Wer Memory pflegt, zwingt sich zu einer Klarheit über seine eigenen Konventionen, die vorher so nicht existierte. Ich habe beim Aufschreiben Dinge entdeckt, die ich zwar intuitiv gemacht, aber nie formuliert hatte. Und manche davon waren Unsinn, der nur deshalb noch da war, weil ich ihn nie ausgesprochen hatte. Memory ist in diesem Sinne auch ein Spiegel. Unangenehm, aber nützlich.

Fazit

Eine memory.md ist kein Komfort-Feature. Sie ist die rationalste Antwort auf eine einfache technische Tatsache: LLMs sind stateless, jeder Token im Kontextfenster kostet Geld und Latenz, und dieselbe Information dreimal pro Tag neu zusammenzusuchen ist teuer — in allen drei Währungen, die ein Entwickler hat. Memory ist billig zu pflegen, einfach zu verstehen, jederzeit korrigierbar. Und sie zahlt sich messbar aus, sobald Prompt-Caching ins Spiel kommt.

Die ehrliche Bilanz nach dem Audit: Die Token-Ersparnis allein ist nicht der wichtigste Effekt. Der wichtigste ist, dass das Projektwissen nach dem Aufräumen an einem einzigen Ort liegt — nachvollziehbar, korrigierbar, mitwandernd. Vorher war es überall verteilt, jeder Ort hatte seine eigene Wahrheit, und der Assistent musste raten, welche gerade stimmt. Tokens zu sparen war angenehm. An einem konsistenten Memory zu arbeiten, das man sechs Monate später noch versteht, war wertvoller. Es hat mich nebenbei gelehrt, dass ein großer Teil meiner KI-Probleme gar keine KI-Probleme waren. Es waren Ordnungsprobleme, die durch ein KI-Werkzeug sichtbar geworden sind. Das ist die gleiche Einsicht, die man auch aus einem systematischen Audit der eigenen Regeldateien mitnimmt, nur an einer anderen Stelle des Aufbaus.

Der ehrliche Schlusssatz: Memory-Management ist weniger ein KI-Thema als ein Disziplin-Thema. Wer sein Projektwissen ordentlich aufschreibt, arbeitet besser mit einer KI — und, ganz zufällig, auch besser mit sich selbst in sechs Monaten, wenn man das Projekt wieder aufmacht und sich fragt, warum man damals eigentlich bestimmte Entscheidungen so getroffen hat. Die Antwort steht dann im Memory. Dort, wo sie hingehört.