Articles

Claude Code memory vs. an MCP memory layer: what actually changes

Claude and Claude Code both carry memory that's scoped to Anthropic's own products: Claude's chat memory to your account, Claude Code's to CLAUDE.md and project memory files in that repo. An MCP memory layer is a file on your machine that any assistant can read. That's the entire difference, but it changes what happens the moment you switch tools, switch projects, or switch computers.

An amber capsule glowing inside a closed dome, beside an identical capsule floating freely with no enclosure

What Claude's built-in memory actually is

Claude's memory feature does something genuinely useful: it lets Claude carry context across separate conversations without you re-explaining yourself each time. It's built into the product, it works out of the box, and for most people using one assistant most of the time, it's the right amount of memory. It also has a specific shape: it belongs to your Claude account, on Anthropic's infrastructure, and it's legible to Claude specifically. That's not a flaw; it's what an in-product memory feature is for.

Where Claude Code's own memory hits a wall

Claude Code's memory, written to CLAUDE.md and project-level memory files, is genuinely useful for the thing it's built for: keeping conventions, decisions and context alive within one project, read back automatically at the start of a session. It's also deliberately scoped to that project and kept small, since it gets re-read into context on every session; a growing CLAUDE.md gets trimmed, split, or otherwise managed rather than left to grow without limit. That's a reasonable design choice for what it's for. It also means it's not the place for a fact you want available in a different project, a different tool entirely, or on a different machine.

What changes when memory lives outside any one assistant

A memory layer like ModelBrain stores what you tell it as ordinary files on your own machine, independent of which assistant wrote them or reads them back. The practical difference shows up in three moments a built-in memory can't help with: switching to a different assistant (the new one starts from zero), switching to a different machine without that vendor's sync (same problem), and wanting your history to be portable rather than tied to one account you'd have to keep active to keep it.

Not a replacement, a different layer

These aren't competing claims about whose memory is better. Claude's memory is optimized for continuity within Claude, across your conversations there. A memory layer is optimized for durability across tools and time: the record outlives the chat window, the subscription, and the particular assistant you used to write it. Plenty of people reasonably want both: Claude's own memory for how a conversation flows, and a separate, exportable record for anything they'd be upset to lose.

Where this actually matters

If everything you'd ever want to recall was said inside Claude and you're comfortable with Claude being the only place it's readable, a memory layer adds a second thing to maintain for no real gain. It matters when the material needs to survive a tool change, when you use more than one assistant against the same body of context, or when you want to be able to point at the actual files later, not just trust that they exist somewhere in a vendor's account. How ModelBrain's recall actually behaves goes into what "remembering" means once it's not tied to one conversation.

How the provenance behind each memory is tracked, regardless of which assistant wrote it: how ModelBrain tags what it remembers.