Basic Memory: KI-Wissen als lokale Markdown-Dateien
KI-Gespräche, die tatsächlich erinnern. Erklären Sie Ihrer KI nie wieder Ihr Projekt. Treten Sie unserem Discord bei:.
Auf einen Blick
- Was ist das?
- Basic Memory hält Kontext für KI-Assistenten als Markdown auf der eigenen Platte, verdrahtet über MCP mit Claude, Codex, Cursor und anderen Clients. Wir prüfen Installation, Datenmodell, Cloud-Weg und Lizenzfolgen.
- Für wen ist es gedacht?
- Basic Memory passt für Nutzer, die ihren KI-Assistenten über Sitzungen hinweg auf eine selbst gehaltene Wissensbasis zugreifen lassen wollen und Markdown sowieso schon verwenden. Wer einen Cloud-Dienst ohne AGPL-Folgen für eigenes Hosting sucht oder mobile Zugriff ohne Cloud braucht, wird nicht fündig.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Basic Memory: Wissen als Markdown-Dateien statt Blackbox-Datenbank
Basic Memory aus dem Haus basicmachines-co ist ein Python-Projekt unter der AGPL-3.0-Lizenz, das das Gedächtnisproblem von KI-Assistenten auf eine ungewöhnliche Art löst. Statt einer proprietären Datenbank liegt das Wissen als einfache Markdown-Dateien auf der Festplatte, die sowohl der Mensch als auch die KI lesen, schreiben und durchsuchen. Das README nennt das Konzept local-first: Plain Text auf der eigenen Disk, dauerhaft.
Das gelöste Problem kennt jeder, der täglich mit Assistenten arbeitet: Nach jeder neuen Sitzung muss man das Projekt erneut erklären. Basic Memory hält den Kontext über Sitzungen hinweg, verbunden über das Model Context Protocol, kurz MCP, mit Clients wie Claude, Codex, Cursor oder ChatGPT. Die Codebasis zeigt mit 3.790 Sternen und 266 Forks eine solide Gemeinde, bei 81 offenen Issues und einem letzten Push Ende August 2026.
Drei Eigenschaften heben das Design hervor. Es ist bidirektional, weil KI und Mensch in dieselben Dateien schreiben und ein Sync sie in Schritt hält. Es baut einen echten Wissensgraphen, in dem sich Observations und Wikilinks zu Kontext verbinden. Und die Cloud ist ausdrücklich optional, niemals Voraussetzung. Wer will, arbeitet komplett luftgekapselt ohne Netzzugang.
uv tool install basic-memory --prerelease=allow und die FastMCP-4-Falle
Die lokale Installation läuft über uv: uv tool install basic-memory --prerelease=allow. Das Flag ist kein kosmetisches Detail, sondern eine dokumentierte Falle. Basic Memory 0.23 hängt an einem FastMCP-4-Pre-Release ab, und uv akzeptiert Pre-Releases transitiver Abhängigkeiten nur auf explizite Anweisung. Ohne das Flag installiert uv stillschweigend eine ältere Version, das README warnt unmissverständlich davor.
Das gleiche Flag gehört auf jeden nachfolgenden Aufruf von uvx und uv tool upgrade. Wer die Installation einmal ohne Flag gefahren hat, sollte sie sauber wiederholen, denn die stillschweigend alte Abhängigkeit zeigt sich nicht als Fehler. Für Postgres-Bereitstellungen, die semantische Vektoren in Milvus ablegen, existiert ein erstes partielles Extra: uv tool install "basic-memory[milvus]" --prerelease=allow.
Die Release-Historie erklärt, warum diese Präzision nötig ist: v0.23.0, v0.23.1 und v0.23.2 erschienen alle zwischen dem 24. und 25. August 2026. Ein so schnelles Tempo verlangt eine gepinnte Werkzeugkette. Das README empfiehlt für Entwicklungsumgebungen die Basisinstallation per make setup, die Git-Hooks und die gepinnte Backend-Umgebung vorbereitet, während die Runtime-Umgebungen für mobil und Desktop ausdrücklich opt-in bleiben.
Observations und Wikilinks: der Wissensgraph im Klartext
Der Datenmodellkern besteht aus Observations und Relationen, wie der Basissatz der Dokumentation sie definiert. Eine Observation ist ein Fakt mit optionaler Kategorie, Tags oder Kontext, eine Relation ist ein Wikilink auf eine andere Entität. Aus dieser Kombination entsteht der Wissensgraph: Jede neue Notiz verknüpft sich über Wikilinks mit bestehendem Wissen, und der Kontext wächst mit jeder Verknüpfung, statt isolierte Textblöcke zu sammeln.
Weil alles in Markdown liegt, bleibt der Bestand mit gewöhnlichen Werkzeugen lesbar. Obsidian liest dieselben Dateien ohne Einrichtung direkt, wie das README anmerkt. Ein Sync hält die Dateien zwischen dem, was die KI schreibt, und dem, was der Mensch im Editor ändert, im Gleichstand.
Für die Suche bietet das Projekt mehr als Stichworte. Die semantische Suche findet Notizen nach Bedeutung und nutzt optional ein Cross-Encoder-Reranking für höherwertige Vector- und Hybrid-Treffer. Der Graph aus Observations, Wikilinks und semantischen Vektoren ist damit die eigentliche Währung des Projekts, und sie bleibt in Klartextdateien sichtbar statt in einer Datenbank zu verschwinden.
Verhaltenshinweise wie read-only und destruktiv bei den MCP-Tools
Basic Memory stellt jedem MCP-Client eine Werkzeugsammlung bereit und versieht jedes Werkzeug mit Verhaltenshinweisen: read-only, destructive, idempotent. Das README nennt das Konzept progressive tool discovery, weil Agenten damit bei Bedarf das richtige Werkzeug wählen, ohne Kontext zu verschwenden, indem sie ausprobieren, was ein Werkzeug tut.
Dieses Detail ist mehr als Deko. In der Praxis scheitern Agentenpläne oft daran, dass ein Werkzeug versehentlich destruktiv wirkt oder ein Lesezugriff Schreiblast erzeugt. Mit expliziten Hints entfällt ein Teil der Probierphase, und der Client kann Vorgänge vorab bewerten. Für Betreiber, die eigene Clients oder Automatisierungen gegen das MCP anbinden, ist der Hinweiskatalog zugleich ein Vertrag, an dem sich eigene Werkzeuge orientieren können.
Die Verbindung zur Infrastruktur bleibt klassisch MCP: Claude Desktop, Claude Code, Codex, Cursor und ChatGPT sprechen dasselbe Protokoll, der Webclient erreichbar über basicmemory.com nutzt HTTPS. Der gleiche Wissensbestand ist damit von verschiedenen Clients aus ansprechbar, ohne dass die Daten zwischen den Werkzeugen kopiert werden müssten.
Basic Memory Cloud mit Tigris S3 und rclone-Sync im Vergleich zur lokalen Installation
Neben der lokalen Installation existiert ein gehosteter Weg. Die Cloud-Variante bietet geräteübergreifenden Zugriff, Backups und Snapshots, für 15 Dollar im Monat, lebenslang eingefroren im Betazugang, regulär 19 Dollar. Eine 7-tägige Testphase erlaubt die Kündigung vor Ablauf, und der Code BMFOSS senkt den Preis für Open-Source-Nutzer drei Monate lang um 20 Prozent auf etwa 11,40 Dollar.
Technisch baut die Cloud laut README auf WorkOS AuthKit, Neon Postgres und Tigris S3. Der bidirektionale Sync zur lokalen Seite ist rclone-basiert, inklusive Konfliktbehandlung: Man editiert am Telefon und sieht die Änderung in Obsidian auf dem Laptop. Snapshots erlauben eine Wiederherstellung zu einem Zeitpunkt, und der Export nach Markdown bleibt jederzeit möglich.
Die Gegenüberstellung im README ist ehrlich: Lokal gibt es keinen mobilen Zugriff, keine eingebauten Snapshots und keine Luftnetz-Option für die Cloud, dafür den gesamten Bestand auf der eigenen Platte ohne laufende Kosten. Cross-Device-Sync muss lokal mit Git oder Syncthing selbst organisiert werden. Beide Wege nutzen dieselbe OSS-Engine und dieselben Markdown-Dateien, und laut README lässt sich zwischen ihnen wechseln, wenn sich die Anforderungen ändern. Ein eigenes Teams-Angebot ergänzt geteilte Arbeitsbereiche, in dem Notizen Echtzeit-Bearbeitung zwischen Menschen und Agenten erlauben.
Releases v0.23.2, die AGPL-3.0-Konsequenz und ein Ausweg über Obsidian
Für eigene Serverinstallationen ergibt sich aus der AGPL-3.0-Lizenz eine konkrete Pflicht: Wer das Netzwerkangebot betreibt, muss Nutzern den Quellcode modifizierter Versionen zugänglich machen. Für einen rein lokalen Einsatz ohne Netzwerkexposition ist das folgenlos, für gehostete Ableitungen ist es der zentrale Unterschied zu einer MIT-Lizenz.
Die Grenzen der lokalen Route sind im Vergleichstisch klar benannt: kein mobiler Zugang ohne Cloud, Snapshots und Backups muss man selbst rollen, Cross-Device-Sync verläuft manuell. Die Testimonials im README stammen von Einzelnutzern wie Alex von TrainerDay oder dem Entwickler hinter dem Handle groksrc, die von einer veränderten Arbeitsweise berichten, selbst berichtete Erfahrungen ohne unabhängige Messung.
Als Alternative zu Basic Memory bleibt der direkte Weg über eine eigene Markdown-Sammlung in Obsidian, die die KI über ein MCP-Dateisystem-Werkzeug bearbeitet. Der Unterschied liegt im semantischen Teil: Basic Memory indiziert Observations, Relationslinks und Vektoren und stellt dem Agenten Verhaltenshinweise bereit, während eine nackte Dateisammlung nur Text liefert. Wer nur gelegentliche Notizabfragen braucht, kommt mit dem einfachen Weg aus, wer einen wachsenden, durchsuchbaren Graphen will, gewinnt mit dem strukturierten Modell. Vor dem Einsatz sollte man ausprobieren, ob der eigene Client MCP sauber ansteuert und ob die Pre-Release-Abhängigkeit an FastMCP 4 in der eigenen Umgebung wie dokumentiert auflöst.
Redaktionelles Fazit
Basic Memory passt für Nutzer, die ihren KI-Assistenten über Sitzungen hinweg auf eine selbst gehaltene Wissensbasis zugreifen lassen wollen und Markdown sowieso schon verwenden. Wer einen Cloud-Dienst ohne AGPL-Folgen für eigenes Hosting sucht oder mobile Zugriff ohne Cloud braucht, wird nicht fündig. Vor dem Alltagseinsatz prüft man, ob der eigene Client MCP spricht, und startet mit uv tool install basic-memory --prerelease=allow samt einer ersten Projektdatei.
Community-Notizen