Generated banner for mnemory
Generated logo for mnemory

mnemory

Memory server

Created by Filip Pytloun

Published in fpytloun/mnemory. Publisher page

283 GitHub stars

What it is

A self-hosted, secure, feature-rich memory system for AI agents and assistants. Provides intelligent fact extraction and deduplication, with an artifact store for detailed content.
— the description by Filip Pytloun

AutoGineer overview, from the brain’s own files

mnemory is a self-hosted memory system designed to provide AI agents and assistants with persistent, long-term memory. It functions as an MCP server, allowing it to integrate seamlessly with various AI clients like Claude Code, Cursor, and Open WebUI. The system uses a two-tier architecture: a vector store for fast, semantically searchable summaries and an artifact store for detailed content. It features an intelligent pipeline that performs fact extraction, deduplication, and contradiction resolution in a single LLM call. mnemory also includes a built-in management UI for monitoring and memory maintenance, along with health checks to ensure data quality. It is built for production environments with support for Qdrant, S3/MinIO, and Prometheus monitoring.

How it works

Memory model: Vector store

AutoGineer overview, from the brain’s own files

mnemory operates by intercepting information shared during agent conversations. It uses an LLM pipeline to extract facts, classify them by importance and category, and resolve contradictions against existing data. These facts are stored in a vector database for semantic search, while detailed artifacts are kept in a separate store. During interaction, the system retrieves relevant memories based on the current context and user queries. It also manages memory lifecycles using configurable time-to-live (TTL) settings and provides a health-checking mechanism to detect and fix data inconsistencies.

Folders
FolderRoleFiles
.githubagent-config4
docsdocs31
teststests42
benchmarksfolder16
filesfolder8
integrationsfolder40
mnemoryfolder59

The agent reads

The agent writes

Requirements

Runtimes: Python >=3.11

Databases: Qdrant, Redis

API keys (by name): OPENAI_API_KEY

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Google Antigravity, Kiro, OpenCode, Amp, Roo Code, Cline, JetBrains Junie, Devin (ex-Windsurf)

Set it up

  1. Not scanned by AutoGineerIts dependencies are installed by pip or uv when you run it and were not scanned by AutoGineer (9 declared). https://pypi.org/project/mnemory/
  2. Created by Filip Pytloun. Published in fpytloun/mnemory. Licence: Apache License 2.0.

Usage

AutoGineer overview, from the brain’s own files

  • Connects to AI agents via the Model Context Protocol (MCP).
  • Provides a REST API for custom integrations and plugin development.
  • Includes a web-based dashboard for memory management and visualization.
  • Supports automatic recall and memory persistence across sessions.
  • Offers built-in health checks and maintenance tools for memory quality.
  • Integrates with monitoring tools like Prometheus and Grafana.
“What did I decide last week about the database?”
The agent performs a temporal-aware semantic search across stored memories to retrieve the specific decision made.
“I drive a Skoda.”
The system extracts this fact and stores it; if a later statement says 'I bought a Tesla', it updates the record instead of creating a duplicate.

Documentation by Filip Pytloun

<p align="center"> <img src="files/banner.png" alt="mnemory banner" /> </p>

mnemory

Looking for a complete Agent OS? Meet Cognis — a cloud-native, self-hosted workspace where AI agents do real work. Bring together conversations, tools, workflows, and remote executors, with long-term memory powered by mnemory and guardrails provided by Intaris.

Deletion is intentionally best effort, not a verified-erasure or compliance guarantee. Normal deletion retracts and preserves history; explicit privacy erasure attempts physical cleanup. See deletion limits.

Give your AI agents persistent memory. mnemory is a self-hosted MCP server that adds personalization and long-term memory to any AI assistant — Claude Code, ChatGPT, Open WebUI, Cursor, or any MCP-compatible client.

Plug and play. Connect mnemory and your agent immediately starts remembering user preferences, facts, decisions, and context across conversations. No system prompt changes needed.

Self-hosted and secure. Your data stays on your infrastructure. No cloud dependencies, no third-party access to your memories.

Intelligent. Uses a unified LLM pipeline for fact extraction, deduplication, and contradiction resolution in a single call. Memories are semantically searchable, automatically categorized, and expire naturally when no longer relevant.

