Wenlan vs SuperLocalMemory v3.8.3: Local AI Memory Compared

Choose SuperLocalMemory when you want a local-first agent memory control plane with automated ingestion, temporal and graph-aware retrieval, personal and team scopes, a dashboard, cache and compression controls, bounded loops, and framework adapters.

Choose Wenlan when you want an LLM wiki for AI work: explicit capture, handoffs between sessions, reviewable memories, source-backed pages, local hybrid retrieval, and readable artifacts that can sit beside an Obsidian vault.

Both are local-first and MCP-capable. The useful distinction is not whether either product has retrieval; it is whether you want a broad operational control plane or a deliberate, inspectable knowledge workflow.

The maintained v3.8.3 README now describes SuperLocalMemory as an enterprise-oriented, local-first agent memory control plane rather than only a retrieval and optimization layer. SQLite and sqlite-vec remain canonical; optional CozoDB and LanceDB projections stay behind parity checks.

Its current retrieval path combines semantic, BM25 lexical, temporal retrieval, Hopfield associative, and spreading-activation candidates before fusion and optional reranking. The release also exposes provenance, memory inspection, personal, shared, and global scopes, multi-workspace isolation, role-based access, retention and erasure controls, a hash-chained audit trail, and a dashboard.

The control plane also covers exact caching, opt-in compression, trusted-peer coordination, bounded loops, and nine framework adapters. Provider-backed enrichment, cloud modes, connectors, and networked adapters remain explicit operator choices rather than requirements of the local core.

Wenlan focuses on turning AI work into a maintained, source-backed LLM wiki. Agents explicitly capture durable facts, write handoffs, retrieve prior context, curate revisions, and distill selected memories into readable pages.

Its local daemon combines FTS5, BGE embeddings, weighted reciprocal-rank fusion, eligible graph context, and optional reranking. The same memory is available across MCP clients, while projected Markdown pages, citations, revisions, session artifacts, and local git history keep the maintained knowledge layer inspectable.

Wenlan is not trying to be a team access-control plane, an LLM proxy, or a framework runtime. Its narrower boundary is useful when the primary job is preserving why work changed and keeping the resulting knowledge readable by people.

Start with the artifact you need at the end. If you need a governed operational memory service for several agents or people, test SuperLocalMemory's profiles, scopes, role gates, audit surfaces, cache, compression, and framework adapters.

If you need a durable project record that an agent can retrieve and a person can open, review, cite, revise, and carry across tools, test Wenlan's capture, handoff, recall, curate, distill, and page workflows.

A team can reasonably use both boundaries. The comparison matters when choosing which product should own the durable memory and which one, if any, should own optimization or operational controls.

SuperLocalMemory's maintained README separates three LoCoMo results. Mode A Raw reports 60.4% across 10 conversations and 1,276 scored questions with local retrieval and zero-LLM answer construction. Mode A Retrieval reports 74.8% on the same question count, but uses GPT-4.1-mini answer synthesis after local retrieval. Mode C reports 87.7% on one conversation and 81 scored questions with cloud embeddings, answer generation, and judging.

Wenlan publishes retrieval-only LongMemEval rows: LME_Oracle at 93.6% Recall@5 / 0.857 MRR / 0.883 NDCG@10 on 500 questions, and LME_S at 87.7% Recall@5 / 0.815 MRR / 0.822 NDCG@10 on a stratified 90-question deep-retrieval snapshot.

Those percentages are not a head-to-head leaderboard. The datasets, sample sizes, answer-construction steps, models, and metrics differ. Use each result to inspect its own retrieval contract, then rerun both products on the same workload if benchmark performance determines the decision.

Install both against disposable test data. Store a decision, its source, and a later correction. Ask a time-qualified question, inspect which evidence was retrieved, verify the correction, delete the original, restart the service, and repeat from a second MCP client.

In SuperLocalMemory, inspect the operation receipt, provenance, scope, audit event, profile boundary, recall trace, and dashboard record. In Wenlan, inspect the recalled memory, source IDs, curated revision, distilled Markdown page, session handoff, and local git history.

Then test the failure paths you actually care about: low-confidence recall, conflicting facts, unavailable enrichment, a busy daemon, a profile or Space boundary, and recovery after restart. This produces a decision you can audit instead of a feature-count vote.

During week one, use real work rather than synthetic prompts. Record capture effort, recall usefulness, source traceability, false positives, and how often a person must repair the memory. Keep SuperLocalMemory's optional cloud modes and Wenlan's optional enrichment settings fixed and documented.

During week two, test time, contradiction, deletion, restart, and cross-client behavior. If you need team governance, add two profiles and verify read, write, and delete boundaries. If you need a maintained knowledge base, require each system to produce or support a readable project summary with citations.

I built Wenlan, so treat this page as a source-linked test plan rather than a neutral verdict. The pinned references above are there so you can check every moving product claim before choosing.