integratedcomputersolutions/mnem-o-matic

Runs privately in a Docker container or natively. Your data never leaves your machine.
The Problem
Every LLM session starts from scratch. Claude doesn't know what ChatGPT learned yesterday. Your Copilot session can't access the architectural decisions you discussed with Claude last week. Each tool operates in complete isolation.
Mnem-O-matic fixes this by providing a shared, persistent memory that any LLM can read from and write to.
What It Stores
**Documents** — reference material, code snippets, specs, configs, notes. Anything you want LLMs to have access to.
**Knowledge** — discrete facts, decisions, and observations. "The auth system uses JWT with RS256." "We chose Postgres over SQLite for the main database." "The deploy pipeline runs on GitHub Actions."
**Notes** — quick thoughts, ideas, observations, and voice transcripts. Informal content that LLMs should be aware of but that isn't structured enough to be a document or atomic enough to be a knowledge entry.
All types support namespaces (per-project or global), tags, and metadata. Everything is searchable via full-text and semantic search, narrowed when you need it by tag or by "updated since". Large documents are automatically split into chunks at store time, so search returns the most relevant passage rather than the entire file — giving agents focused context without burning their context window.
A Memory and a Filing Cabinet
The filing cabinet is the part above — organized, tagged, searchable storage. What makes it also a *memory* is how content behaves over time: it has history, mistakes are reversible, and the store helps keep itself tidy:
- **Temporal facts** — knowledge answers questions whose answers change. When a fact changes, the old entry is superseded rather than overwritten: search returns only the current answer, and fact_history shows what was believed before, and until when. More →
- **Undo & recovery** — every update and delete first saves the item's prior state as a revision; restore rolls back a bad edit or recreates a deleted item under its original id. More →
- **Duplicate awareness & consolidation** — storing near-identical content gets flagged in the store response, and consolidation_report clusters look-alike items and lists stale, never-retrieved ones. The bundled consolidate and briefing prompts turn review into one-command workflows — no server-side LLM involved, the connected agent is the judge. More →
- **Associative recall** — related returns an item's nearest neighbors across all content types, so an agent that just read one thing can pull in the surrounding context it didn't know to search for. More →
- **Usage tracking** — items carry retrieval counters, bumped only when something is genuinely read or surfaced by search. The raw material for spotting what earns its place. More →
- **Audit trail** — every write lands in an append-only log: what changed, when, by which user and token, from which client and address. Sign-ins, token and user changes are recorded too. Two-year retention by default. More →
Backups & Export
The whole store downloads as a **human-readable zip** — one folder per namespace, one Markdown file per item, metadata in sidecars — via GET /export, the web UI, or the CLI. Your memory stays portable and is never locked in. The server can also write that archive on a schedule with rotation: set MNEMOMATIC_BACKUP_DIR and backups happen with no host-side cron. More →
Embedding Model
Semantic search runs on a local embedding model bundled into the Docker image — nothing leaves your machine. Four models are selectable at build time via the EMBED_MODEL build argument: **arctic-embed-xs** (the default) is the smallest and fastest, English only, at ~240 MB of memory; **amaretto-embed-148m** is a distillation of EmbeddingGemma that keeps most of its retrieval quality at roughly 40% of the memory, across 8 Latin-script languages plus code; **gte-multilingual-base** adds strong multilingual retrieval at near-arctic query speed; **EmbeddingGemma** has the best retrieval quality of the four — it resolves paraphrased queries that share no words with the stored content — at a higher CPU and memory cost. You can also bypass the built-in model and point MNEMOMATIC_EMBED_URL at any OpenAI-compatible embedding endpoint. See choosing the built-in embedding model for the full comparison.