Persistent Memory for AI Agents.
Your agents forget everything between sessions. mem9 fixes that with persistent memory across sessions and machines, shared memory for multi-agent workflows, and hybrid recall with a visual dashboard.

For OpenClaw and ClawHub installs, start here: mem9.ai/openclaw-memory
Hermes Agent, Claude Code, OpenCode, Codex, and Dify guides are below.

1. Choose your mem9 endpoint.

   • Hosted API: https://api.mem9.ai

   • Self-hosted: apply the matching control-plane schema, then start mnemo-server:

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

     See Self-Hosting for backend-specific setup details, and API Reference for provisioning.

2. Pick your integration guide.

   • OpenClaw / ClawHub
   • Hermes Agent
   • Claude Code
   • OpenCode
   • Codex
   • Dify
   • Any HTTP client / custom runtime

3. Set your credentials.

   # Hosted API
   export MEM9_API_URL="https://api.mem9.ai"
   export MEM9_API_KEY="<mem9-api-key>"
   
   # Self-hosted
   export MEM9_API_URL="http://localhost:8080"
   export MEM9_API_KEY="<mem9-api-key>"

   For self-hosted deployments, use your server URL and the mem9 API key returned or configured by your provisioning flow.

mem9 gives coding agents one shared memory layer instead of separate local notebooks and one-off prompt files.

All supported runtimes and platform integrations expose the same core memory flow: store, search, get, update, and delete against the mem9 server API.

The hosted mem9 API is the fastest way to put persistent memory behind an agent fleet while keeping the option to self-host later.

Under the hood, the hosted mem9 API runs the same mem9 server model surfaced in this repository, with TiDB Cloud Starter providing managed provisioning, native vector search, full-text search, server-side auto-embedding, hybrid search, and MySQL-compatible storage semantics.

Set X-Mnemo-Agent-Id on authenticated memory, import, and session-message requests when you want the server to distinguish which runtime or agent instance is writing and recalling memories inside the same mem9 space. This works on both the tenant-path v1alpha1 routes and the v1alpha2 API-key routes.

Use this endpoint when you want mem9 to auto-provision a new TiDB-backed space.

Prefer v1alpha2 for all new integrations. It uses X-API-Key and is the primary API surface for current runtimes.

Use these endpoints only when you need compatibility with older tenant-ID-in-path clients.

Before first start, apply the control-plane schema that matches your backend: server/schema.sql, server/schema_pg.sql, or server/schema_db9.sql.

mem9 server supports multiple storage backends. Set MNEMO_DB_BACKEND to tidb, postgres, or db9, point MNEMO_DSN at that backend, and the rest of the runtime contract stays the same for your agents. TiDB supports three tenant flows: TiDB Zero auto-provisioning is enabled by default on tidb; TiDB Cloud Pool auto-provisioning uses MNEMO_TIDB_ZERO_ENABLED=false with MNEMO_TIDBCLOUD_API_KEY and MNEMO_TIDBCLOUD_API_SECRET; manual bootstrap uses pre-existing tenants mode. postgres and db9 use the advanced manual-bootstrap path, which requires an active tenant row in the control-plane DB plus a live tenant database and schema behind it. In v1alpha2, X-API-Key resolves tenants by ID lookup.

make build
cd server
MNEMO_DSN="user:pass@tcp(host:4000)/mnemos?parseTime=true" ./bin/mnemo-server

For PostgreSQL or db9 deployments, export MNEMO_DB_BACKEND=postgres or MNEMO_DB_BACKEND=db9 before launching the server.

make docker tags the image as ${REGISTRY}/mnemo-server:${COMMIT}. This local example builds local/mnemo-server:dev:

make docker REGISTRY=local COMMIT=dev
docker run -e MNEMO_DSN="..." -e MNEMO_DB_BACKEND="tidb" -p 8080:8080 local/mnemo-server:dev

Minimal runtime config is MNEMO_DSN. Everything else is optional or only applies to specific deployment modes.

The MEM9_SOURCE_TURN_* variables control how many source turn conversations are attached to search results as contextual decorations.

These variables control automatic spend-limit increases for TiDB Cloud clusters that hit their cap. The feature progressively raises the limit up to MNEMO_AUTO_SPEND_LIMIT_MAX with a configurable cooldown between increments.

These are the supported rollout variables for the server-side metering writer. The writer is initialized at server startup, but this round does not wire any Record() call sites yet, so no usage events are emitted until caller hooks are added.

The public env surface is intentionally small for now. Metering location is configured as a single destination URL. Supported schemes are:

• s3://<bucket>/<prefix>/ for compressed JSON batches in S3
• http://... or https://... for JSON batch webhooks

These are only relevant when MNEMO_ENCRYPT_TYPE=kms. The server uses the AWS SDK default config chain; the common environment-based inputs referenced in code are:

See CONTRIBUTING.md for development setup and guidelines.

Apache-2.0

_{Built on TiDB Cloud Starter for shared memory, vector search, and managed cloud provisioning.}