5 Ways to Add Memory to Claude Code (Compared)

If you use Claude Code for anything beyond one-off scripts, you’ve hit the memory wall. Every session starts from zero. Context compaction destroys your working state. MEMORY.md caps out at 200 lines.

The good news: the community has built real solutions. The bad news: there are enough options that choosing one is its own time sink.

I’ve tested all of the major approaches. Here’s an honest comparison — what works, what breaks, and which one fits your situation.

1. CLAUDE.md + MEMORY.md (Built-In)

What it is: Claude Code’s native memory system. CLAUDE.md files hold project instructions; MEMORY.md (in ~/.claude/projects/) stores notes Claude writes to itself. Both load into the system prompt at session start.

Setup: Nothing. It’s already there.

How it works:

• CLAUDE.md at your project root — team-shared instructions, conventions, architecture notes
• CLAUDE.local.md — personal notes, auto-gitignored
• ~/.claude/CLAUDE.md — global preferences across all projects
• MEMORY.md — auto-generated by Claude, loaded at session start

The good:

• Zero setup, zero dependencies, zero cost
• Works offline
• CLAUDE.md is version-controlled with your project
• Simple enough to understand in 5 minutes

The bad:

• MEMORY.md has a hard 200-line cap. Content beyond line 200 is silently dropped. No warning. (Issue #25006)
• No search. Claude reads the entire file every session. With 200 lines of notes, it has no way to find specific context by meaning.
• Post-compaction amnesia. Multiple bug reports document Claude ignoring CLAUDE.md after context compaction. (Issue #4017, 20 upvotes)
• No automatic extraction. Claude has to decide what to write down. Important context slips through constantly.
• No cross-device sync. Each machine has its own disconnected MEMORY.md.
• Hidden token cost. Every message re-sends the full CLAUDE.md. One developer found cache reads consuming 99.93% of total token usage.

Best for: Small projects, quick tasks, developers who don’t want to install anything.

Verdict: Fine for getting started. Inadequate for serious, multi-session development.

2. Local Vector Database Solutions

What it is: The most popular category of third-party memory solutions. These tools capture session context, compress it with Ai, and store it in a local database with vector search.

How it works:

• Integrates with Claude Code’s session lifecycle for seamless recovery
• Captures conversation context and compresses it into summaries
• Stores summaries locally with vector embeddings for search
• Injects relevant context at session start automatically

The good:

• Large communities, actively maintained
• Battle-tested across thousands of developers
• Open source options available
• Session summaries are automatic
• Vector search finds relevant context

The bad:

• Local dependencies. Typically requires multiple runtimes and databases running on your machine.
• RAM consumption. Local vector database solutions can consume significant system resources, especially during long sessions.
• No cross-device sync. Your memories live on one machine. Work from a laptop and desktop? Two separate memory stores.
• License restrictions. Some popular options use restrictive licenses that may be a concern for enterprise environments.
• Session-level granularity. Captures session summaries, not individual facts. You can’t search for a specific architecture decision — you search for sessions that might have mentioned it.

Best for: Developers who want a proven, community-backed solution and work from a single machine with plenty of RAM.

Verdict: The community standard. Solid choice if you don’t mind local resource usage and single-machine limitations.

3. Other MCP Memory Servers

What it is: Several MCP servers offer persistent memory with knowledge graph features, semantic search, and autonomous memory consolidation.

How it works:

• Runs as an MCP server alongside Claude Code
• Stores memories locally with vector embeddings
• Provides tools for saving, searching, and managing memories
• Some include knowledge graph relationships between memories
• Autonomous consolidation merges related memories over time

The good:

• Knowledge graph structure adds relationship context
• Semantic search finds memories by meaning
• Autonomous consolidation reduces memory bloat
• MCP-native — works through the standard protocol

The bad:

• Complex setup. Often requires Python, additional runtimes, and local vector databases. Multiple configuration steps.
• Stability concerns. With other MCP memory servers, stability varies between releases. Check issue trackers before committing to one.
• Local-only. Same single-machine limitation as local vector database solutions.
• Smaller communities. Fewer people testing edge cases compared to the most popular solutions.
• Heavy dependencies. Embedding model downloads can be hundreds of megabytes and may fail on some platforms.

Best for: Developers who want knowledge graph features and don’t mind a more complex setup process.

Verdict: Ambitious architecture, but stability can vary. Check the issue tracker before committing.

4. CogmemAi (Cloud-Based)

What it is: A cloud-first MCP server that moves all memory intelligence server-side. The local MCP server is a thin HTTP client — no databases, no vector stores, no heavy dependencies. Full disclosure: I built this one.

Setup:

npx cogmemai-mcp setup

How it works:

• 12 MCP tools: save, recall (semantic search), extract (Ai-powered), project context, import/export, and more
• Memories stored with high-dimensional semantic embeddings server-side
• Ai extraction identifies important facts from conversations automatically
• Smart deduplication detects duplicate and conflicting memories
• Project scoping via git remote auto-detection + global preferences
• Automatic compaction recovery — context is preserved and seamlessly restored

The good:

• Zero local setup. No databases, no Python, no Docker, no vector stores. One command.
• Zero RAM issues. Nothing running locally except a thin HTTP client.
• Cross-device sync. Memories are in the cloud. Work from any machine.
• Compaction recovery. Automatically saves context before compaction and restores it after.
• Semantic search. Find memories by meaning, not keywords.
• Ai extraction. Automatically identifies facts worth remembering.
• Document ingestion. Feed in READMEs or docs to quickly build project context.
• Free tier: 1,000 memories, 500 extractions/month, 5 projects.

The bad:

• Requires internet. No network, no memories. Not usable offline.
• Data in the cloud. Your memories (short factual sentences, not source code) are stored on HiFriendbot’s servers. If that’s a dealbreaker, go local.
• Newer project. Smaller community than the most popular local tools. Fewer people have battle-tested it.
• Paid tiers for heavy use. Free tier is generous (1,000 memories), but Pro is $14.99/mo for 2,000 memories.

Best for: Developers who want zero-config setup, cross-device sync, and compaction recovery without managing local infrastructure.

Verdict: The trade-off is cloud dependency for zero maintenance. If you’re comfortable with that, it’s the fastest path to persistent memory.

5. Roll Your Own

What it is: Build a custom memory system tailored to your exact needs. Popular approaches include markdown file collections, SQLite databases with FTS5, or even Neo4j knowledge graphs.

Setup: However long it takes you to build it.

Common approaches:

• Markdown files + grep. Maintain a /memory/ directory with topic-based markdown files. Simple, version-controlled, human-readable. No semantic search.
• SQLite + FTS5. Store memories in SQLite with full-text search. Good for keyword matching, misses semantic similarity.
• Custom MCP server. Build an MCP server that wraps your preferred storage backend. Full control, full responsibility.
• Obsidian vault. Some developers use Obsidian’s knowledge graph as a project memory, connected via MCP servers like easy-obsidian-mcp.

The good:

• Complete control over storage, format, and retrieval
• No vendor dependency
• Can be exactly what you need and nothing more
• Educational — you learn how memory systems work

The bad:

• Time investment. Building a good memory system is a project in itself. Semantic search alone requires embedding models, vector storage, and retrieval logic.
• Maintenance burden. You own every bug, every upgrade, every edge case.
• No Ai extraction. Unless you build it, you’re manually deciding what to remember.
• No compaction recovery. You’d need to build the session lifecycle integration yourself.

Best for: Developers with specific requirements that no existing tool meets, or those who want to learn by building.

Verdict: Maximum flexibility, maximum effort. Only worth it if the existing tools genuinely don’t fit.

The Comparison Table

Feature	CLAUDE.md	Local Vector DB	MCP Memory Servers	CogmemAi	DIY
Setup time	0 min	~5 min	~15 min	~1 min	Hours/days
Local dependencies	None	Multiple (DB + runtime)	Python + vector DB	None	Varies
Semantic search	No	Yes (local)	Yes (local)	Yes (cloud)	If you build it
Ai extraction	No	Session summaries	No	Yes	If you build it
Compaction recovery	No	Yes (automatic)	No	Yes (automatic)	If you build it
Cross-device sync	No	No	No	Yes	If you build it
Works offline	Yes	Yes	Yes	No	Varies
RAM usage	None	High (resource-intensive)	Moderate	None	Varies
Memory capacity	200 lines	Unlimited (local disk)	Unlimited (local disk)	1,000 free / 50K enterprise	Unlimited
Project scoping	Per-directory	Per-project	Tags	Git remote + global	If you build it
Cost	Free	Free	Free	Free / $14.99+	Your time
License	N/A	Varies	Varies	MIT	Yours

My Recommendation

There’s no universally “best” option. It depends on what you value:

• “I don’t want to install anything.” → Stick with CLAUDE.md. Maximize those 200 lines. Use .claude/rules/*.md for topic-scoped instructions.
• “I want the most proven solution.” → A popular local vector database tool. Large community, active development. Accept the RAM trade-off.
• “I want zero maintenance.” → CogmemAi. One command, nothing local to break, memories follow you across machines.
• “I need knowledge graphs.” → An MCP memory server with graph features, but test the current version first.
• “I have specific requirements.” → Roll your own. Start with SQLite + FTS5 and add complexity as needed.

The worst option is no memory at all. If you’re still re-explaining your architecture every session, pick any solution from this list and set it up today. The 5–15 minutes of setup will save you hours every week.

---

I’m Scott, a network and systems engineer with 30+ years in the industry. I built CogmemAi after testing every approach on this list and wanting something with zero local infrastructure. Try whichever fits your workflow — the important thing is to stop losing context.