Drei Gedächtnissysteme in einem Login – warum Sie keine Kompromisse eingehen sollten

Anthropic integriert derzeit mindestens drei verschiedene Gedächtnismodelle in die Claude-Produktfamilie. Doch diese Systeme funktionieren nicht nur unterschiedlich, sondern sind auch nicht miteinander kompatibel. Nutzer stehen vor der Herausforderung, zwischen ihnen wählen zu müssen – obwohl eigentlich niemand diese Entscheidung treffen sollte.

Claude.ai speichert für Pro-, Max-, Team- und Enterprise-Abonnenten Gesprächsverläufe und fasst sie in einem 24-Stunden-Synthese zusammen. Diese Inhalte werden dann in neue Chats eingebunden. Claude Code hingegen nutzt CLAUDE.md-Dateien und ein separates, projektbezogenes Speicherverzeichnis, das lokal auf dem Gerät liegt und bei jedem Session-Start geladen wird. Der API-Zugriff bietet mit dem memory_20250818-Tool ein separates Verzeichnis namens /memories, das Anwendungen nutzen können, um Daten zwischen verschiedenen Anfragen zu persistieren. Drei Oberflächen, drei Regeln, drei Speicherstrategien – und keine einfache Möglichkeit, Kontext zwischen ihnen zu übertragen.

Warum die Speicherlösungen so unterschiedlich sind

Das Gedächtnissystem in Claude.ai fasst Gespräche projektbezogen zusammen und ist über die Einstellungen steuerbar. Bei Claude Code hingegen werden Markdown-Dateien direkt im Repository abgelegt, während ein lokales Verzeichnis unter ~/.claude/projects//memory/ spezifische Projektkontexte speichert. Die API-Schnittstelle definiert sechs Grundoperationen wie view, create, str_replace, insert, delete und rename, überlässt die tatsächliche Speicherung jedoch der Anwendung. Jede dieser Lösungen ist für einen bestimmten Anwendungsfall optimiert – aber sie folgen unterschiedlichen Formaten, bieten keine Exportmöglichkeiten zwischen den Systemen und erfordern manuelles Kontextmanagement, wenn Nutzer zwischen den Oberflächen wechseln.

Der Lock-in-Effekt: Warum die Wahl der falsche Ansatz ist

Viele Nutzer neigen dazu, sich für eine der drei Speicherlösungen zu entscheiden, etwa die Chat-Synthese für spontane Fragen, das automatische Gedächtnis für Programmieraufgaben oder das API-Tool für Produktionsagenten. Doch diese Vorgehensweise ist problematisch, weil sie davon ausgeht, dass die angebotenen Speicherlösungen stabil bleiben. Das ist jedoch nicht der Fall: Die Chat-Speicherfunktion wurde erst für Team- und Enterprise-Kunden eingeführt und später auf Pro- und Max-Abonnements ausgeweitet. Die automatische Speicherung in Claude Code erfordert mindestens Version 2.1.59 und speichert Daten in einem Git-repo-abhängigen Pfad. Das API-Tool befindet sich zudem noch in der Beta-Phase und hat bereits zweimal Änderungen in der Namenskonvention erfahren.

Hinzu kommt ein grundlegendes Problem: Agenten-Gedächtnis schafft Wechselkosten, die selbst durch Datenportabilitätsregeln nicht behoben werden können. Selbst wenn ein Anbieter morgen die Exportfunktion für Speicherdaten anbieten würde, bleibt die betriebliche Wissensbasis – Teamjargon, Ausnahmen, interne Abkürzungen – nicht vollständig übertragbar. Eine Studie von Parallels aus dem Jahr 2026 zeigt, dass 94 % von 540 IT-Verantwortlichen Bedenken bezüglich Vendor-Lock-in haben. Agenten-Gedächtnis ist genau die Schicht, in der sich solche Bedenken verstärken.

Die eigene Speicherstrategie: So umgehen Sie die Fallstricke

Statt auf die proprietären Lösungen der Anbieter zu vertrauen, empfiehlt sich ein unabhängiger Ansatz. Ein mögliches Setup nutzt ein NAS-basiertes Verzeichnis namens nexus/, das unter Versionskontrolle steht und ausschließlich aus Markdown-Dateien besteht. Im Projektstamm liegt eine CLAUDE.md, die automatisch in jede Claude-Code-Session geladen wird. Für langfristige Inhalte existiert eine MEMORY.md, während SESSION-STATE.md den aktuellen Kontext speichert. Domänenspezifische Dateien in agents/-context.md strukturieren Wissen nach Bereichen wie Finanzen, Gesundheit oder Content-Erstellung. Tägliche Protokolle werden unter memory/YYYY-MM-DD.md abgelegt. Querverweise zwischen Einträgen nutzen [[Doppelklammern]], sodass sie sowohl per grep durchsuchbar als auch mit Tools wie Obsidian visualisierbar sind.

Die Suche über den gesamten Wissenskorpus läuft über eine lokale Ollama-Einbettungspipeline mit dem Modell nomic-embed-text bei 768 Dimensionen – ohne dass dafür API-Aufrufe an einen Anbieter nötig wären. Diese Struktur bietet drei entscheidende Vorteile:

• Überlebensfähigkeit bei Oberflächenwechseln: Die gleichen Dateien lassen sich in Claude Code laden, in Claude.ai einfügen oder über die API-Schnittstelle nutzen. Das Format ist universell, weil es auf einfachen Dateien basiert.
• Unabhängigkeit vom Anbieter: Selbst bei einem Wechsel des Modellanbieters bleiben die Markdown-Dateien lesbar, die Einbettungen nutzbar und die Wikilinks funktionsfähig. Es gibt kein proprietäres Speicherschema, das migriert werden müsste.
• Volle Kontrolle und Transparenz: Nutzer können ihre Kontexte per grep durchsuchen, Änderungen mit diff analysieren oder gelöschte Einträge wiederherstellen. Solche Funktionen fehlen in den anbieterseitigen Speicherlösungen – oder sind nur eingeschränkt verfügbar.

Fazit: Entwickeln Sie Ihre eigene Gedächtnisstrategie

Der Speicher eines KI-Agenten ist kein Feature des Modells, sondern des Wrappers – und dieser Wrapper gehört nicht Ihnen, sondern dem Anbieter. Drei verschiedene Speichersysteme unter einem Login zu nutzen, ist kein Zeichen von Flexibilität, sondern von Abhängigkeit. Die einzige nachhaltige Lösung liegt darin, die Kontrolle über den eigenen Kontext zurückzugewinnen. Ein lokal organisiertes, plattformunabhängiges Gedächtnissystem schützt vor Lock-in-Effekten, ermöglicht Auditierbarkeit und gibt Nutzern die Freiheit, zwischen Oberflächen zu wechseln – ohne dass ihre betriebliche Wissensbasis verloren geht. Die Technologie wird sich weiterentwickeln, doch wer heute die richtigen Grundlagen legt, bleibt morgen handlungsfähig.