Claude remembers things now. Close a session, open a new one, and it still knows your preferred test framework, your directory structure, your naming conventions. It works. It is genuinely useful. And it costs nothing.
So why would anyone install an external memory tool?
That question deserves a straight answer -- not a sales pitch. If built-in memory covers your needs, you should use it. But if you have bumped into its limits, or if you are about to, here is what those limits actually are.
What built-in memory does well
Credit where it is due. Claude's native memory handles a specific job effectively: capturing personal preferences and project context within Anthropic's own surfaces. It auto-detects things like your build commands, your code style preferences, and your architecture decisions. It persists across sessions. For a single developer working exclusively in Claude Desktop or Claude Code, it removes real friction.
The import/export feature means your memory is not entirely trapped, either. You can pull it out as a bulk export and move it somewhere else.
For casual use -- a developer with one project, one tool, one workflow -- this is enough.
The problems start when your workflow gets real
Most professional developers do not work in a single tool. They move between Claude Code for implementation, a desktop client for design discussions, Cursor or Windsurf for specific codebases, and sometimes a web interface for quick questions. Built-in memory lives inside Anthropic's surfaces. It does not travel with you.
That is the first fracture. But there are more.
Your memory is fragments, not sessions
Built-in memory stores disconnected facts: "prefers pytest over unittest," "uses snake_case," "project uses FastAPI." These are useful. They are also flat. There is no narrative, no timeline, no connection between decisions.
When you need to recall why you chose FastAPI over Flask three weeks ago, or what trade-offs you weighed when designing a particular schema, fragments do not help. You need the session where that conversation happened -- the full context, the artifacts produced, the decisions made and the alternatives rejected.
Session-oriented memory preserves the shape of your thinking, not just its conclusions. When you return to a project after a week away, you do not need a list of preferences. You need to pick up where you left off.
Your projects blur together
Built-in memory is a single namespace. If you work on three projects, your memories from all three coexist in one undifferentiated pool. There is no way to scope a search to "show me what I decided about the database schema in project X" without also surfacing unrelated memories from projects Y and Z.
Project-scoped memory -- where sessions are tagged by project and searchable within that scope -- is not a luxury feature. It is how professional developers actually organize their work. One project per context, clean boundaries, no cross-contamination.
You cannot query your own history
Built-in memory is not searchable in any structured way. You cannot run a query like "find all sessions from last week where I discussed authentication" or "show me every decision I made about the API design." The memory is there, but you cannot interrogate it.
For a solo developer on a small project, this is a minor inconvenience. For someone managing multiple projects, coordinating with a team, or building systems that need an audit trail, it is a gap.
Your data lives somewhere else
Built-in memory is stored on Anthropic's infrastructure. You do not control where it lives, how long it persists, or what happens to it if you change providers. There is no local file you can back up, version-control, or migrate.
For developers who care about data sovereignty -- and increasingly, for organizations with compliance requirements -- this matters. A single local file that you own, back up by copying, and can inspect with standard tools is a fundamentally different proposition than cloud-stored memory you access through an API.
What session-oriented memory looks like in practice
The difference between fragment memory and session memory is not abstract. Here is a concrete example.
After a two-hour architecture session where you design a new data pipeline, fragment memory might capture that you chose LangGraph for orchestration, that you prefer SQLite for local storage, and that the pipeline has nineteen nodes. Those three facts are not wrong -- they are just incomplete. Session memory captures the full conversation: the title, the summary of decisions made, the artifacts produced, tags linking it to the project, and a timestamp. When you come back next week, you search for "pipeline architecture" and get the complete context, not three disconnected facts.
This is especially valuable when you need to explain a decision to someone else, or when you need to revisit a choice you made under different constraints. The reasoning matters as much as the conclusion.
When built-in memory is enough
Be honest about this. If you work exclusively in Claude's own interfaces on one or two small projects, do not need to search your conversation history, and are comfortable keeping that data on Anthropic's infrastructure, then built-in memory probably covers you. It is free, it is automatic, and it works within its scope. There is no reason to add complexity you do not need.
When you need something more
The case for session-oriented memory builds quickly once your workflow has any real complexity. If you move between multiple MCP-compatible clients -- Claude Code, Cursor, Windsurf, or any other tool that speaks MCP -- you have already left behind what any single tool's built-in memory can reach. Your history needs to follow you across all of those surfaces, not reset each time you switch. Add project boundaries to that picture, and the mismatch becomes even clearer: a flat namespace where memories from three different projects coexist without scoping is not a limitation you work around -- it is a fundamental mismatch with how professional developers organize their work.
The ability to search your own history changes things further. Full-text search across sessions, filtered by project, date, or tag, turns session records into a queryable knowledge base. The question "what did I decide about the API design in project Y last month?" becomes answerable in seconds rather than impossible. That search also implies structure: timestamps, surface tracking, artifact lists, and metadata that lets you navigate decisions after the fact. Not fragments -- records.
Data ownership is a quieter concern until it matters. A local SQLite file you own, can back up by copying, can inspect with any SQLite tool, and can migrate to a new environment independently is a different kind of asset than cloud-stored memory you access through an API. For developers with compliance requirements or an aversion to vendor lock-in, that distinction is not theoretical. And if you coordinate with a team now, or expect to, structured portable sessions position you well for when collaboration tools catch up -- flat preference fragments are much harder to share meaningfully than organized, tagged session records.
The real question is not "free vs. paid"
The interesting question is not whether memory costs money. It is whether your memory system matches the complexity of your actual workflow.
Built-in memory is a good default for simple workflows. But professional development work is not simple. It spans tools, projects, timelines, and teams. A memory system built for that reality -- portable, structured, local-first, and session-oriented -- is not competing with built-in memory. It is solving a different problem.
The developers who benefit most from external session memory are the ones whose work has already outgrown what any single tool's built-in features can track.
LoreConvo is an MCP server for persistent session memory. It works in Claude Code, Claude Desktop, and any MCP-compatible client. Learn more about LoreConvo or get in touch if you want to talk through your memory architecture.