Features

  • Zero config — uvx mnemory, connect your MCP client, done. Works out of the box with any OpenAI-compatible API.

  • Intelligent extraction — A single LLM call extracts facts, classifies metadata, and deduplicates against existing memories.

  • Contradiction resolution — "I drive a Skoda" + later "I bought a Tesla" = automatic update, not a duplicate.

  • Two-tier memory — Fast searchable summaries in a vector store + detailed artifact storage (reports, code, research) retrieved on demand.

  • AI-powered search — Multi-query semantic search with temporal awareness. Ask "What did I decide last week about the database?" and it finds the right memories.

  • Memory health checks — Built-in three-phase consistency checker (fsck) detects duplicates, contradictions, quality issues, and prompt injection. Run manually or on a schedule with auto-fix.

  • 10+ client support — Claude Code, ChatGPT, Open WebUI, OpenClaw, Cursor, Windsurf, Cline, OpenCode, and more. Native plugins available for automatic recall/remember.

  • Built-in management UI — Dashboard, semantic search, memory browser with full CRUD, relationship graph visualization, and health check interface. No extra tools needed.

  • Production ready — Qdrant for vectors, S3/MinIO for artifacts, API key or Cognis JWT authentication, per-user isolation, Kubernetes-friendly stateless HTTP.

  • Secure by default — API key or Cognis JWT authentication with session-level identity binding, per-user memory isolation, anti-injection safeguards in extraction prompts.

  • REST API + MCP — Dual interface with the same backend. 16 MCP tools + full REST API with OpenAPI spec. Build plugins, integrations, or use directly.

  • Prometheus monitoring — Built-in /metrics endpoint with operation counters and memory gauges. Pre-built Grafana dashboard included.

Quick Start

mnemory needs an OpenAI-compatible API key for LLM and embeddings. It picks up OPENAI_API_KEY from your environment automatically.

uvx mnemory

If uvx reports No module named 'mcp.server.fastmcp', update uv. Older uv versions on Alpine can ignore mnemory's MCP v1 dependency constraint. Until you update uv, run:

uvx --with "mcp<2" mnemory

That's it. mnemory starts on http://localhost:8050/mcp, stores data in ~/.mnemory/.

Now connect your client — for Claude Code, add to your MCP config:

{
  "mcpServers": {
    "mnemory": {
      "type": "streamable-http",
      "url": "http://localhost:8050/mcp",
      "headers": {
        "X-Agent-Id": "claude-code"
      }
    }
  }
}

Start a new conversation. Memory works automatically.

Also available via Docker, pip, or production setup with Qdrant + S3. See the full quick start guide for more clients and options.

Screenshots

<p align="center"> <img src="files/screenshots/ui-dashboard.jpg" alt="Dashboard — memory totals, breakdowns, and operation counts" width="800" /> <br><em>Dashboard with memory breakdowns by type, category, and role</em> </p>

<p align="center"> <img src="files/screenshots/ui-search.jpg" alt="Search — semantic and AI-powered search with filters" width="800" /> <br><em>Semantic search and AI-powered find with filters</em> </p>

<p align="center"> <img src="files/screenshots/ui-graph.jpg" alt="Graph — D3.js force-directed memory relationship visualization" width="800" /> <br><em>Memory relationship graph visualization</em> </p>

See all screenshots and UI features including memory browser, health checks, and artifact management.

Supported Clients

mnemory works with any MCP-compatible client. Some clients also have dedicated plugins for automatic recall/remember.

ClientMCPPluginSetup Guide
Claude CodeYesYes (hooks)Guide
ChatGPTYes (MCP connector)--Guide
Claude DesktopYes--Guide
Hermes AgentYesYes (plugin)Guide
Open WebUIYesYes (filter)Guide
OpenCodeYesYes (plugin)Guide
OpenClawYesYes (plugin)Guide
CursorYes--Guide
WindsurfYes--Guide
ClineYes--Guide
Continue.devYes--Guide
Codex CLIYes--Guide

MCP = works via Model Context Protocol (LLM-driven tool calls). Plugin = dedicated integration with automatic recall/remember (no LLM tool-calling needed).

How It Works

Storing: You share information naturally. mnemory extracts individual facts, classifies them (type, category, importance), checks for duplicates and contradictions against existing memories, and stores them as searchable vectors — all in a single LLM call.

Searching: Ask a question and mnemory generates multiple search queries covering different angles and associations, runs them in parallel, and reranks results by relevance. Temporal-aware — "what did I decide last week?" just works.

Recalling: At conversation start, your agent loads pinned memories (core facts, preferences, identity) plus recent context. During conversation, relevant memories are found automatically based on what you're discussing.

Maintaining: Memories have configurable TTL — context expires in 7 days, episodic memories in 90. Frequently accessed memories stay alive (reinforcement). The built-in health checker detects and fixes duplicates, contradictions, and quality issues.

Learn more in the architecture docs.

Benchmark

Evaluated on the LoCoMo benchmark — 10 multi-session dialogues with 1540 QA questions across 4 categories:

