marm-memory: a local SQLite memory server your coding agents connect to over MCP

The problem marm-memory targets: context that dies with the chat window

Coding agents keep their working context inside a session. Close the session, switch from Claude Code to Codex, or open the same repository in Cursor, and the decisions, error fixes and research notes from the previous conversation are gone. The README frames this bluntly: "Your AI forgets everything. MARM Memory doesn't." The intended user is a developer or researcher who works across more than one MCP-capable client and wants the accumulated project history to be addressable from any of them. The project's own summary of the value is narrow and specific: switch clients "without losing the context already gathered." That is a different goal from giving one agent a longer context window. It is about persistence that outlives a single tool, stored locally rather than in a vendor's account.

Three stores in one SQLite file: memory, code graph, concept graph

The README describes the system as three things brought together, exposed as 14 MCP tools over both HTTP and STDIO. Core Memory is 7 tools covering conversations, notes, notebook entries and summaries. Code Graph is 5 tools that map a repository so agents can find symbols and follow code paths "without rereading it all." Concept Graph is 2 tools that connect people, decisions, errors and ideas drawn from stored memories, with links back to code where available. The concept graph builds itself as memories are stored; the code graph is created per repository when you index it, and according to the README it "keeps itself current as you work." These are separate graphs, not one merged structure: indexing a repository produces an independent Code Graph that you can browse in the Console under Knowledge Graph then Code Explorer, even before you have stored a single memory. The layered table in the README names the retrieval machinery: an FTS filter, semantic re-rank, a bounded semantic fallback, auto-classification, write-time consolidation and compaction candidates. The stated purpose of that last group is to stop recall degrading as duplicates pile up, which is the honest failure mode of any append-only memory store.

The scale layer is the part worth reading closely

Under the heading Scale layer, the README lists SQLite WAL mode, connection pooling, a serialized write queue and HTTP rate-limit presets. Those four items together tell you what the authors expect to go wrong: concurrent writers. SQLite in WAL mode still permits only one writer at a time, so a serialized write queue is the standard mitigation, and the existence of swarm and swarm-max profiles confirms that multi-agent write bursts are a supported scenario rather than an edge case. The README does not publish latency or throughput figures in the material available here, so treat any claim about how many agents a single server can absorb as unverified until you measure it on your own hardware. What you can verify is the shape of the design: one local server process, one SQLite database, presets that trade throughput against how much concurrent access you allow.

Install and wiring: pip, init flags, and the two transports

Installation is two commands from the README. First pip install marm-mcp-server, then marm-memory init --g-claude --g-codex --g-gemini to initialize with agent profiles. The README notes two further profile flags, --g-qwen and --g-kiro, and states that running init without flags installs into the current project folder instead of your home directory. From there the README offers an agent-driven path: tell your agent "Use the marm-init skill to set up MARM," and it handles Python or Docker, HTTP or STDIO, keys and client configs interactively. If you prefer to wire it yourself, the README gives a table. For HTTP, start the server with marm-memory start and connect with "agent" mcp add --transport http marm-memory http://localhost:8001/mcp. For STDIO, run marm-mcp-stdio as the server and register it with "agent" mcp add --transport stdio marm-memory-stdio marm-mcp-stdio. Codex uses a different form: codex mcp add marm-memory --url http://localhost:8001/mcp. Swarm users start with marm-memory start --profile swarm or --profile swarm-max, and a trusted private lab uses --profile trusted. Lifecycle commands are status, logs --follow, restart and stop. marm-memory fast-start-http launches the runtime, opens the console and loads it in the browser, and --no-console or --no-browser suppress those steps.

Where this design costs you: a daemon, a database, and a default of no auth

The HTTP transport listens on localhost:8001 and the README's client examples point at that URL with no token in the command. The trusted profile exists for a "Trusted private lab/server," which implies the other profiles are not hardened for shared networks. If you bind the server to anything other than loopback, you have to reason about who can reach it yourself; the README material here does not document an authentication scheme. The second cost is operational. A background daemon with logs, restart and stop commands is a process someone must own, and the memory itself is a SQLite file whose durability, backup and deletion story you inherit. A team that only wants one agent to remember its own conversations is paying for a service it will not use, and STDIO mode exists precisely for people who want to avoid the daemon but then lose the shared-memory benefit across clients. The third limitation is scope: the code graph is built by indexing a repository, so it reflects the state of the index, not the state of your working tree at the instant an agent asks. The README says it keeps itself current as you work; how promptly that happens is not specified in the material available.

How it differs from a hosted memory API and from plain RAG over a vector store

The obvious alternative is a hosted agent-memory service, which handles persistence, scaling and backups for you and charges per stored or retrieved unit. The difference is not only cost: a hosted service means your session history, notes and error write-ups leave the machine. marm-memory's whole position is that the SQLite file stays local, which is the reason the README uses the phrase "zero-cloud." A second alternative is wiring your own retrieval: embed your documents, drop them in a vector store, and expose a search tool to each agent. That gives you one flat similarity index and nothing else. marm-memory separates the concerns instead, with an FTS filter feeding a semantic re-rank and a bounded fallback, plus a concept graph that links entities across memories and back to code. Whether that layered retrieval beats a plain vector index on your data is an empirical question the README does not answer with numbers. The structural difference is that you get typed stores (sessions, notebooks, summaries, code symbols, concepts) rather than one undifferentiated pile of chunks, and you get them behind a single MCP endpoint that several clients can share.

Licence, maintenance and what the release cadence implies

The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirement to preserve notices and state changes. That is a permissive licence, and nothing here constitutes legal advice; if you redistribute a modified server, read the licence text rather than this summary. Maintenance looks active in the material provided: v2.45.0, v2.46.2 and v2.47.0 landed within roughly two weeks in late August and early September 2026, and the README itself advertises v2.48.0, one version ahead of the most recent release listed. That gap is worth noting: the README describes a version that the release list does not yet show, so pin the version you install rather than assuming the README and the package match. The upgrade cost is the part you cannot see from here. The README documents a SQLite schema behind 14 tools but does not describe a migration policy, so before adopting, check whether the release notes for the versions you skip mention schema changes. Python 3.10 or newer is required, which rules out older interpreter pins.

Editorial conclusion

Adopt marm-memory if you regularly move between Claude Code, Codex, Gemini or Cursor on the same repositories and want that history to survive the switch without sending it to a hosted service. Do not adopt it if you want a single agent's memory to live inside that agent's own session store, or if nobody on the team will own a background daemon and its SQLite file. Before committing, verify three things yourself: that your Python is 3.10 or newer, that the machine running the daemon is the machine that holds the database, and that the profile you pick (swarm, swarm-max, trusted) matches how many agents will write concurrently, because the README's scale layer exists precisely because concurrent writes are the pressure point.

Official sources

1. License: Apache-2.0
2. Lyellr88/marm-memory on GitHub
3. Project website
4. README
5. Releases