mem9: a shared memory service for coding agents, with plugins for eight runtimes

One memory layer instead of a notebook per project

The problem mem9 describes is specific: your agents forget everything between sessions. Restart a chat, switch laptops, or come back to a project after a week, and the context that mattered is gone, so you end up keeping local notebooks and one-off prompt files that nothing else can read.

The README puts four capabilities in a table. Persistent memory across sessions and machines, so context survives restarts and device changes. Shared memory across agents and workflow platforms, so OpenClaw, Hermes Agent, Claude Code, OpenCode, Codex, DeepSeek Harness, Dify apps and custom clients recall the same facts. Stateless integrations, where the runtime plugins stay thin because storage, search, ingest and policy live in the server. And hybrid recall with a visual dashboard, combining semantic and keyword search with a way to inspect what was stored.

The stateless point is the architectural decision. A plugin that calls an API and keeps no state is replaceable, upgradeable and testable in isolation, which is why the same plugin shape works across eight runtimes with different extension mechanisms. The trade is that the server becomes the component you have to trust and operate.

The tree shows how wide that surface has grown: separate directories for `claude-plugin/`, `codex-plugin/`, `opencode-plugin/`, `openclaw-plugin/`, `dsh-plugin/` and `skills/`, plus `server/`, `cli/`, `dashboard/`, `benchmark/`, `e2e/`, `docs/` and `site/`.

The server is Go even though the repository is filed as TypeScript

This is worth pausing on, because it changes how you install it. The repository language is TypeScript, which matches the plugin directories, but the `Makefile` at the root builds a Go binary named `mnemo-server` from `server/`, and the server documentation refers to starting that binary rather than running a Node process.

The build targets in the Makefile are plain:

cd server && CGO_ENABLED=0 go build -o ./bin/mnemo-server ./cmd/mnemo-server

There is also a `build-linux` target that sets `GOOS=linux` and `GOARCH=amd64` for the container image, a `vet` target running `go vet ./...`, a `test` target using `go test -race -count=1 ./...`, a coverage target writing to `coverage/`, and an integration target gated behind the `integration` build tag and pointed at `./internal/repository/tidb/`.

The presence of `test-integration` scoped to `internal/repository/tidb/` is a useful signal about where the risk sits in this codebase: the database layer, not the HTTP surface. The race detector on every test run and the `-count=1` flag, which disables caching, both point to a project that takes concurrent correctness seriously.

The README badges include a Go Report Card link aimed at `mem9-ai/mem9/server`, which corroborates that the server component is the Go one.

Hosted or self-hosted, the API contract is supposed to be identical

The quick start asks you to pick an endpoint first. The hosted API is `https://api.mem9.ai`. For self-hosting you apply the matching control-plane schema and start the server yourself:

cd server
MNEMO_DSN="user:pass@tcp(host:4000)/mnemos?parseTime=true" go run ./cmd/mnemo-server

Credentials are set the same way in both cases, with `MEM9_API_URL` and `MEM9_API_KEY` pointing at either the hosted endpoint or `http://localhost:8080` for a local server.

The README's claim to check is that moving from hosted to self-hosted is a base URL and credential change rather than a plugin rewrite, because the hosted service runs the same server model this repository contains. That is a testable claim and the repo gives you the pieces to test it, since the self-hosted path and the hosted path expose the same endpoints.

The storage story is TiDB. The hosted path is described as running on TiDB Cloud Starter, with the value of that choice spelled out: instant provisioning, native vector search, full-text search, server-side auto-embedding, hybrid search, and MySQL-compatible operational semantics. Auto-embedding on the server side is the detail that matters most to an integrator, because it means a client does not have to own an embedding model to get semantic recall.

The `MNEMO_DSN` value in the example is a MySQL-style connection string with a TCP address on port 4000 and `parseTime=true`, which is what TiDB speaks.

Two API generations coexist, distinguished by a header

The API reference introduces an `X-Mnemo-Agent-Id` header to set on authenticated memory, import and session-message requests. The purpose is attribution: when several runtimes write and recall inside the same space, the server needs to know which agent instance is responsible. The README notes this works on both the tenant-path `v1alpha1` routes and the `v1alpha2` API-key routes.

Having two versioned route families in a project with no releases is unusual and tells you something. The tenant-path form appears to be the older shape, where a path segment identifies the tenant, and `v1alpha2` is the API-key form. The provisioning table shows `POST /v1alpha1/mem9s` as a TiDB auto-provision endpoint that is enabled by default on `tidb` when a provisioner is configured, and mentions TiDB Zero for local development. So the newer route family coexists with the older one rather than replacing it, which is what you would expect from something still in alpha.

Every supported integration is described as exposing the same core flow: store, search, get, update and delete against the server API. That uniformity is the product. A memory system is only useful if a fact recalled by one agent is the same fact another agent gets back, and that requires the storage and retrieval behaviour to live in one place rather than in eight plugin implementations.

The README also describes per-space authorization for Dify, with both single-space and multi-space options, which is the sort of detail that only becomes urgent once more than one team shares a deployment.

What the repository does not settle

The documentation is strongest at the integration surface and thinnest at the data surface. Every plugin has a linked guide, the API routes are tabulated, and the hosted versus self-hosted distinction is explained clearly. What is not explained is what ends up in memory.

There is no documented server-side policy for what gets stored. Smart ingest appears in the README only as a DeepSeek Harness capability, described as a native bundle with recall, smart ingest and memory tools, which places the filtering decision in the plugin rather than the server. For a system that receives raw session messages, that leaves the most consequential design question to the integrator.

There is also no release history at all. The repository records a last push on 2026-09-16 and the default branch is `main`, with Apache-2.0 licensing and a `LICENSE` file present. A project with no tags gives you no way to pin a version or to see what changed between two points, which for infrastructure dependencies is a real operational gap.

The rest of the tree suggests where the project is going. `benchmark/` and `e2e/` imply performance and integration suites, `dashboard/` is the visual inspection surface the README promises, `cli/` is a client, and `site/` holds the documentation website. `meta.json` and `AGENTS.md` and `CLAUDE.md` at the root suggest the repository is itself managed with agent tooling, which fits a project whose subject is agent memory.

For a reader deciding whether to adopt this, the honest summary is that the integration story is well documented and the memory-quality story is not.

Editorial conclusion

mem9's bet is that agent memory should be a service with one API rather than a file in each repository, and the plugin list is the evidence that this is the direction agent tooling is moving. The hosted path is genuinely the easier one, since the same API contract serves both and moving is a base URL change, but a self-hosted install means a TiDB or PostgreSQL-compatible database and a Go binary built from `server/`, not a Node package, which contradicts the TypeScript label on the repository. Two things to weigh before adopting it. First, memory is only as good as what gets written into it, and the project offers smart ingest as a DeepSeek Harness feature rather than a documented server-side policy. Second, agent memory contains whatever your sessions contain, so the storage decision carries the same sensitivity as a database backup. Read the provisioning section for the `v1alpha1` and `v1alpha2` route split, then start from `claude-plugin/README.md`, which is the most concrete of the integration guides.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. mem9-ai/mem9 on GitHub
4. README