Wenlan vs claude-mem: Which Claude Memory Workflow Fits Your Work?

Choose claude-mem if your primary need is an observer-style memory workflow tightly centered on Claude Code sessions.

Choose Wenlan if you want local-first AI work memory that can serve Claude Code, Cursor, Codex, Claude Desktop, Gemini CLI, and other MCP-compatible tools.

claude-mem presents itself as a memory sidekick for Claude Code. Its core idea is watching work happen, capturing decisions and context, and retrieving that context later with useful scoping.

That is compelling when the main product surface is Claude Code and the desired experience is automatic memory capture around that tool.

Wenlan treats memory as part of a local AI work loop, not a single-client feature. Claude Code is important, but Wenlan also works through MCP so other clients can share the same context.

Wenlan's workflow includes handoffs, manual distillation, optional model-backed page work, wiki pages, readable artifacts, local indexes, and provenance attached to durable memories.

If you live entirely in Claude Code and want an observer-style assistant for that environment, claude-mem is directly aimed at that habit.

If your work moves across coding agents, chat tools, projects, and sessions, Wenlan is designed to make the same context portable across those surfaces.

claude-mem watches your Claude Code session and extracts memorable context without you naming it. The promise is low friction: keep working, memory accumulates on its own.

Two trade-offs show up over weeks of use. First, false positives: an observer cannot reliably tell which 'decision' is durable versus which is the start of an idea you will revise an hour later. Second, attribution: when the AI later cites memory, you usually want to know whether it came from your considered handoff or from a sentence you typed while still figuring out the problem.

Wenlan defaults to explicit capture for that reason. `/capture` is one keystroke during flow. `/handoff` preserves session state, and `/distill` deliberately turns repeated context into source-backed pages. Optional local models or API keys can add background extraction and page refresh work. The high-confidence layer is the one you marked.

claude-mem's session-end pattern, as documented, summarizes the Claude Code session into memory entries automatically. That summary lives in claude-mem's store and gets retrieved on the next session via MCP.

Wenlan's session-end pattern is the `/handoff` flow. You write one to three sentences about what happened, what is blocked, and what is next. The daemon attaches that to your session captures, links related entities, and updates readable session/status artifacts under `~/.wenlan/` that are versioned in `~/.wenlan/.git/`. The next session starts with a handoff brief plus relevant prior context, not a chat-log summary.

Both reduce repeated context across sessions. The difference is who decides what is worth carrying forward: the model (claude-mem) or you with model help (Wenlan).

claude-mem's positioning is Claude Code first. MCP exposure exists so other clients can read the store, but the workflow shape (observer of Claude Code sessions) is the product.

Wenlan's positioning is MCP first, Claude Code as one of many clients. One daemon at `127.0.0.1:7878` serves any MCP-compatible runtime. In my own work I switch between Cursor for refactors, Claude Code for greenfield, and Codex for shell-heavy tasks; the memory is the same memory.

If you live 100% inside Claude Code, this difference is theoretical. If you context-switch between tools across a typical week, it is the difference between one memory layer and three disjoint ones.

If your AI work is entirely inside Claude Code, you want zero capture friction, and you are comfortable letting an observer pick what is memorable, claude-mem is shaped exactly for that. Single-tool by design, not by oversight.

If you want explicit human control over what enters memory, multiple AI clients sharing one local context store, or git-versioned audit trails for readable artifacts, those are not claude-mem's headline features. Use Wenlan.

Cost: claude-mem ships as an npm package under MIT. Wenlan's daemon, CLI, and MCP server are Apache-2.0. Both are free to self-host. The optional Wenlan desktop app lives in a separate repo under AGPL-3.0 if you want a GUI on top.