Wenlan vs Superlocal Memory: Local-First AI Work Memory for Work That Spans Tools

Superlocal Memory and Wenlan both sit in the local-first AI memory category, but they optimize for different buying questions. Choose Superlocal Memory if its reliability-engineering framing, modes, benchmark positioning, and IDE integration story match your workflow.

Choose Wenlan as the Superlocal Memory alternative when you want local AI work memory centered on sessions, handoffs, source-cited pages, MCP clients, and deliberate page distillation.

Superlocal Memory presents itself as memory for AI reliability engineering, and its current public positioning goes beyond memory retrieval. It now frames the product as a local reliability layer spanning memory, cache, compression, and cost optimization.

The official site and README describe repeat-call caching, prompt compression, provider KV-cache alignment, local-first retrieval, memory modes, IDE integrations, open research, AGPL v3 licensing, and benchmark-oriented claims. Treat the published savings numbers as the project's attributed claims and test them against your own workload.

Wenlan focuses on the loop around real AI work: sessions start, work happens, handoffs are written, memory is distilled, and the next session receives relevant context.

The daemon-owned store powers retrieval, graph context, and hybrid search while Markdown artifacts stay readable and source-cited for inspection.

If you want a reliability-oriented product with its own memory modes and integration claims, Superlocal Memory may be the natural thing to inspect.

If you want the memory layer to feel like a transparent local record of your work across MCP-compatible tools, Wenlan is the closer fit.

Superlocal Memory reports ~74.8% on LoCoMo in their zero-LLM (pure-math) retrieval configuration. Wenlan's current public retrieval snapshot now leads with LongMemEval rows instead of preserving the older LoCoMo headline.

Two things to read alongside it. First, benchmark mix: LongMemEval (LME) is a more recent and more rigorous evaluation, especially for time-aware questions and contradiction handling. Wenlan reports LME_Oracle at 93.6% Recall@5 / 0.857 MRR / 0.883 NDCG@10 on the 500-question snapshot, and LME_S at 87.7% Recall@5 / 0.815 MRR / 0.822 NDCG@10 on the stratified N=90 deep-S retrieval snapshot. I did not find LongMemEval numbers on SuperLocalMemory's official site during the 2026-06-24 source check. The leaderboard story is incomplete without both.

Second, configuration: 'zero-LLM' means retrieval only, no answer generation. Wenlan's published retrieval rows are also retrieval-only, but Wenlan's product is designed to feed memories into an LLM for answer composition, not to be a SOTA retrieval algorithm in isolation. Different products optimize for different downstream tasks.

If LoCoMo top score is the deciding factor for you, rerun the current Wenlan harness against the exact protocol you care about. If the question is 'which tool helps me carry AI work across sessions,' the benchmark is one input, not the answer.

I picked LME_Oracle and LME_S as Wenlan's primary retrieval surfaces because the workload matches what actually breaks AI sessions: multi-turn conversations with implicit time references, contradictions across turns, references to facts established weeks ago. LoCoMo and LongMemEval stress different failure modes; run both against your workload if benchmark fit matters.

The product gaps I notice in daily use are not retrieval ceiling. They are things like: did the AI capture the decision when I made it, is the wiki page distilled cleanly, can I open `~/.wenlan/pages/auth.md` and read it as prose, can I inspect the source memory IDs and artifact git history, does the same memory show up in Cursor and Claude Code.

Those are workflow features, not benchmark features. Wenlan trades leaderboard simplicity for explicit capture, MCP-first cross-tool reach, projected Markdown, versioned readable artifacts, and mandatory provenance. If those things matter to your work, the trade is worth it. If they do not, look at Superlocal.

Try this on any memory layer you are evaluating, including Wenlan. Open the tool. Find one memory the AI stored about you in the last week. Now answer five questions in under 10 seconds: can you see the verbatim text, can you see when it was stored, can you see what generated it, can you see what changes have been made to it since, can you delete it without an admin panel.

Wenlan scores high on this test by design. Raw captures live in the daemon store for retrieval, while readable pages, session logs, and project status live under `~/.wenlan/` and are versioned in `~/.wenlan/.git/`. `wenlan recall <query>` shows matching memory text. Deletion goes through `/forget` or the MCP forget tool by source ID.

Superlocal Memory now publishes source, docs, and research papers as part of its open research positioning. Use those materials to run the same inspection test against its current record format, provenance surface, history, and deletion flow before deciding.

If I were picking a memory layer from scratch today, I would run a two-week parallel trial. Week one: install both, point an MCP-capable AI client at each, and use them for real work. No synthesized traffic. Real captures only.

End of week one, run three queries against each: 'what did I decide about X last Monday,' 'who did I have a conversation with about Y,' 'what is the current status of Z.' Compare not just accuracy, but readability of the response and traceability of where it came from.

Week two, deliberately try to break each one. Introduce a contradiction by capturing two conflicting facts on consecutive days. Use a different MCP client. Kill the daemon mid-session and restart it. The product that recovers cleanly and surfaces the contradiction is the one I would keep.

I am biased; I built Wenlan. This trial shape will surface real differences faster than reading either product page, including this one.