bettermemory
Persistent memory for Claude Code, retrieved on demand instead of force-fed into every prompt.
bettermemory is a Claude Code plugin (and a standalone MCP server for any other client) that fixes a problem common to most LLM memory features. Those tools auto-inject every stored fact into every conversation. They have no sense of which facts are stale, which are relevant, or which you would rather forget. The longer you use them, the more polluted unrelated conversations become. Ask for a Python tutorial, get answers tinted by your home-lab notes. Ask a generic shell question, get advice coloured by a preference you stated months ago. Stale facts get dispensed confidently.
bettermemory inverts the contract. The model calls memory_search only when it actually needs context. Every retrieval ships with three structured staleness signals (verification, path_drift, commit_drift) so the model can spot-check before relying on what it pulled up. Memories live as plain markdown and YAML on disk, so you can grep them, git log them, and hand-edit them. A separate health surface tells you what is dead weight and what has drifted, instead of letting the store grow into a haunted closet of half-true notes.
Install in Claude Code
/plugin marketplace add 0Mattias/bettermemory
/plugin install bettermemory@bettermemory
That is it. Claude Code starts the MCP server, loads a system-prompt-level skill carrying the opt-in retrieval policy, and on the next turn the model has all 17 memory tools and the discipline to use them correctly. For other clients (Claude Desktop, Cursor, Continue, Cline) and manual setup, see § Other MCP clients below.
How it compares
| Most memory features | bettermemory | |
|---|---|---|
| Retrieval | Auto-injected into every prompt | Model calls memory_search only when needed |
| Staleness awareness | None: facts are surfaced as if current | Three structured signals (verification, path_drift, commit_drift) on every retrieval |
| Storage | Opaque database | Plain markdown plus YAML on disk; works with grep, git, and any text editor |
| Curation tools | None: memory just grows | memory_health surfaces dead weight, contradictions, typo scopes, and verification debt |
| Deletes | Gone forever | Tombstones with reason, tombstone-aware dedup, reversible via memory_restore |
| Project scoping | Everything mixed together | Auto-scoped by git repo; cross-project queries are explicit |
| Inferences about you | Saved silently | Structural confirmation tier: the model asks before saving |
| Feedback loop | None | memory_record_use outcomes feed memory_health so dead weight surfaces automatically |
What it looks like in practice
Day one. You tell Claude something:
"When I ask for a tutorial, I want runnable code, not screenshots of an IDE."
Claude calls memory_write(category="user-inference", scopes=["learning-style"], …). Because the memory captures a claim about you, the write goes pending. Claude asks: "Want me to remember that you prefer hands-on tutorials with runnable code?" You confirm. The fact lands at ~/.claude-memory/ as a markdown file you can read, edit, or delete.
Week two, in a fresh session. You ask:
"Walk me through pandas from zero to hero."
The phrase "zero to hero tutorial" is the kind of ambiguity stored preferences could resolve, so Claude calls memory_search, surfaces the stored learning-style memory, and tells you up front: "Using your stored preference for code-driven tutorials…" before answering. Compare with auto-injection memory, which would have done the same thing silently, even on "what is the capital of France?"
Month three. You ask about an unrelated tool:
"What is the difference between
findandfd?"
This question is generic. Claude does not call memory_search. The reply is pristine generic-shell prose, untainted by months of accumulated personal context. That is the whole design.