LightMem vs metronix-memory
ICLR 2026 memory framework for LLMs/agents: LLMLingua pre-compression, topic segmentation and offline memory updates — leading LoCoMo/LongMemEval results at lower token cost. — versus — Self-hosted agent memory stack in Docker: Postgres + Qdrant + Neo4j hybrid retrieval, a temporal knowledge graph, ontology layer and freshness checks behind one MCP-native API.
Both attack long-conversation memory quality; metronix ships a Docker stack (Postgres+Qdrant+Neo4j, temporal KG), lightmem is the research framework â compression, topic segmentation, offline updates.
| LightMem | metronix-memory | |
|---|---|---|
| Stars | 1.2k | 102 |
| Forks | 113 | 13 |
| Language | Python | Python |
| License | MIT | Apache-2.0 |
| Last activity | 14 days ago | 2 days ago |
| Topics | memory | memory, rag, knowledge-graphs |
| Curated connections | 5 | 8 |
LightMem — the curator's take
Research-grade memory with receipts: reproduction scripts for LoCoMo/LongMemEval plus a baseline harness that benchmarks Mem0, A-MEM and LangMem side by side — useful even if you adopt none of them. The compression-first pipeline (LLMLingua before storage) is the differentiating idea. Expect paper-adjacent ergonomics: manual model downloads and config dicts, not a polished product.
metronix-memory — the curator's take
Reach for it when you want one self-hosted box doing dense + sparse + graph retrieval and keeping long-lived facts fresh, and you're willing to run four datastores to get it. Skip it if you only need per-project session recall — a SQLite memory plugin is a fraction of the operational surface. Read the benchmark table with care: they are the author's own N=1 runs under a self-defined protocol, and the honest signal in them is that retrieval scores (Recall@10 85-95%) far outrun end-to-end answers (53-63%) — finding the evidence was never the hard part.