Claude's memory stays inside Claude. 7 alternatives for when your work doesn't

Claude remembers you. Until you open Codex. Then you're a stranger again.

That vendor boundary is the whole story behind "Claude memory alternatives." Claude's built-in memory is real and useful, but it's scoped to Claude. The second your workflow includes a second tool, a scheduled job, a different model, that memory may as well not exist. So people go looking for a memory layer that sits outside any one vendor.

Here are the seven worth knowing, organized by the situation you're actually in.

Situation 1: You never leave Claude

Stay with Claude's built-in memory. No new account, no integration, no bill. It keeps context across your sessions and projects inside the product.

The catch is the one you already know: it's a single-vendor memory. Add one more tool and you're back to re-briefing. If your whole workflow genuinely lives in Claude, stop reading. You don't have a memory problem.

Situation 2: You're building one agent app and need memory beside it

This is Mem0 territory, and it's the most popular answer for a reason. Open source (Apache-2.0), 60k+ stars, and a genuinely simple model: your app calls add() when something worth remembering happens and search() when the agent needs context, scoped by user_id and agent_id. Self-host it as a library or a server, or pay for the hosted platform and skip the infrastructure.

The tradeoff: you instrument your own app. Self-hosting means a vector store plus Postgres that you run. And it stores extracted facts, not the conversation itself, so what the extraction pass drops is gone.

Two neighbors worth knowing in this situation:

• Cognee (Apache-2.0) builds a knowledge graph from your agent's history and re-weights it from use. A correction sticks instead of the store just growing. Same deal otherwise: you wire it into your own app.
• Zep, built on the open-source Graphiti engine, is the pick when your agent needs to know when things were true. Its temporal knowledge graph records valid-from/valid-until on facts, so "what did we know last March" is answerable. Graphiti you self-host against your own graph database; Zep Cloud is managed-only.

Situation 3: You want the agent to manage its own memory

Letta, the project that grew out of the MemGPT research, takes the boldest position: memory as an operating-system concern. The agent gets tiered memory (core, recall, archival) and pages facts in and out with tool calls, rewriting its own store as it works.

The tradeoff: you adopt the whole agent runtime. Of everything on this list, it's the most infrastructure and the most commitment. Right when you want self-managing stateful agents; overkill when you wanted a shared notes file.

Situation 4: Your agents run across five tools and you run zero servers

Now we're in cross-tool territory, and there are two serious answers.

Smara is the self-hoster's answer. MIT-licensed with a Docker Compose setup, it's a memory API with semantic search, decay scoring, and contradiction detection at write time. The pricing is refreshingly quantified: 10,000 memories free, $19/mo for 200,000. Integrates over MCP and REST. The tradeoff: it's a memory store, not a work system. No tasks, no rules, no project boards.

Vilix AI is the fully-managed answer. It's a cloud-hosted shared memory and work-state layer across MCP clients on one account: the same memory follows you through Claude, Codex, Cursor, OpenClaw, Hermes, even headless scheduled agents over a plain API key. Two differences from the fact-extractors above: it stores full conversation exchanges with source metadata (so you can revisit what was actually said), and it carries work state alongside memory, projects, tasks, rules, reusable agent skills, editable from any connected tool or the dashboard at app.vilix.ai. Retrieval is semantic plus keyword and recency-aware; conflicts resolve last-write-wins. Free plan is limited, then $10/$20/$49 a month, with a 7-day Pro trial and no credit card.

The honest tradeoffs, since this list is useless without them: Vilix AI is cloud-only, every client still needs its own setup, and connecting a tool doesn't import its old history. If your data can't leave your hardware, Smara's self-hosting wins outright and no cloud tool can argue with it.

The decision in one paragraph

One tool, no new moving parts: stay in Claude. One app you're building: Mem0 for the lightest lift, Cognee if corrections should compound, Zep if facts have a timeline. An agent that owns its own state: Letta. Many tools and you want to hold the server: Smara. Many tools and you want to hold nothing: Vilix AI.

The question isn't which memory is "best." It's which boundary you're actually hitting: one vendor, one app, or many tools. Name the boundary and the list picks itself.