OpenMemory

Die meisten LLM-Anwendungen vergessen alles in dem Moment, in dem eine Session endet, und der übliche Behelf, vergangene Gespräche in eine Vektordatenbank zu kippen und die nächstgelegenen Chunks abzurufen, hat klare Lücken. Reines RAG weiß nicht, ob ein Fakt noch gilt, wie aktuell er war oder um welche Art von Erinnerung es überhaupt geht. OpenMemory von CaviraOSS positioniert sich als lokaler, selbst gehosteter Langzeitspeicher für Agenten und Copilots und versteht sich als Schritt über Embeddings in einer Tabelle hinaus. Das Projekt beschreibt sich als cognitive memory engine: eine persistente Schicht, in die eine LLM-App schreiben und aus der sie über Sessions hinweg abrufen kann, betrieben auf der eigenen Maschine, standardmäßig mit SQLite oder mit externem Postgres. Der Kern des Versprechens ist Eigentum und Nachvollziehbarkeit, weil Nutzerdaten und Recall-Logik in der eigenen Infrastruktur bleiben statt in einer gehosteten Memory-API.

OpenMemory modelliert Erinnerung in Sektoren statt in einem flachen Speicher. Die README nennt episodisches Gedächtnis für Ereignisse und Gespräche, semantisches für Fakten, prozedurales für Fähigkeiten und Abläufe sowie emotionale und reflektierende Sektoren. Darüber liegt ein temporaler Knowledge Graph mit valid_from- und valid_to-Zeitstempeln, sodass überholte Fakten geschlossen und Point-in-Time-Abfragen möglich werden. Der Recall kombiniert Vektorsuche mit Graph-Traversierung über Waypoints und einen zusammengesetzten Score aus Salienz, Aktualität und Coactivation, mit allmählichem Decay statt hartem Verfall. Das Besondere ist der explainable trace: Er zeigt, welche Knoten abgerufen wurden und warum, was unter Memory-Schichten selten ist. Mitgeliefert werden Python- und JS-SDKs, ein opm-CLI, ein MCP-Server und Connectors für GitHub, Notion und Google Drive.

Die naheliegende Zielgruppe sind Entwickler, die zustandsbehaftete KI bauen: Agenten, Coding-Assistenten, Copilots, Journaling-Tools und Anwendungen für Wissensarbeit, bei denen ein Modell Kontext über Sessions hinweg mitnehmen soll, statt ihn jedes Mal neu aufzubauen. Die Framework-Integrationen zeigen genau dorthin, mit dokumentierten Anbindungen an LangChain, CrewAI, AutoGen und Streamlit sowie MCP-Unterstützung, damit Claude, Cursor und Windsurf Erinnerungen lesen und schreiben können. Konkrete Anwendungen sind ein Coding-Agent, der sich Projektkonventionen und frühere Entscheidungen merkt, ein persönlicher Assistent, der Vorlieben und wiederkehrende Fakten behält, oder ein Recherche-Tool, das Erkenntnisse über Wochen sammelt. Die Connectors und der Migrationspfad von Mem0 und Zep machen es auch für Teams interessant, die bereits eine gehostete Memory-Schicht betreiben und diese Daten auf eine selbst gehostete, lokale Infrastruktur unter eigener Kontrolle holen wollen.

Die ehrlichen Vorbehalte sind real. Dies ist die kleinste Community unter den vergleichbaren Projekten hier, und seit Dezember 2025 gab es kein Release mehr, womit es auf dem Papier das am wenigsten aktiv gepflegte der Gruppe ist. Die README selbst trägt einen Hinweis, dass das Projekt mitten in einem Rewrite steckt, mit zu erwartenden Breaking Changes und Bugs auf dem rewrite-Branch, ein deutliches Signal, dass es noch nicht produktionsreif ist. Die Performance- und Kostenangaben, der berichtete schnellere Recall und die niedrigeren Kosten gegenüber gehosteten APIs, sind die eigenen Benchmarks des Projekts und keine unabhängigen Ergebnisse, also bis zur Prüfung im eigenen Workload als Marketing zu behandeln. Hinzu kommt ein unsauberes Detail: Die Homepage nennt MIT, während das Repository tatsächlich Apache-2.0 ist. Geringfügig, aber bei einer Memory-Schicht, die Nutzerdaten verarbeitet, zählen Sorgfalt und stetige Pflege.

Im Vergleich zu kommerziellen Memory-APIs wie Mem0, Zep oder Supermemory tauscht OpenMemory einen gemanagten, supporteten Dienst gegen lokales Eigentum, ein reicheres Sektorenmodell und nachvollziehbare Recall-Traces, und es liefert ein Migrationswerkzeug, sodass der Wechsel kein Neuaufbau auf der grünen Wiese ist. Dieser Tradeoff lohnt sich, wenn Datenhoheit, Kostenkontrolle und Transparenz schwerer wiegen als der Komfort eines gehosteten SLA. Interessant ist es heute, wenn man eine selbst gehostete, erklärbare Memory-Schicht mit fertigen Connectors will und damit leben kann, ein bewegliches Ziel zu verfolgen. Zu früh ist es, wenn aktive Wartung eine harte Anforderung ist: sechs Monate ohne Release plus laufender Rewrite bedeuten, dass man mit Quelltext-Lesen, Versions-Pinning und womöglich eigenen Fixes rechnen sollte. Zum Prototyping geeignet, aber die Benchmarks und die Stabilität sollten geprüft sein, bevor Produktion darauf gesetzt wird.