Questions about open source AI memory

mem-port is an open source AI memory server for AI agents. It runs as one local MCP daemon holding a single knowledge graph of entities, memories, episodes, skills, and architectural decision records.

Every MCP client you point at it — Claude Code, Cursor, Windsurf, Claude Desktop — reads and writes that same AI memory instead of keeping its own siloed copy.

The agent memory GitHub repo is rsl-innovation/mem-port. Everything in that agent memory GitHub project is MIT licensed — the daemon, the MCP tool surface, and the portable export format — so you can read it, fork it, or self-host it without asking anyone.

Yes. mem-port is open source AI memory under the MIT license, and self-hosting is the only way it runs: by default the daemon binds to 127.0.0.1 and keeps the graph in an embedded SurrealDB store on local disk.

There is no hosted tier, and no account to create in order to run it on your own machine. Nothing leaves it unless you deploy mem-port somewhere else yourself, or export a bundle and move it.

Both, and the difference is where it binds. On 127.0.0.1 there are no accounts at all: the operating system is already the boundary, so nothing is asked of you. That has not changed — the same npx command, no auth, no external database, and the same 19 tools.

Bind any other interface and that boundary is gone, so authentication switches on with the exposure. An admin portal at /admin then manages workspaces (a workspace is one isolated graph, and its name is what clients send as library-id), users, API keys with rotation, and per-workspace grants. It serves its own documentation, and includes a read-only graph explorer per workspace — the quickest way to check whether a newly connected client is actually writing anything. Clients send an Authorization: Bearer header alongside library-id, and nothing else about them changes.

Being an admin is deliberately not data access. Admins decide who may reach what, which is a different power from reading it, so an admin who wants a workspace has to grant it to themselves. A container image, a Compose stack, and Cloud Run manifests ship under deployments/, all defaulting to closed.

No. Most agent memory stacks ask you to stand up a vector database and a graph database side by side before you save a single fact. mem-port uses one embedded SurrealDB instance that does graph relations and vector search in the same process, so the entire AI memory layer starts with one npx command.

Postgres is supported as an alternative, not a requirement. There is a second storage driver — Postgres with pgvector, selected by a postgres:// database URL, with the pg package as an optional dependency you install only if you want it. It exists for deployments where an embedded file on a local disk is the wrong thing, and the two drivers are interchangeable: one test seeds the same fixture through both and asserts every read tool returns byte-identical output. On your own machine, the default still stands and still needs nothing installed.

No. Semantic search over your AI memory runs on a local ONNX embedding model (Xenova/all-MiniLM-L6-v2) that downloads once and is then cached on disk. No OpenAI key, no embedding bill, and no memory content sent to a third party.

An ADR log is a record of the consequential technical choices whose reasoning matters months later. Each entry gets a sequential number in its library (ADR-0001, ADR-0002) and holds the four things a decision record needs: the context that forced the decision, the decision itself, its consequences, and the alternatives that lost.

This is deliberately not the same as saving a memory of type decision. A memory records that something was decided. An ADR keeps the problem framing and the rejected options, which is what you actually need when someone proposes a rejected option again a year later. search_adrs matches against title, context, and decision, so "why aren't we using Postgres?" finds the record even when it shares no words with it.

Decisions get reversed, so ADRs carry a lifecycle (proposed, accepted, then superseded or deprecated) and a supersede chain. Recording a newer decision with supersedes marks the older one superseded and links the two, so the log stays readable from either end instead of accumulating contradictory records.

Yes, in hosts that support MCP Apps. The nine read tools — search_memory, list_episodes, search_skills, list_skills, get_skill, search_adrs, list_adrs, get_adr, get_entity — each declare a UI resource in their tool definition, pointing at one ui://mem-port/results.html page. The host fetches that page, renders it in a sandboxed iframe, and pushes the tool result into it, so the card you see and the JSON the model reads come from the same description and can't disagree. Lists come back as result cards; get_ tools come back as a detail view.

Results paginate five at a time with a running tally, and the panel reads the host's own style variables and fonts, so its colors and typeface come from the client rather than an approximation of it. That is the difference between a panel that reads as part of the conversation and one that reads as an embedded widget.

Claude Desktop, VS Code Copilot, Cursor and Goose are MCP Apps hosts. Claude Code is not, so results stay as text there. The text block is unchanged and always first, so a host that doesn't render MCP Apps behaves exactly as it did.

It's on by default: turn it off for one client with an mcp-apps: 0 header next to library-id, or for every client at once by starting the daemon with MCP_APPS=0 mem-port serve. An explicit header wins over the environment in both directions, so a single client can opt back in on a daemon that has it off.

mem0 is a universal AI memory layer shipped as an SDK, a self-hosted Docker stack, and a managed cloud; its defaults call an LLM to extract facts, and it keeps vector storage separate from graph storage.

mem-port is deliberately narrower: one local process, no API key, no external database, and cross-machine portability as its namesake feature. Both are open source, so compare the two agent memory GitHub projects side by side before you commit.

Hermes Agent is a full self-improving agent from Nous Research that keeps its own agent memory in SQLite and supports pluggable memory providers. mem-port is not an agent at all — it is the memory your existing agents share.

If you already run Claude Code and Cursor every day, mem-port gives them one AI memory without asking you to migrate to a new agent.

Any MCP client that speaks Streamable HTTP with custom headers. Claude Code (both the CLI and the VS Code extension), Cursor, and Windsurf connect directly; stdio-only clients bridge through mcp-remote.

Clients sending the same library-id header share one AI memory graph, and different library-ids are fully isolated from each other.

Yes — that's the thumb-drive part of the name. export_library writes an entire library to one portable .memport.json bundle, and import_library merges or overwrites it on another machine.

Your AI memory travels with you instead of living inside one vendor's tool.

A memory server. mem-port makes no model calls and takes no autonomous actions on its own — your memory agent, whichever copilot that happens to be, does the thinking and uses mem-port's 19 MCP tools to save and search.

That separation is why a single mem-port library can back several different agents at the same time.

Nothing. It is free, MIT-licensed open source AI memory with no paid tier, no usage metering, and no account. The only running cost of an agent memory GitHub project you host yourself is the disk the graph sits on.

Open an issue on the agent memory GitHub tracker, or send a pull request. The agent memory GitHub repo takes contributions to the daemon, the MCP tools, and the documentation alike.