Systemsingle_hopmulti_hoptemporalopen_domainOverall
mnemory63.153.174.878.273.2
mnemory (gpt-oss-120b)66.359.468.573.870.5
Memobase70.952.185.077.275.8
Mem0-Graph65.747.258.175.768.4
Mem067.151.255.572.966.9
Zep61.741.449.376.666.0
LangMem62.247.923.471.158.1

Configuration: gpt-5-mini for extraction, text-embedding-3-small for vectors. gpt-oss-120b via Groq is a budget alternative at ~5x lower cost with comparable quality. See configuration docs for model options and benchmarks/ for reproduction.

Documentation

DocumentDescription
Quick StartGet running in 5 minutes with any client
ConfigurationAll environment variables — LLM, storage, server, memory behavior
Memory ModelTypes, categories, importance, TTL, roles, scoping, sub-agents
MCP Tools16 MCP tools — memory CRUD, search, artifacts
REST APIFull REST API, fsck pipeline, recall/remember endpoints
ArchitectureSystem diagram, detailed flows for storing/searching/recalling
Management UIScreenshots, features, access, UI development
MonitoringPrometheus metrics, Grafana dashboard
DeploymentProduction setup, Docker, authentication, Kubernetes
DevelopmentBuilding, testing, linting, contributing
Client GuidesPer-client setup instructions (10 clients)
System PromptsTemplates for personality agents and custom setups

License

Apache 2.0

docs/maintenance-performance.md

Bounded maintenance performance evidence

Scope and verdict

The initial single full-fsck pair measured 54.28 s baseline / 75.62 s candidate. Two additional matched pairs did not reproduce that regression. They do not establish a runtime gain either: timing variance is large, and the measured fsck phase source is identical between revisions. No evidence-based production correction was justified. The broad end-to-end performance gate remains not established; retain the safe partial changes without claiming a general fsck speedup or deployment readiness.

The intended scheduler benefit is independently demonstrated as bounded per-pass work, not faster processing of the entire queue in one pass.

Full fsck repeated pairs

benchmarks/maintenance_fsck.py ran under the shared heavy-validation flock, in fresh processes, in candidate/base then base/candidate order. Both use 4,096 synthetic memories, 1,536-dimensional decoded vectors, deterministic model replies, two model threads, no warmup, and tracemalloc throughout the check. Identical fixture setup precedes both timers. RSS is process high-water including imports; Python allocation peak covers the check.

MeasurementBase 1Candidate 1Base 2Candidate 2
Wall seconds23.05017.92735.49020.134
Process CPU seconds23.06917.94235.46920.161
Duplicate phase wall seconds22.30217.48234.52219.319
Quality phase wall seconds0.5260.3420.6620.525
Metadata scroll wall seconds0.1330.0580.1750.181
Security regex wall seconds0.0660.0290.1020.083
Peak RSS bytes229482496228667392229195776229171200
Peak Python bytes20113267200971032007561920125077

Median wall time is 29.270 s baseline / 19.030 s candidate. This is descriptive, not an attributed improvement. Only two repetitions per revision, shared-host load, allocation instrumentation, and Python scheduling limit inference. The earlier pair remains part of the evidence; it is not discarded. Process CPU varies as well as wall time, so waiting alone does not explain the variation. No particular environmental cause has been proven.

All four runs produce 410 issues and the same output SHA-256: b793b557a8364198efef2eef5ee9d0c52185a5159bb4eb3362b263238e793396. All measured phase source fingerprints are e3b180026c40a384bcac774a133a02fce926382f59d9183c23a76f4d3cba45c9.

Every run performs 16 metadata scrolls, 16 vector retrievals, 4,096 neighbor queries, and 3,276 metadata stamp writes. Maximum vector batch is 256; 4,096 vectors are decoded in total. Index operations and maintenance scans are zero.

These are synthetic backend calls, not real Qdrant requests. The full check benchmark does not execute apply/recovery, scheduler diagnosis, network search, or durable stamp writes. Its call counts cannot establish end-to-end durability performance. Detailed phase wall/CPU measurements are retained in the JSON evidence, including validation, security re-evaluation and stamps.

Actual remote-Qdrant scheduler measurement

benchmarks/maintenance_scan.py used a disposable Qdrant 1.16.2 container under the same lock. Each revision got a newly created collection with the same deterministic fixture and no warmup:

  • 1,000 recent idle sessions (ineligible).

  • 70 due idle sessions.

  • 40 legacy consolidating sessions with missing timestamps.

