If you run more than one coding agent — Claude Code in the terminal, Codex in CI, Cursor in the editor — you've hit the wall: each one starts every session amnesiac. Nothing you told Claude Code yesterday is available to Codex today. A new category of open-source tool exists to fix exactly that: one shared memory that every agent reads and writes. Four have reached real adoption by August 2026 — memsearch, agentmemory, Memorix, and Memmy — and the fastest way to choose wrong is to compare them on recall.

Here's the one-line answer, citable up front: **they don't disagree on whether they remember — they disagree on what your memory *is***. memsearch makes it a folder of Markdown files you own. agentmemory makes it a tool your agents call over MCP. Memorix makes it a local service tied to your repo. Memmy makes it a second-brain agent. Pick the shape, and the rest follows — the same way operational shape, not speed, separates sqlite-vec, LanceDB, and Qdrant inside a single agent.

The decision in one screen#

All four are local-first, open-source, and free to start — no cloud account required. Now the detail.

memsearch: memory as files you own#

memsearch is the most conservative design, and that's its selling point. Markdown files are the canonical store — human-readable, editable, and version-controllable — and a Milvus vector index is treated explicitly as "a shadow index: a derived, rebuildable cache." If the index corrupts or you switch machines, you re-index from the Markdown and lose nothing.

uv tool install memsearch          # global CLI
memsearch config init              # interactive setup
memsearch index ./memory/          # build the vector index from your Markdown
memsearch search "auth flow decisions"

It's the only one of the four not built around MCP — you drive it from a CLI and Python API and wire it into agents via project rules or a small wrapper. It's also the one with a real organization behind it: Zilliz, the company behind Milvus (~2.4k stars, MIT). Reach for memsearch when you want your agent's memory to be an artifact you own and audit as plain text, not an opaque database.

agentmemory: memory as a tool your agents call#

agentmemory is the category leader — ~26k stars, far more than the other three combined — and it earns that by being the most batteries-included. It's MCP-first: it ships 54 MCP tools, 6 resources, and 15 skills, runs standalone via npx @agentmemory/mcp, and lists 40+ compatible agents (Claude Code, Codex CLI, Copilot CLI, Cursor, Cline, Aider, Gemini CLI, and more). Storage is a local SQLite database plus an in-process vector index — no external vector service to run.

npm install -g @agentmemory/agentmemory
agentmemory                        # or: npx @agentmemory/agentmemory

Its README makes the loudest performance claim of the group: 95.2% retrieval R@5 on LongMemEval-S at ~92% fewer tokens than LLM-summarized memory. Read that as a vendor number — self-reported on the maintainer's harness, with no independent replication yet. Memory benchmarks are unusually easy to misread; let it break a tie, not make the decision. Reach for agentmemory when you want maximum agent coverage and an MCP surface that works the day you install it.

Memorix: memory as a service tied to the repo#

Memorix splits the difference between "files" and "tool." It's local-first with SQLite as the canonical store and Orama for full-text search, but it anchors every memory to your git project identity — so the memory belongs to the repository, not to a chat or a machine. It exposes that memory four ways: MCP, CLI, SDK, and an HTTP service with a dashboard at localhost:3211.

npm install -g memorix
memorix setup --agent claude-code --global
memorix background start            # HTTP service + dashboard

The pitch is that memory "survives new chats, IDE switches, terminal sessions, and handoffs" while living under the git project. Reach for Memorix when you juggle many repos and want each project's context to travel with the repo, with one local daemon several agents can hit at once (~600 stars, Apache-2.0).

Memmy: memory as an agent#

Memmy is the outlier. It's not just a memory layer — it's a local memory hub that is also an agent runtime, built on a MemOS-powered engine that "automatically collects, understands, and structures your knowledge." It runs a Memory Service on a local port, ships a desktop app and a CLI, supports MCP and custom Skills, and — uniquely — can import your existing history from Cursor, Claude Code, Codex, OpenClaw, and Hermes.

memmy onboard
memmy serve                         # API mode

That extra surface is the trade: Memmy is a heavier thing to adopt than a memory library, because it wants to be your standing second brain, not a dependency. Reach for it when that's what you actually want (~550 stars, MIT, requires Node ≥22).

The pattern, not the pick#

Notice what the four have in common: local-first storage, retrieval by similarity, and the same job — end the amnesia between agents. What separates them is where the memory lives and what it looks like when you go find it:

Since all four are early and pre-1.0, the durable questions are the boring ones: Can I read my memory without their software? Can I rebuild it if the index dies? Does it speak a standard my agents already speak? memsearch wins the first (it's just Markdown), agentmemory wins the third (MCP-native, biggest ecosystem), and both keep their real data in a store you can back up. Start there, back up the underlying folder or SQLite file, and you can change your mind later — which, this early in a new category, is the feature that matters most.

For the single-agent version of this decision, see sqlite-vec vs LanceDB vs Qdrant; for the managed, hosted layer above these, see Mem0 vs Zep vs Letta; and before you trust any of their numbers, read why agent memory rots in production.