Gnosem vs. mem0, Letta, Zep: when hosted MCP memory is the right choice

Every few weeks somebody asks the same question: how does Gnosem compare to mem0, Letta, or Zep? The short answer is that they solve different problems for different audiences. The long answer is worth writing down, because the wrong choice wastes a lot of engineering time.

All four projects touch "AI memory." That is where the resemblance ends. Mem0, Letta, and Zep are libraries and frameworks that a developer imports into an application they are building. Gnosem is a hosted Model Context Protocol server that an existing AI assistant reads and writes to. If you are building an app that talks to an LLM, you probably want one of the libraries. If you use AI assistants and want them to share memory across vendors, you probably want Gnosem. The two categories don't compete so much as sit at different layers.

What each one actually is

mem0 is an open-source Python and TypeScript library. You install it in your app, wire up an LLM key and a vector store, and call memory.add() and memory.search() from your own code paths. It has managed hosting available, but the primary shape is a library your app calls. It ships with a small pipeline that extracts facts from raw conversation turns before storing them.

Letta (formerly MemGPT) is an agent framework focused on long-lived agents with hierarchical memory — core memory that always stays in context, and archival memory the agent can page in and out. Letta is a full agent runtime; memory is one of its subsystems. You use Letta by building agents on its runtime, not by adding memory to an agent someone else built.

Zep is a memory service for chat applications. It stores conversation history, extracts entities into a temporal knowledge graph, and exposes REST and Python APIs your app calls between turns. Cloud-hosted or self-hosted. The output is optimized for pulling into chat prompts.

Gnosem is a hosted MCP server. There is no library to import; you don't call it from application code. You point an existing MCP client — Claude Desktop, Cursor, Windsurf, Zed, Kimi, or any other client that speaks the Model Context Protocol — at https://gnosem.dev/mcp with a Bearer token, and the client automatically discovers five memory tools and calls them during a session on the user's behalf. The reading LLM sees Gnosem the same way it sees any other MCP tool.

The audience split

The clearest way to think about this: who is doing the writing?

• App developers write code that calls an LLM, and want that LLM to remember things across sessions. They control the runtime, own the prompts, and can insert a memory.add() call wherever they like. For them, mem0 / Letta / Zep are the right shape. Gnosem is not — there is no application code to bolt Gnosem into, because Gnosem sits outside the app.
• End users of AI assistants don't write any code. They use Claude Desktop for planning, Cursor for coding, ChatGPT for a second opinion, and Kimi when they want a long-context model. They can't add mem0 to Claude Desktop because they don't own Claude Desktop's source. What they want is a memory that follows them across vendors. For them, Gnosem is the right shape and the memory libraries are not applicable.

There is a third audience — app developers who want to expose memory to end users through their client of choice. That's a fit for Gnosem too, because Gnosem's tools appear in the client's tool list the same way any MCP tool would. You get "memory as a feature" without shipping any tool-calling glue.

The cross-vendor property nobody else has

The specific property Gnosem gives you that none of the libraries give you: one memory graph, many clients, no per-client integration.

Point Claude Desktop at Gnosem. Point Cursor at Gnosem with the same API key. Point Windsurf at the same endpoint. Now all three see the same memories, write to the same store, and can find things the other clients saved. Switch primary assistants next month? Your memory comes with you, because it never lived in the assistant.

If you built the same "memory sharing" capability on top of mem0, you would need each client to speak your mem0-wrapper's API. Because Claude Desktop, Cursor, and Windsurf don't speak your API — they speak MCP — you'd have to either fork every client or run a per-client shim. That's the work MCP was designed to eliminate.

Architecture and hosting

Gnosem's stack is deliberately narrow: everything runs on Cloudflare (Workers, D1, Vectorize, Workers AI). That's the price of eliminating the "run your own infra" step. If you want to self-host on your own Cloudflare account you can — the source is MIT — but there is no "run on your own Postgres" path, because that would break the edge-native architecture that makes it sub-100ms.

Fact extraction: everyone does something, but differently

All four projects transform raw text before storing it, but the shape is different.

Mem0's pipeline runs an LLM over each conversation turn and extracts atomic facts as separate memory records, then also does an update/conflict resolution step to reconcile with existing memories. This produces a clean fact graph but is chatty on the LLM side — a real per-write cost in tokens.

Letta's core/archival split isn't a fact-extraction step; it's a memory hierarchy the agent manages by tool call. The agent decides what to promote from archival to core memory.

Zep builds a temporal knowledge graph of entities and relationships from conversation history. Retrieval blends the graph with dense vector search.

Gnosem is closer to a hybrid. Long memories (over ~400 characters) are compressed on write into structured pipe-separated key–value pairs — TOPIC=..., PROJECT=..., DECISION=..., STACK=... — with the raw prose preserved. Semantic search embeds the raw content, so search behaves naturally, but retrieval returns the compressed form by default so the reading LLM ingests fewer tokens. Discussed in more depth in Memories that Cost Fewer Tokens to Read.

None of these is objectively "better." They optimize for different things. Mem0 optimizes for a clean queryable fact database. Zep optimizes for chat-context reconstruction. Gnosem optimizes for the token cost of cross-vendor recall.

Pricing shape

Because Gnosem is a hosted end-user product and the others are primarily libraries with optional hosted tiers, pricing shape is different.

Gnosem's Pro tier is $9/month or $90/year and includes unlimited memories up to 1 GB storage. Free tier is 200 memories. The pricing model is "individual with a credit card, not a manager approval."

Mem0, Letta, and Zep all offer free open-source self-hosting and have separate managed cloud tiers that are usage-based (per API call, per token embedded, per memory stored). Their managed products are priced for teams and products, not individuals.

Neither approach is universally cheaper. If you're a developer with real usage inside an app, per-request pricing on a managed library may beat a flat individual subscription. If you're one person using AI assistants heavily across four vendors, $9/month with unlimited memories is going to be cheaper than any per-request tier at that scale.

When to pick what

Pick mem0 if: you are shipping an app with a chat UI, you own the runtime, and you want a clean library with pluggable vector store choice and a solid fact-extraction pipeline.

Pick Letta if: you are building an agent runtime and want first-class agent memory as part of a broader agent framework. Not the right shape if you already have an agent orchestration layer you like.

Pick Zep if: you are shipping a chatbot or assistant application, want chat-history-aware retrieval, and value the temporal knowledge graph model. Their managed tier is aimed squarely at production chat apps.

Pick Gnosem if: you use more than one AI assistant, and want them to share a memory. You aren't building an app; you are using apps that already exist, and you want those apps to remember your context across vendors. Bearer token in the client config, done — nothing to import, deploy, or maintain.

The stack-level equivalent to keep in mind: mem0/Letta/Zep are like SQLite/Postgres/Neo4j — you embed them in your product. Gnosem is more like Dropbox — you point every device at it and they share state. Neither replaces the other. If you're building an app that needs its own private memory graph, run one of the libraries. If you want cross-vendor memory that follows you across every MCP client you touch, use Gnosem.

You can also do both. Nothing prevents an app built on mem0 from also exposing an MCP endpoint that reads that mem0 store, or from talking to Gnosem in addition to its own private memory. The layers compose.

Try it

Sign up at gnosem.dev. Free tier requires no credit card. Add the returned API key to your MCP client of choice — the config is a five-line JSON block per client. See How to add persistent memory to Claude Code for a concrete walkthrough with Claude Code, or the landing page for the other clients. Then try switching between clients mid-project. That's the demo.