Both setup times are reported separately: base 0.480 s, candidate 0.518 s; each setup performs one collection creation and one fixture upsert. Candidate index creation remains inside its first-pass timer. The server process is shared sequentially; OS/server caches are not forcibly flushed, so timing is illustrative. Request and row bounds are the primary evidence.

MeasurementPrevious full passCandidate pass
Selection scrolls52
Summary rows returned1,110At most 48: 32 due + 16 diagnostic
Due rows returned70At most 32
Ineligible rows returned1,040At most 16 in diagnostic page; none in due page
Additional hydration requests1,110 collection-list callsAt most 32 retrieves + 32 collection-list calls
Index requests05 on first pass, 0 thereafter
Diagnosis writes0Observed 0–4 per pass; bounded by 16
Measured Python peak bytes11,705,631At most 1,234,602
Wall seconds4.556Cold 3.230; steady 0.040–1.172, median 0.417

The candidate's observed steady total request count was 14–68 per pass, including hydration and diagnosis. Its first pass made 71 requests. The theoretical steady bound for this fixture without append events is 82 requests (2 scrolls, 64 hydration calls, 16 diagnosis writes). This is not a bound on append-event pages in a real individual session. The baseline scans append links for every session before idle filtering.

All 70 due sessions are visited by pass 3; all 1,110 diagnostic rows by pass 70, including the 40 missing-timestamp legacy records. The eligible-ID digest matches between revisions. Cursors wrap without hiding ineligible data. The benchmark deliberately does not consume due work, so later passes revisit it; it is not a throughput comparison of completed consolidations.

Row counts describe records returned to and examined by Python, not internal Qdrant index-node visits. The candidate count excludes duplicate full payloads returned by hydration retrieves; those retrieves are separately counted. Source/result consolidation writes, arbitrary append-event histories, crash/restart fairness, and sustained infinite-arrival workloads are not performance-certified by this experiment.

Reproduction and evidence

Use the same candidate benchmark scripts with baseline and candidate PYTHONPATH, the same locked environment, and separate processes. The measurements describe the historical baseline/candidate comparison, not qualification of the current release. Runtime behavior was unchanged during that measurement follow-up.

Save evidence in a local directory of your choice outside the public repository. Historical evidence is not bundled; regenerate these outputs when reproducing:

  • repeat-{base,candidate}-{1,2}.json: full phase and request measurements.

  • repeat-summary.json: distributions and scheduler bounds.

  • scan-{base,candidate}.json: actual remote request counts and every pass.

  • fsck-{baseline,candidate}.json: original pair, retained unchanged.

  • fencing.log: target-fencing failure, unchanged and still blocking takeover.

212 files · 196 not served here

Advantages

  • Intelligent extraction and contradiction resolution ensure memory accuracy and prevent duplicate entries. evidence: README.md
  • Self-hosted architecture ensures data privacy with no third-party access to stored memories. evidence: README.md
  • Supports a wide range of clients through the Model Context Protocol and dedicated plugins. evidence: README.md

Limitations

  • Deletion is best-effort and does not guarantee verified erasure or compliance. evidence: README.md
  • Most MCP clients require a specific system prompt instruction to initialize memory correctly. evidence: docs/README.md

Security

Risk level: Low risk

This brain runs

Agent instructions that run or fetch something (8)

  • AGENTS.md: docker buildx build --platform linux/amd64,linux/arm64 -t ghcr.io/fpytloun/mnemory:latest .
  • AGENTS.md: docker buildx build --platform linux/amd64,linux/arm64 --push -t ghcr.io/fpytloun/mnemory:latest .
  • AGENTS.md: # Unit tests (fast, no API key needed, default pytest run)
  • AGENTS.md: They are **excluded from the default `pytest` run** via `addopts = "-m 'not e2e'"` in `pyproject.toml`.
  • AGENTS.md: **When to run e2e tests:**
  • AGENTS.md: Migrations run automatically on startup before the server accepts requests.
  • AGENTS.md: Each migration has a unique ID (e.g., `001_add_sparse_vectors`), a `description`, and a `run()` method
  • AGENTS.md: Migrations must be **idempotent** — safe to re-run if interrupted mid-way or if multiple instances start simultaneously

MCP servers (1)

  • README.md (mnemory): http://localhost:8050/mcp · uses the network
  • Low risk: network-instructions (AGENTS.md:88)

Attribution and licence

Created by
Filip Pytloun
Declared authors
  • Filip Pytloun (declared in pyproject.toml)
Publisher
Filip Pytloun (Community)
Source
fpytloun/mnemory · commit 2d83c47
Licence
Apache License 2.0 (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Filip Pytloun.

Install from source

196 of its files are not served here, so there is no ZIP. fpytloun/mnemory at 2d83c47