Claude Code Memory-Systeme: Die 6 Stufen erklärt

Claude Code Memory-Systeme: Die 6 Stufen erklärt

Ich hätte letzten Dienstag fast meine ganze Content-Operation kaputtgemacht, indem ich mein Memory-System auf eine Stufe upgradete, die ich gar nicht brauchte.

Das Setup, das mein Business antreibt: 232 veröffentlichte Posts auf mejba.me, vier Brand Voices, ein @aria-Agent, der 3.000-Wörter-Artikel in einem Rutsch schreibt, und eine Memory-Schicht, die sich an den Ton jeder Marke, jeden Cluster, jede verbotene Phrase, jede Footer-Vorlage erinnern muss. Etwa drei Monate lang waren das nur zwei Markdown-Dateien. Dann las ich einen Thread, der behauptete, „echte" Claude-Code-User würden RAG-gestützte Memory Palaces mit Vektorindizes betreiben, und ich verbrachte einen ganzen Nachmittag damit, einen anzuschließen.

Am Ende des Nachmittags hatte ich drei Skills kaputt gemacht, die Auto-Memory eines Projekts beschädigt und exakt null neuen Content produziert. Also rollte ich das Ganze zurück, öffnete ein leeres Dokument und zwang mich, tatsächlich zu kartieren, wie Claude-Code-Memory in 2026 aussieht — jede Stufe, was sie kostet, für wen sie ist. Nicht in der Theorie. Basierend darauf, was ich tatsächlich gefahren habe, was ich andere Operatoren fahren sehe und was ich schiefgehen sehe.

Es gibt sechs Stufen. Die meisten Leute, die Claude Code nutzen, müssen nie über Stufe drei hinaus klettern. Ein paar müssen es. Die falsche Stufe zu wählen — zu einfach oder zu komplex — verbrennt Wochenenden. Dieser Post ist die Karte, die ich mir gewünscht hätte, bevor ich anfing zu klettern.

Warum Claude-Code-Memory in 2026 überhaupt wichtig ist

Wenn du Claude Code als verherrlichte Autovervollständigung nutzt, ist Memory irrelevant. Tab öffnen, Prompt eintippen, schließen, fertig. Das Modell muss sich nichts über dich merken, weil es nichts zu merken gibt.

Aber sobald dein Workflow eine Form hat — wiederkehrende Aufgaben, Brand Voices, Code-Konventionen, Entscheidungen, die du getroffen hast und nicht jeden Montag neu erklären willst — wird Memory zum größten einzelnen Hebel zwischen „Claude ist manchmal hilfreich" und „Claude ist ein Teammate". Das ist keine Marketingsprache. Das bin ich, der zusieht, wie derselbe Agent vom Generieren generischer SEO-Posts dazu kommt, meine Brand Voice beim ersten Versuch zu treffen, einfach weil ich ihm eine strukturierte Memory-Schicht gegeben habe, in die er greifen kann.

Das Problem in 2026 ist, dass „Claude-Code-Memory" jetzt mindestens sechs verschiedene Architekturen meint, von einer Markdown-Datei in deinem Projekt-Root bis zu einer selbstgehosteten Postgres-Datenbank mit Embeddings, die über Claude, ChatGPT und Cursor hinweg geteilt werden. Die offiziellen Docs decken die erste gut ab. Die Community hat die anderen fünf gebaut. Fast niemand erklärt, wo jede aufhört, die Komplexität wert zu sein.

Und das ist die Frage, die mich tatsächlich interessiert. Denn jede Stufe oberhalb derjenigen, die du brauchst, ist nur Steuer — Engineering-Steuer, Debugging-Steuer, Aufmerksamkeits-Steuer. Also gehen wir sie durch.

Stufe 1: Basic Native Memory (claude.md + memory.md)

Das ist, womit Claude Code ausgeliefert wird. Kein Plugin. Keine Vektordatenbank. Keine Hooks. Nur zwei Markdown-Dateien, die das Modell beim Session-Start lädt.

