The short answer
- Claude Projects gives one assistant a curated, per-project knowledge base, with memory deliberately isolated inside each project. It is the better choice for a Claude-only team that wants zero operations.
- MemBrain is a self-hosted gateway that every AI tool talks through, holding one governed knowledge layer with an explicit path for knowledge to be promoted from private to team-shared. It is the better choice when more than one model or tool is in play, or when the data cannot leave your infrastructure.
- They are not mutually exclusive. Plenty of teams should run both — see using both.
Side by side
| Claude Projects | MemBrain | |
|---|---|---|
| Memory scope | A separate memory space per project. What Claude learns in one project does not carry into another — an intentional boundary. | Project-scoped by default, with an explicit promotion path from private to team-shared knowledge. |
| Sharing model | Person-to-project. Team and Enterprise members can be granted "Can view" or "Can edit" on a project. No supported way to share one knowledge base across projects. | Person-to-project and entry-level promotion: a human approves, then the owner explicitly shares to the team, with attribution attached. |
| Models covered | Claude. | Anthropic, OpenAI, Ollama, Claude CLI, and 100+ models via LiteLLM, behind one interface. |
| Clients covered | Claude apps, Claude Code, Cowork. | Full coverage — passive capture and automatic injection — for anything that can point at a proxy: Claude Code, Cursor, SDKs, CI scripts. Claude Desktop connects at the tool level over MCP. See the coverage note below. |
| How knowledge gets in | You upload files to the project knowledge base; conversations are also summarized into memory automatically. | Captured passively at the gateway from work already happening, then distilled by a budgeted daily reflection pass into a review queue. |
| Updating a document | Remove and re-upload — there is no in-place update. A doc shared across several projects is revised once per copy. | One entry, updated in place, injected everywhere it is permitted. |
| Retrieval | Loaded into the context window, with retrieval-augmented generation engaging automatically for large knowledge bases on paid plans. | pgvector semantic search, retrieved and injected per request. |
| Where the data lives | Anthropic's cloud. | Your Postgres, on your infrastructure. Nothing leaves unless you route it out. |
| Review before sharing | You can view and edit what Claude has remembered; incognito chats skip saving entirely. | Two gates. Entries land pending and private; a human approves, then the owner separately decides to share. Rejections are tombstoned. |
| Record of what entered a prompt | The memory summary is user-viewable and editable. | Tamper-evident hash-chained audit log, Prometheus metrics, GDPR export and right-to-erasure. |
| PII controls | Platform-level enterprise data controls. | Per-request scanning: 25+ patterns, re-scanned on injection, fail-closed if the scanner errors. Optional ML NER. |
| Setup | Create a project. No infrastructure. | Docker Compose: gateway, Postgres, Redis. Real operational work. |
| Cost | Included with Pro, Max, Team, and Enterprise plans. | Apache-2.0 and free to self-host; you pay for the infrastructure you run. Some add-ons are Enterprise-licensed. |
Claude Projects behaviour above reflects Anthropic's published documentation as of August 2026 and may change — see what are projects, project visibility and sharing, and bringing memory to teams. If something here has gone out of date or reads unfairly, tell us and we'll correct it.
Coverage note: not every surface is equal
"Works with every tool" is the kind of claim that deserves its caveats printed next to it rather than discovered later. MemBrain reaches three tiers of surface, and they are genuinely different:
- Full coverage — anything you can point at a proxy. Claude Code, Cursor, SDK calls, CI scripts. Knowledge is captured passively from work as it happens and injected automatically into requests. This is the tier the product is built around.
- Tool-level coverage — Claude Desktop, over MCP. The gateway exposes a built-in
team-brainMCP server, so Claude Desktop can search team knowledge, save to it, and recall your own episodes. But these are tools the model chooses to call: there is no passive capture of the conversation and no automatic injection into every message. Useful, and weaker than the proxy path. - Detection only — browser AI use. The transparent network proxy can show you that someone used a browser-based assistant, which is a Visibility and Detection story. It does not give that session your team's memory.
The honest edge case is claude.ai in the browser. Custom connectors are the only route in, and Anthropic's clients connect to a remote MCP server from Anthropic's cloud infrastructure, not from your machine — so a gateway on localhost or behind a VPN cannot be reached. Covering that surface means exposing your gateway publicly over HTTPS with OAuth or request-header auth, which is a deliberate trade against the self-hosting posture that made you choose MemBrain. For many teams the right answer is to leave browser Claude uncovered and keep the brain where the work happens.
Which produces an asymmetry worth stating plainly: the surface where Claude Projects is strongest is the surface MemBrain reaches least well. If your team's knowledge work happens in the claude.ai web app, Projects is a better fit than anything we can offer there. If it happens in editors, terminals, and pipelines, the proxy sees all of it and Projects sees none of it.
Which one fits
Claude Projects is the better choice when…
- Claude is the only model you use, and you expect that to stay true.
- Nobody wants to run infrastructure. This is a real advantage and no architecture argument dissolves it.
- Your knowledge is a curated document set — contracts, specs, style guides — rather than a byproduct of daily work. Retrieval over documents a human chose is more precise than distillation from traffic nobody curated.
- Non-technical teammates need it to just work, today, with no rollout.
- Isolation is the whole point. If per-client separation is a contractual obligation, a boundary with no door is a feature.
MemBrain is the better choice when…
- More than one tool or model is in play. Memory inside one vendor's product can't reach the editor, the CLI, or the local model.
- The data can't leave your infrastructure. Self-hosted, in your own Postgres.
- Knowledge should accumulate from work, not from remembering to upload it.
- You need to prove what context entered a request — an auditable chain, not a summary you can read.
- The same knowledge is needed in many projects and you'd rather maintain one entry than six drifting copies.
Using both
The honest recommendation for most teams is not a migration. Keep Projects for what it is good at — a curated, per-engagement document set that one assistant reasons over, with a wall around it. Add MemBrain underneath for the cross-cutting layer: the conventions, decisions, and hard-won constraints that should follow the team across every tool, governed by a share gate and an audit trail.
The dividing line that works in practice: if it belongs to one engagement, it belongs in a project. If it belongs to the organization, it belongs somewhere every tool can reach it.
The longer argument for why that second thing needs a promotion path rather than just a shared folder is in Walls Without Doors.
Try the cross-tool test
Point Claude Code and Cursor at the same MemBrain instance. Learn something in one; ask about it in the other. Self-hosted, Apache-2.0, running in about five minutes.
Get started on GitHub →