LongMemory: zeitliche Wahrheit und Governance statt reiner Vektorsuche
Local persistent memory store for LLM applications including claude desktop, github copilot, codex, antigravity, etc.
Auf einen Blick
- Was ist das?
- LongMemory ist eine lokale, SQLite-gestützte Speicherschicht für LLM-Anwendungen, die Gültigkeitszeitpunkte, Herkunft und Zugriffsscopes mitführt. Der Ansatz löst ein echtes Problem, verlangt aber, dass man die Daten vorher modelliert.
- Für wen ist es gedacht?
- Wer einem Agenten über Wochen hinweg widerspruchsfreie Antworten entlocken will und dafür ein eigenes Schema, Decay-Regeln und ACL-Scopes pflegen kann, findet in LongMemory eine Engine, die diese Konzepte im Datenmodell führt. Für Prototypen mit einer Handvoll Dokumenten ist der Aufwand nicht zu rechtfertigen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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
Welches Problem LongMemory adressiert
Der Ausgangspunkt ist eine Beobachtung, die das Projekt im README selbst formuliert: Viele Systeme, die sich Gedächtnis nennen, sind Retrieval-Pipelines, die Text zerlegen, einbetten und die nächsten Vektoren zurückgeben. Diese Pipeline beantwortet keine der Fragen, die im Betrieb tatsächlich weh tun. Sie weiß nicht, was zu einem bestimmten Zeitpunkt galt. Sie erkennt nicht, ob eine neue Aussage eine alte ersetzt hat. Sie kennt keine Quelle, die maßgeblich ist, und keine Sichtbarkeitsregel. Sie kann nicht begründen, warum ein Treffer im Kontext landen soll.
LongMemory ist für Teams gedacht, die genau diese Fragen beantworten müssen: Anwendungen mit mehreren Nutzern oder Mandanten, Agenten, die über Monate laufen, und Assistenten, die auf Projektwissen zugreifen sollen, ohne dass Entscheidungen von gestern die Antwort von heute verfälschen. Die Zielgruppe sind damit eher Backend- und Plattformteams als Einzelentwickler, die schnell eine semantische Suche brauchen.
Der Datenkern: Knoten, Kanten, Welten, Zeit
Das README beschreibt den Unterbau als Hydrograph-Speicher mit unveränderlichen Knoten, ausführbaren Kanten, Welten, Entitäten, Facetten und Traces. Unveränderlich heißt hier: Inhalt, Vektoren, Hashes und Herkunft werden durch Recall oder Decay nicht überschrieben. Neue Erkenntnisse entstehen als zusätzliche Datensätze, nicht als Mutation des Bestands.
Der zweite tragende Mechanismus ist die Trennung von Aufzeichnungszeit und Gültigkeitszeit. Ein Fakt kann also zu einem Zeitpunkt erfasst worden sein und für einen anderen Zeitraum gegolten haben. Darauf setzt der Recall-Modus historical auf, der laut README überholte Wahrheiten erhält, statt sie zu verwerfen. Wer schon einmal versucht hat, mit einem reinen Vektorspeicher die Frage "Was galt im Januar?" zu beantworten, erkennt den Unterschied sofort: Dort müsste man Zeitfilter und Versionslogik selbst bauen und über die gesamte Schreibstrecke konsistent halten.
Dazu kommen typisierte Beziehungen zwischen Knoten. Diese Kanten sind nicht bloß Metadaten, sondern nehmen an der Suche teil, was der assoziative Modus nutzt. Ein dritter Baustein ist die Governance-Schicht: Projekt, Mandant, Nutzer, Team, Rolle, Agent, Task und Framework bilden Scopes, die bei der Auslieferung durchgesetzt werden.
Recall-Modi und ihre Voraussetzungen
LongMemory bietet mehrere Abfragemodi, die sich nicht nur in der Trefferreihenfolge unterscheiden, sondern in den Prüfungen, die sie anwenden. strict kombiniert laut README zeitliche, Widerspruchs-, Vertrags-, Konfidenz- und Erdungsgates. historical akzeptiert einen valid_time-Parameter, im Beispiel Date.UTC(2026, 0, 15). associative folgt semantischen, lexikalischen, Entitäts-, Aktivierungs- und Graph-Signalen. world_grounded verlangt aktuelle externe Belege.
Bemerkenswert ist, dass strict und world_grounded scheitern können, wenn die Voraussetzungen fehlen. Ein Widerspruchsgate braucht Widerspruchsinformationen, ein Erdungsgate eine Auflösung gegen externe Quellen. Wer seine Daten ohne diese Signale einspeist, bekommt nicht etwa schlechtere Treffer, sondern womöglich gar keine. Das ist eine Designentscheidung mit Konsequenz: LongMemory verschiebt Aufwand von der Abfrage in den Schreibpfad und in die Modellierung. Wer das nicht will, ist mit einem Vektorspeicher plus Reranker besser bedient.
Der Token-Budget-Aspekt ist ebenfalls erwähnenswert. Das README spricht von token-bounded context und erklärbarer Evidenzauswahl. Für Agenten mit harten Kontextfenstern ist das relevanter als ein weiteres Prozent Recall.
Inbetriebnahme: Bibliothek, CLI, Dienst
Der schnellste Weg führt über die Bibliothek. Nach npm install longmemory erzeugt createMemory() eine Instanz, ingest() schreibt einen Text mit user_id, recall() liest ihn zurück. Für den flüchtigen Betrieb ist kein externer Dienst nötig. Wer Persistenz braucht, übergibt Optionen: store: 'sqlite', db_path: './longmemory.db', tenant_id und user_id. Das README hält fest, dass beim erneuten Öffnen derselben Datenbank Knoten, Welten, Entitäten, Kanten, zeitliche Historie, Erdung und Lebenszykluszustand wiederhergestellt werden.
Für die Kommandozeile gibt es npm install --global longmemory, danach longmemory init und longmemory recall "current project priorities" --mode associative. Als Dienst startet man aus dem Quellbaum mit corepack enable, pnpm install --frozen-lockfile, pnpm build und pnpm start; die API lauscht standardmäßig auf http://127.0.0.1:7331. Der Container ghcr.io/caviraoss/longmemory:latest wird mit Port 7331, einem Volume auf /data und der Variablen LONGMEMORY_API_KEY gestartet. Mit Docker Compose kommen Dashboard (Port 3000) und Health-Endpunkt unter /health dazu.
Für Agenten-Hosts ist der MCP-Pfad der interessanteste: longmemory mcp --db .longmemory/project.db --project current startet einen stdio-Server, LONGMEMORY_API_KEY=change-me longmemory serve --mcp-http einen authentifizierten HTTP-Transport. Das README nennt 13 Tools sowie Ressourcen und Prompts, und es hält ausdrücklich fest, dass Tool-Argumente die serverseitig gebundene Laufzeitidentität nicht überschreiben können.
Wo der Ansatz an Grenzen stößt
Die erste Einschränkung ist der Schreibpfad. Zeitliche Wahrheit entsteht nicht dadurch, dass man Texte einfüttert. Irgendwo muss festgelegt werden, welcher Fakt welchen Vorgänger ablöst und für welchen Zeitraum er gilt. Das README beschreibt Supersession als Teil des Modells, nennt aber in den gezeigten Beispielen keine API, mit der man sie explizit setzt. Wer diese Semantik nicht selbst produziert, betreibt eine teure Vektordatenbank mit zusätzlichen Feldern.
Die zweite Einschränkung ist die Reife. Die letzten Releases tragen Versionen wie v1.3.0 (Beta v1.3.0), v1.2.3 und v1.2.2 aus dem Dezember 2025. Eine Beta-Kennzeichnung auf der Hauptversion ist ein Signal, dass sich Schnittstellen und Datenformate noch bewegen können. Für ein System, das die dauerhafte Wahrheit einer Anwendung speichert, ist das ein reales Migrationsrisiko.
Drittens die Betriebsform. SQLite als Standard bedeutet lokale Datei, also einen einzigen Schreiber und keine verteilte Replikation. Für einen Desktop-Assistenten ist das ideal, für ein Team mit vielen gleichzeitigen Schreibern auf einem gemeinsamen Speicher ist es die falsche Wahl. Das Material nennt keine Alternative für diesen Fall, und ich würde sie auch nicht unterstellen.
Schließlich die Benchmark-Frage. Das README verweist auf auswertbare Benchmarks für LongMemEval, LoCoMo, BEAM, Retrieval-Qualität, Zeitverhalten und Latenz. Zahlen nennt es nicht. Wer diese Werte als Entscheidungsgrundlage braucht, muss sie selbst erheben.
Abgrenzung zu Vektor- und RAG-Stacks
Die naheliegende Alternative ist ein Vektorspeicher mit einem RAG-Framework davor, also etwa pgvector oder eine dedizierte Vektordatenbank plus Chunking- und Reranking-Logik. Der Unterschied liegt nicht in der Ähnlichkeitssuche, die beide beherrschen, sondern im Verhältnis von Schreiben zu Lesen. Ein Vektorstack behandelt Schreiben als Append und überlässt die Interpretation dem Prompt. LongMemory verlangt beim Schreiben Entscheidungen über Zeit, Herkunft und Scope und liefert sie beim Lesen als Gates zurück.
Konkret: Eine Frage wie "Was war die Deployment-Region im Januar?" ist mit pgvector nur über zusätzliche Spalten und manuelle Filter im Anwendungscode zu beantworten, und die Konsistenz dieser Filter liegt bei jedem Aufrufer. In LongMemory ist der Zeitbezug Teil des Recall-Modus. Umgekehrt ist ein Vektorstack deutlich billiger, wenn es nur darum geht, einem Chatbot die letzten zwanzig Dokumente zugänglich zu machen. Dort wäre LongMemory ein Werkzeug für ein Problem, das nicht existiert.
Wartung, Upgrades und Lizenz
Der Wartungsaufwand verteilt sich auf drei Flächen: das Schema, die Lebenszyklusregeln und die Integrationen. Das README nennt deterministischen Decay, explizite Verstärkung, Konsolidierung, Kompression und Rekonsolidierung. Solche Regeln sind Parameter, die jemand abstimmen muss. Ohne Abstimmung altern sie still vor sich hin, und der Speicher füllt sich mit Einträgen, die niemand mehr erklären kann.
Upgrades sind wegen der Beta-Kennzeichnung der Hauptversion mit Vorsicht zu behandeln. Zwischen v1.2.2, v1.2.3 und v1.3.0 liegen jeweils rund ein bis zwei Wochen, was auf eine aktive, aber schnelle Entwicklungslinie hindeutet. Wer produktiv geht, sollte die Datenbank vor jedem Versionssprung sichern und die Release Notes lesen, statt sich auf Abwärtskompatibilität zu verlassen. Konkrete Migrationshinweise gibt das vorliegende Material nicht her.
Lizenzseitig steht das Projekt unter Apache-2.0, was kommerzielle Nutzung, Änderung und Weitergabe erlaubt und eine ausdrückliche Patentgewährung enthält. Wer den Code verändert und weitergibt, muss die Lizenz- und Änderungshinweise mitführen. Das ist eine technische Einordnung, keine Rechtsberatung; für den Vertrieb eines modifizierten Dienstes sollte man die eigenen Pflichten mit der Rechtsabteilung klären.
Redaktionelles Fazit
Wer einem Agenten über Wochen hinweg widerspruchsfreie Antworten entlocken will und dafür ein eigenes Schema, Decay-Regeln und ACL-Scopes pflegen kann, findet in LongMemory eine Engine, die diese Konzepte im Datenmodell führt. Für Prototypen mit einer Handvoll Dokumenten ist der Aufwand nicht zu rechtfertigen. Vor dem Einsatz würde ich prüfen, ob der eigene Schreibpfad Supersession korrekt setzt, denn ohne dieses Signal kann der Modus strict seine Zusagen nicht einlösen.
Community-Notizen