claude.md ist deine projektweite Anweisungsdatei. Du schreibst sie. Sie enthält die Regeln, Konventionen, Brand Voices, verbotene Phrasen, Dateipfade — alles, was das Modell jedes Mal wissen soll, wenn du eine Session in diesem Verzeichnis öffnest. Laut den official Claude Code docs wird die Datei automatisch in den Kontext geladen und als verbindliche Projekt-Guidance behandelt.

memory.md (auch Auto-Memory genannt) ist, was Claude über dich schreibt. Wenn du es korrigierst („benutze in dieser Codebase keine Semikolons"), oder es einen Build-Befehl herausfindet oder eine Workflow-Präferenz lernt, fragt es, ob es das als Memory speichern soll. Du bestätigst. In der nächsten Session erinnert es sich.

Zusammen bilden diese beiden Dateien eine arbeitende Memory-Schicht, die null Dollar kostet, vollständig auf deiner Maschine läuft und vielleicht 70 % dessen abdeckt, was ein Single-Developer- oder Solo-Operator-Workflow braucht. Meine Haupt-claude.md für das ai-agents-team-Repo läuft auf etwa 180 Zeilen. Sie definiert die vier Brand Voices, das Output-Format, die harten Constraints, das Verzeichnis-Layout. Das war's. Keine Vektoren. Keine Embeddings. Keine Daemons.

Der Haken — und das ist der Haken, vor dem dich niemand warnt — ist Context Rot. Wenn claude.md über etwa 200 Zeilen wächst, beginnt das Modell, sie zu überfliegen. Spezifische Regeln werden ignoriert. Verbotene Phrasen schleichen sich zurück in den Output. Du fängst an zu denken, das Modell sei kaputt, aber eigentlich hast du nur zu viel in den aufmerksamkeitswürdigsten Slot des Kontextfensters gestopft. Ich habe das in meinem eigenen Setup dreimal beobachtet. Der Fix ist immer derselbe: Datei aufteilen oder dauerhafte Regeln in etwas Strukturierteres verschieben.

Für wen Stufe 1 ist: Jeder, der gerade mit Claude Code anfängt. Jeder, dessen gesamter Workflow in ein Projekt passt. Jeder, der „Was muss diese KI über mich wissen?" in unter 200 Zeilen beantworten kann. Wenn du diese Frage noch nicht beantworten kannst, hast du kein Memory-Problem — du hast ein Klarheitsproblem, und Infrastruktur hinzuzufügen wird das nicht beheben.

Wo es bricht: In der Woche, in der du merkst, dass du sieben verschiedene claude.md-Dateien über sieben Projekte hinweg pflegst, die alle dieselben Kernregeln wiederholen.

Stufe 2: Erweiterte Memory-Injection (Hooks + Ordnerstruktur)

Hier habe ich den Großteil von 2026 gelebt. Hier haben sich auch die meisten Leute eingerichtet, die ich in diesem Bereich respektiere.

Die Idee ist einfach. Statt einer riesigen claude.md teilst du Memory in eine Ordnerstruktur auf — meist drei Buckets:

• general/ — projektübergreifende Regeln. Voice, Ethik, Output-Formatierung.
• domain/ — themenspezifische Memory. SEO, Copywriting, Security, Design.
• tool/ — toolspezifische Memory. Claude-Code-Skills, Figma-MCP-Nutzung, Webflow-Stolpersteine.

Dann fügst du einen Session-Start-Hook hinzu — ein Skript, das in dem Moment läuft, in dem Claude Code hochfährt. Der Hook liest einen Index deiner Memory-Ordner und injiziert nur das relevante Stück in den Kontext. SEO gebraucht? Hook injiziert die SEO-Memory. Arbeitest an einem Design-System? Es zieht die Design-Memory und überspringt den Rest.

Hooks aren't natural-language instructions — sie sind Skripte, die bei Events feuern. PreToolUse, PostToolUse, SessionStart, UserPromptSubmit. Die offiziellen Docs in 2026 sind in dieser Unterscheidung klar, und sie ist wichtig: Hooks sind deterministisch. Sie laufen, ob das Modell „Lust hat" oder nicht. Das ist der ganze Punkt.

Was du aus Stufe 2 bekommst:

1. Kein Context Rot. Jedes injizierte Stück bleibt klein und spezifisch.
2. Team-Sharing. Dein Memory-Ordner ist einfach Markdown — committe ihn in Git, dein Teammate cloned ihn, sie bekommen deine Standards.
3. Selektives Recall. Arbeitest du an einem Laravel-Projekt? Die Figma-Memory lädt nicht. Dein Kontextfenster bleibt sauber.
4. Versionierung. Memory ist jetzt ein getracktes Artefakt, kein Runtime-Seiteneffekt.

Die Kosten sind ein Nachmittag Setup. Du schreibst die Ordnerstruktur, schreibst ein winziges Hook-Skript (meines sind 40 Zeilen Bash plus eine JSON-Config), testest es einmal, und dann läuft es einfach. Ich behandle das breitere Hook-Muster in meinem Beitrag zu automating SEO checks with Claude Code routines — dieselbe Architektur, andere Anwendung.

Für wen Stufe 2 ist: Jeder, der Claude Code länger als einen Monat nutzt. Jeder, dessen Memory-Datei die 200-Zeilen-Grenze überschritten hat. Jeder, der mit einem Team arbeitet. Jeder, der Multi-Projekt-Workflows fährt, bei denen sich die Regeln überschneiden, aber nicht identisch sind.

Wo es bricht: Wenn dein Memory-Ordner eine bestimmte Größe erreicht — sagen wir 50+ Dateien — und der Index-Hook beginnt, zu viele „relevante" Stücke zu injizieren oder, schlimmer, das wirklich relevante verfehlt. An diesem Punkt reicht keyword-artige Relevanz-Bewertung nicht mehr aus. Du brauchst Semantik.

Stufe 3: Semantische Vektorsuche mit MemSearch

Das ist die Stufe, die ich aktuell fahre, und die Stufe, bei der ich empfehle anzuhalten, es sei denn, du hast einen spezifischen Grund, weiterzugehen.

MemSearch ist ein markdown-first Memory-System, veröffentlicht von Zilliz, dem Team hinter Milvus. Ihre eigene Beschreibung nennt es „a standalone library for any AI agent, inspired by OpenClaw." Das Claude-Code-Plugin sitzt auf der Kern-CLI auf, und die Architektur ist ehrlich darüber, was sie ist: eine hybride Retrieval-Schicht über reinen Markdown-Dateien.

Hier ist, was interessant ist. MemSearch ersetzt deine Memory-Dateien nicht. Es indexiert sie. Deine Memory lebt weiterhin als menschenlesbares Markdown — du kannst es in jedem Texteditor bearbeiten, in Git versionieren, im Flieger ohne Internet lesen. Der Vektorindex ist ein Cache. Laut dem Milvus blog post on MemSearch „rebuilds [the index] from Markdown at any time."

Drei Recall-Schichten:

1. Long-term facts — dauerhaftes Wissen. Brand-Voice-Regeln, Security-Policies, architektonische Entscheidungen.
2. Daily notes — Session-Zusammenfassungen mit Timestamp, Session-ID, Turn-ID. Plain Text. Vollständig menschenlesbar.
3. Dreaming / promotion — periodische Verdichtung, bei der Kurzzeitnotizen in Long-Term-Facts hochgestuft werden, wenn sie sich als dauerhaft erweisen.

Retrieval nutzt hybride Suche — semantische Vektoren für „finde Inhalte zu dieser Anfrage, auch wenn die Formulierung anders ist", plus BM25 für „finde Inhalte, die diese exakten Keywords nutzen", zusammengeführt mit Reciprocal Rank Fusion (RRF) Reranking. Dieser letzte Teil schlägt Keyword-Suche bei Skalierung. Wenn meine Memory 400 Markdown-Chunks über vier Marken hinweg hat, findet semantische Suche die colorpark.io-Brand-Voice-Regel, selbst wenn ich meinen Prompt in völlig anderen Worten formuliert habe, als ich in der Memory-Datei verwendet habe. Keyword-Suche würde das verfehlen. Semantik + BM25 + RRF fängt beides ein.

Das Retrieval ist außerdem gestaffelt, was ich liebe:

• L1 (automatisch): Top-3 semantische Ergebnisse mit Vorschauen, injiziert bei jedem Prompt. Deckt die meisten Anwendungsfälle ab.
• L2 (on-demand): vollständige Markdown-Sektionen, wenn der ganze Kontext gebraucht wird.
• L3 (deep): rohe Konversationsaufzeichnungen, wenn du den exakten Dialog aus einer vergangenen Session brauchst.

Bei mir trifft L1 etwa 90 % dessen, was ich brauche. L2 feuert, wenn ich etwas Dichtes schreibe und das vollständige Voice-Profil einer Marke brauche. L3 habe ich in zwei Monaten vielleicht zweimal genutzt — beide Male, um die exakte Formulierung einer Kundenentscheidung zu finden.

Das Setup ist eine Plugin-Installation plus ein Vector Store (Milvus läuft lokal; du kannst es auch auf eine gemanagte Variante richten). Die Kosten sind deine Zeit, die du brauchst, um zu lernen, was jede Schicht macht. Die erste Woche fühlt sich überengineert an. In der zweiten Woche bemerkst du es nicht mehr, weil es einfach funktioniert.

Für wen Stufe 3 ist: Operatoren mit substanzieller akkumulierter Memory — sagen wir 100+ Markdown-Dateien, oder ein Jahr Session-Historie, oder Multi-Brand-Workflows wie meiner. Solo-Founder, die ein AI-First-Business betreiben. Jeder, dessen Stufe-2-Setup begonnen hat, das relevante Stück bei komplexen Prompts zu verfehlen.

Wo es nicht mehr ausreicht: Wenn du wortwörtlichen Recall vergangener Konversationen brauchst, nicht semantisch ähnliche Paraphrasen. Oder wenn deine Memory irgendwo anders leben muss als auf deinem Laptop.

Das ist auch der Punkt, an dem die meisten Content-Operatoren tatsächlich stoppen sollten. Ich habe Stufen 4, 5 und 6 getestet und bin jedes Mal zu Stufe 3 zurückgerollt — weil die marginale Recall-Verbesserung die operationelle Komplexität für meinen tatsächlichen Job, nämlich Artikel auszuliefern, nicht wert war. Wenn dein Job etwas anderes ist, kann die Mathematik kippen. Schauen wir, wann.

Stufe 4: Wortwörtliches Recall mit Memory Palace (RAG)

Hier beginnt Memory-Architektur wie echtes Engineering auszusehen, und hier solltest du anhalten und fragen, ob du es tatsächlich brauchst.

Ein Memory Palace — manchmal Me Palace, MemPalace oder Memory-Palace-RAG genannt — ist ein Retrieval-Augmented-Generation-System, das exakten Konversationstext in einer symbolisch indexierten Struktur speichert. Die Metapher ist die antike Mnemotechnik: Du hast Flügel, Räume in diesen Flügeln, Schränke in diesen Räumen und Schubladen in diesen Schränken. Jede Schublade enthält einen spezifischen wortwörtlichen Chunk. Pointer indexieren alles.

Die veröffentlichten Zahlen zu den besseren Implementierungen sind real: rund 42 ms Retrieval-Latenz über indexierte Pointer, mit dem, was ihre Autoren als höchsten veröffentlichten Recall-Benchmark im Open-Source-Memory-Bereich beanspruchen. Architektur ist typischerweise SQL plus Vektor-DB — SQL für den strukturierten Pointer-Index, Vektoren für den semantischen Match. Lokal. Kostenlos. Selbst hostbar.

Warum würdest du das wollen? Weil semantische Suche auf Stufe 3 Paraphrasen und Zusammenfassungen zurückgibt. Ein Memory Palace gibt die exakten Worte zurück, die jemand sagte, in der exakten Reihenfolge, mit der exakten Zeichensetzung. Für manche Workflows zählt das enorm:

• Rechts- oder Compliance-Arbeit — du brauchst die wortwörtliche Formulierung einer Klausel.
• Therapie- oder Coaching-Notizen — du musst dem Klienten seine eigene Formulierung zurückzitieren.
• Recherche-Transkripte — du musst exakt zitieren, was in Interview 47 gesagt wurde, nicht eine Zusammenfassung.
• Lange RPGs oder Fiktionsprojekte — der Charakter muss sich daran erinnern, was er tatsächlich in Kapitel 3 gesagt hat.

Für meinen Content-Workflow? Ich brauche keinen wortwörtlichen Recall. Wenn ich einen Artikel über Claude Code schreibe, muss ich nicht zitieren, was ich vor sechs Monaten über Claude Code gesagt habe — ich brauche nur den Kern. Also wäre Memory Palace teure Infrastruktur, in die ich nie hineingreifen würde.

Für wen Stufe 4 ist: Leute, deren Arbeit von exakter Formulierung abhängt. Recht, Medizin, Forschung, bestimmte Creative-Writing-Pipelines, Voice-of-Customer-Analyse, bei der Paraphrasieren die Daten zerstört.

Wo es bricht: Wenn du mehr Zeit damit verbringst, die Index-Hierarchie zu tunen, als das Recall tatsächlich zu nutzen. Memory Palaces haben eine echte Wartungssteuer — du betreibst jetzt eine kleine Datenbank, und Datenbanken brauchen Pflege.

Stufe 5: Verknüpfte Wissensbasis (LLM-Wiki)

Das ist die Stufe, die den meisten Hype bekommt, weil Andrej Karpathy sie erwähnt hat. Es ist auch die Stufe, die am häufigsten falsch angewendet wird.

Das Muster, ursprünglich aus Karpathy's gist on LLM Knowledge Base architecture, ist: Statt Query-Time-RAG zu machen, lässt du ein LLM deine eingehenden Quellen — Artikel, Podcasts, Transkripte, PDFs — in ein dauerhaftes, durchsuchbares Markdown-Wiki kompilieren. Die Synthese passiert einmal beim Ingest. Danach ist jedes Retrieval einfach das Lesen einer fertigen Seite. Wie VentureBeat summarized it, agiert das LLM als „full-time research librarian, actively compiling, linting, and interlinking markdown files."

Zwei Ordner:

• raw/ — schreibgeschützte Inputs. Transkripte, Artikel, Rohnotizen. Niemals modifiziert.
• wiki/ — KI-verwaltet. Enzyklopädiestil-Synthese-Seiten mit Backlinks zwischen Konzepten.

Du kannst das Ganze in Obsidian visualisieren, das das Markdown-Wiki als navigierbaren Wissensgraphen rendert — durch Linien verbundene Boxen, die Art Sache, die in einem Screenshot wunderschön aussieht und tatsächlich nützlich ist, wenn dein Job Recherche ist.

Mehrere Community-Implementierungen existieren. Das OpenClaw-memory-wiki-Plugin kompiliert Workspace-Memory in ein Wiki-Verzeichnis mit einem Index-Katalog, Modulsynthese-Seiten und maschinenlesbaren Digests. Es gibt eine Karpathy-style LLM wiki Agent Skill für OpenClaw und Codex. Es gibt obsidian-wiki, ein Framework für KI-Agenten, um ein Obsidian-Wiki nach Karpathys Muster zu bauen und zu pflegen.

Das ist wunderschöne Architektur. Sie ist auch falsch für operationelle Projekt-Memory. Hier ist warum.

Ein Wiki ist eine statische Referenz. Es ist optimiert für „Ich möchte über X lesen". Aber operationelle Projekt-Memory muss „Was war die Regel zu X?" oder „Was haben wir letzten Sprint zu X entschieden?" beantworten. Das ist ein anderes Zugriffsmuster. Zu versuchen, ein LLM-Wiki als deine operationelle Memory zu nutzen, ist wie eine Enzyklopädie als To-do-Liste zu benutzen — technisch möglich, fundamental fehlangepasst.

Wofür ein LLM-Wiki gut ist: tiefe Recherche-Projekte. Eine echte Wissensbasis aus Quellen aufzubauen, die du im Lauf der Zeit aufnimmst. Content-Organisation, bei der du ein Thema über Dutzende Inputs synthetisierst und am Ende ein navigierbares Artefakt willst. Ich habe überlegt, eines für das gesamte mejba.me-Archiv zu bauen — 230+ Artikel synthetisiert in ein Karpathy-Wiki — rein als Recherche-Artefakt für mein eigenes zukünftiges Schreiben. Ich habe noch nicht abgedrückt, weil die Vorab-Synthese-Kosten real sind und ich noch nicht sicher bin, ob sich der Payoff lohnt.

Für wen Stufe 5 ist: Forscher. Wissensarbeiter, die auf großen Quellkorpora aufbauen. Autoren, die tiefe Themensynthese betreiben. Pädagogen, die Kursmaterial bauen. Leute, die von einem Obsidian-Graphen ihres eigenen Denkens profitieren würden.

Wo es bricht: Als operationelle Projekt-Memory. Benutze kein Wiki dafür. Benutze Stufe 2 oder 3.

Stufe 6: Tool-übergreifende Unified Memory (Open Brain / Mem.ai)

Die finale Stufe, und die, die die Laptop-Grenze sprengt.

Die Prämisse: Deine Memory sollte nicht an ein Tool gebunden sein. Wenn du Claude am Montag etwas fragst, dann am Dienstag ChatGPT eine verwandte Frage stellst, dann am Mittwoch Code in Cursor schreibst — alle drei sollten aus demselben Memory-Store ziehen. Ein Gehirn. Viele Gesichter.

Zwei Hauptvarianten in 2026:

Hosted (Mem.ai, Mem0, Zep, MemPalace): Production-ready Cross-Tool-Memory als Service. Laut Mem0's pricing deckt der Free Tier 1.000 Memories pro Monat ab, bezahlte Pläne starten bei $19/Monat für 10K Memories, und Graph Memory ist hinter einem $249/Monat Pro-Plan zugangsbeschränkt. Ihre Integrations-Abdeckung läuft über 21 Frameworks und Plattformen in Python und TypeScript. Das ist jetzt reife Infrastruktur — kein Nebenprojekt mehr.

Self-hosted (Open Brain, custom Postgres + pgvector): Dieselbe Architektur, du besitzt sie. Postgres (oft via Supabase, das pgvector out of the box bietet) speichert Chunks plus Embeddings. Günstiger im Großen, weil du Infrastrukturkosten zahlst, nicht Pricing pro Memory. Mehr Kontrolle. Mehr Setup. Mehr Dinge, die du pflegen musst.

Beide Varianten fügen geteilte Echtzeit-Memory über Claude Desktop, Claude Code, ChatGPT, Cursor und jedes Tool mit MCP-Server oder API-Hook hinzu. Das ist die Magie. Frag Claude über eine Projektentscheidung; später, in Cursor, weiß die Code-Generierung es bereits.

Die Haken sind nicht theoretisch:

1. Latenz. Ein Netzwerk-Call an einen Remote-Memory-Store fügt 100-500 ms pro Retrieval hinzu. Bei einem schnellen Prompt ist das okay. In einer engen Schleife mit häufigen Retrievals ist es spürbar.
2. Externe Abhängigkeit. Hosted Memory bedeutet, einem Anbieter deinen Kontext anzuvertrauen. Self-hosted bedeutet, eine Datenbank zu hüten.
3. Sync-Konflikte. Zwei Tools, die zur gleichen Zeit in dieselbe Memory schreiben, schaffen Merge-Probleme, die noch keine Architektur vollständig gelöst hat.
4. Privacy-Angriffsfläche. Was immer in deiner Unified Memory lebt, ist jetzt von jedem Tool aus erreichbar, das du verbunden hast. Das ist das Feature. Es ist auch das Risiko.

Für wen Stufe 6 ist: Power-User, die echt Multi-Tool-Workflows fahren. Engineers, die mehrmals täglich zwischen Claude, ChatGPT und Cursor wechseln. Teams, in denen KI-unterstützte Arbeit ständig Tool-Grenzen überschreitet. Jeder, der eine echte „Second Brain"-Pipeline betreibt, die bereits über eine einzelne KI hinausgeht.

Wo es bricht: Für die meisten Solo-Operatoren übersteigt die Latenz- und Komplexitätssteuer den Tool-übergreifenden Komfort. Ich habe sowohl Mem0s Hosted-Tier als auch ein Supabase-+-pgvector-Setup getestet. Beide funktionierten. Beide fügten 200-300 ms zu jedem Prompt hinzu. Beide forderten Aufmerksamkeit, die ich lieber für das Schreiben aufwende.

Wie du deine Stufe wählst, ohne ein Wochenende zu verbrennen

Hier ist das Entscheidungs-Framework, das ich meinem früheren Ich vor jenem kaputten Dienstag in die Hand gedrückt hätte.

Starte bei Stufe 1. Liefere etwas aus. Sieh, was bricht. Die zwei Fragen, die zählen: Ist claude.md über 200 Zeilen, und pflegst du dieselben Kernregeln in mehreren Projekten?

Wechsle zu Stufe 2, wenn die Antwort auf eine der Fragen ja ist, oder wenn du länger als einen Monat auf Claude Code bist und deine Memory eindeutig über das hinausgewachsen ist, was eine Datei halten sollte. Ordnerstruktur plus Session-Start-Hook. Ein Nachmittag.

Wechsle zu Stufe 3, wenn Stufe 2 anfängt, das richtige Memory-Stück bei komplexen Prompts zu verfehlen, oder deine Memory ~100 Markdown-Chunks überschreitet. MemSearch-Plugin, hybrides Retrieval. Ein Tag Setup. Hier richten sich die meisten ernsthaften Operatoren ein.

Erwäge Stufe 4 nur, wenn deine Arbeit von wortwörtlicher Formulierung abhängt — Recht, Medizin, Forschung, Voice-of-Customer. Bau keinen Memory Palace, weil er cool klingt.

Erwäge Stufe 5 nur, wenn du tiefe Recherchesynthese über viele Quellen machst und ein navigierbares Artefakt willst. Es ist keine operationelle Memory. Es ist ein Wissensprodukt.

Erwäge Stufe 6 nur, wenn du bereits täglich zwischen drei oder mehr KI-Tools wechselst und die Memory-Lücke zwischen ihnen aktiv deine Arbeit beeinträchtigt. Sonst ist die Latenzsteuer es nicht wert.

Das Muster: Jede Stufe oberhalb derjenigen, die du brauchst, ist Reibung. Jede Stufe unterhalb derjenigen, die du brauchst, ist Leckage. Der Sweet Spot ist die niedrigste Stufe, die deinen tatsächlichen Workload bewältigt, nicht die höchste, mit der deine Peers prahlen.

Für mich — Multi-Brand-Content im großen Stil, @aria über vier Marken laufen lassen, manchmal mit Skill-Stacks koordinierend wie denen, die ich in my Claude Code skills stack post und den top Claude Code skills for business efficiency durchgegangen bin — ist Stufe 3, wo die Mathematik aufgeht. Wortwörtlicher Recall ändert meinen Output nicht. Tool-übergreifende Unified Memory auch nicht, weil @aria ein Claude-Code-Agent ist, der in einem Tool lebt. Also bleibe ich bei Stufe 3, spare die Engineering-Steuer und liefere mehr Artikel aus.

Wenn deine Mathematik anders ist, klettere. Wenn nicht, lass es.

Was ich jedem sagen würde, der heute anfängt

Die Sache, die ich vor dem kaputten Dienstag und dem Wiederaufbau danach unterschätzt habe, ist, dass Memory Hebel ist, aber nur auf der Stufe, die zu deiner Arbeit passt. Stufe 1 ist genug Hebel für die meisten Leute. Stufe 3 ist genug Hebel für fast alle anderen. Die übrigen Stufen existieren für spezifische Arbeitsformen, und sie als aspirational Targets zu behandeln, ist, wie man Nachmittage verschwendet.

Was mir geholfen hat, korrekt darüber nachzudenken, war zu beobachten, wie das Ökosystem tatsächlich evolviert ist. Das memsearch repo wurde von OpenClaw inspiriert, das auf Community-Mustern aufbaute, die auf dem ursprünglichen Anthropic-claude.md-Primitiv aufbauten. Jede Stufe wickelt die Stufe darunter ein. Keine ersetzt die Schicht darunter — sie fügt nur hinzu. Das bedeutet, du kannst immer später klettern. Du verlierst nichts, indem du klein anfängst. Du verlierst nur Zeit, wenn du groß anfängst und es nicht passt.

Wenn ich heute mit Claude Code anfangen würde, mit dem Wissen, das ich jetzt habe, würde ich exakt das machen:

1. Öffne ein Projekt. Schreibe claude.md. Halte es unter 200 Zeilen. Nutze es eine Woche.
2. Bemerke, was fehlt. Füge es hinzu. Begrenze die Dateilänge in dem Moment, in dem sie 200 droht.
3. Nach einem Monat: Aufteilen in einen Memory-Ordner mit General-/Domain-/Tool-Buckets. Füge einen Session-Start-Hook hinzu.
4. Nach drei Monaten, wenn deine Memory eindeutig über Keyword-Retrieval hinausgewachsen ist, installiere MemSearch.
5. Stop. Reassess nur, wenn ein spezifischer Workflow es verlangt.

Das ist der Pfad. Er ist langweilig. Er funktioniert. So betreibe ich eine Multi-Brand-Content-Operation auf einer Memory-Schicht, die in ein einzelnes Repo passt und aus Markdown neu aufbaut.

Der Dienstag, an dem ich versuchte, diese Schritte zu überspringen, kostete mich einen Arbeits-Nachmittag. Den nächsten Dienstag, mit Stufe 3 tatsächlich eingestellt, lieferte @aria vier Artikel beim ersten Versuch aus. Derselbe Agent. Dasselbe Modell. Andere Memory-Architektur, dimensioniert auf den tatsächlichen Job.

Wähle die Stufe, die deine Arbeit verlangt. Nicht die Stufe, die der Thread dir gesagt hat, du sollst fahren.

Häufig gestellte Fragen

Was ist der Unterschied zwischen claude.md und memory.md in Claude Code?

claude.md ist eine projektweite Anweisungsdatei, die du manuell schreibst — sie enthält Regeln, Konventionen und dauerhafte Guidance, die beim Session-Start geladen werden. memory.md ist Auto-Memory, in der Claude selbst Notizen aus Korrekturen und Präferenzen über Sessions hinweg speichert. Du verfasst die eine; Claude pflegt die andere. Beide laden zusammen in den Kontext.

Wie verhindere ich Context Rot in claude.md?

Halte claude.md unter rund 200 Zeilen, dann teile sie in einen Memory-Ordner mit General-, Domain- und Tool-Buckets auf. Nutze einen Session-Start-Hook, um nur das relevante Stück pro Session in den Kontext zu injizieren. Lange monolithische Memory-Dateien führen dazu, dass das Modell überfliegt statt liest, was die Hauptursache für Context Rot ist.

Ist MemSearch besser als Basic-Claude-Code-Memory?

MemSearch schlägt Basic Memory, sobald dein akkumuliertes Wissen rund 100 Markdown-Chunks überschreitet, weil hybrides Semantik-+-BM25-Retrieval relevanten Kontext findet, den keyword-only Loading verfehlt. Für kleinere Setups unterhalb dieser Schwelle fügt es Komplexität ohne signifikante Verbesserung hinzu. Die meisten Operatoren brauchen es in ihren ersten drei Monaten nicht.

Was ist ein Memory Palace in KI-Workflows?

Ein Memory Palace ist ein RAG-System, das exakten wortwörtlichen Konversationstext in einer symbolisch indexierten Struktur speichert — typischerweise Flügel, Räume, Schränke und Schubladen — unter Nutzung von SQL plus einer Vektordatenbank für Retrieval. Es ist optimiert für Recall mit exakter Formulierung, nicht paraphrasiertem Sinn. Nützlich für Recht-, Medizin- oder Forschungs-Workflows, bei denen exakte Formulierung zählt.

Soll ich Mem.ai nutzen oder meine eigene Cross-Tool-Memory bauen?

Nutze Mem.ai oder Mem0, wenn du production-ready Hosted Memory willst und keine Infrastruktur pflegen möchtest — das Pricing startet bei $19/Monat für 10K Memories bei Mem0. Bau dein eigenes mit Supabase plus pgvector, wenn du volle Datenhoheit brauchst, vorhersehbare Kosten im Großen und mit dem Pflegen einer Datenbank wohlfühlst. Die meisten Solo-Operatoren brauchen keinen der beiden Tiers.

Lass uns zusammenarbeiten

Du willst KI-Systeme bauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Security-Services): xcybersecurity.io