What Mnemon is
Mnemon is a persistent memory engine for coding agents, written in Go and published under Apache-2.0. Its own README states its thesis plainly: agents forget everything between sessions, context compaction drops decisions, and long conversations push early information out of the window. Mnemon’s answer is a store that outlives the session.
The design difference it advertises is where the intelligence runs. Most memory tools put an LLM inside the pipeline; Mnemon says your host LLM is the supervisor. The binary does the deterministic work — storage, graph indexing, search, decay — while the model decides what to remember, how to link it, and when to forget. Its README describes this as “LLM-supervised”, in contrast to the LLM-embedded pattern it attributes to Mem0 and Letta.
That distinction is the whole product, and it is also the reason the DSH story is split across two repositories — see the next section.
How it reaches DeepSeek Harness
DSH is not wired directly into Mnemon. The README routes it through a separate plugin, dsh-mnemon, which layers DSH’s own runtime memory, managed project documents, and Mnemon’s long-term memory spaces into what the README calls one supervised three-tier memory system.
What this directory’s package actually installs is narrower than the name suggests. The manifest is @mnemon-dev/dsh-mnemon, version 0.1.0, Apache-2.0, and it ships three files: cordis.patch.yml, a README, and a LICENSE. Its dsh field declares one thing only — bundle.patch: ./cordis.patch.yml. Everything else comes from its single dependency, dsh-mnemon: "latest"; the README confirms that installing from the Mnemon repository resolves the latest npm release of dsh-mnemon, so publishing a new plugin release needs no matching change in the Mnemon repo, and an existing install stays on its resolved version until it is reinstalled or updated.
Two honest footnotes. First, the scoped name above is the manifest’s own name, but the unscoped dsh-mnemon is what exists publicly: the npm registry serves dsh-mnemon (0.5.x at the time of writing) and returns 404 for @mnemon-dev/dsh-mnemon. Second, nothing in these two files says this wrapper installs or bundles the mnemon executable, and it declares no OS or CPU constraints, no install scripts, and no optional platform packages. The README’s “npm installs the matching native Go executable” sentence belongs to the standalone core install; assuming the DSH wrapper also provisions the binary is exactly the kind of leap this listing will not make.
What the memory actually is
Memory lives in a local database — a SQLite schema holding insights connected by four edge types: temporal, entity, causal, and semantic. The README’s illustrative screenshot caption describes a real graph of “87 insights, 2150 edges across four graph types”. Storage stays on disk under ~/.mnemon by default (MNEMON_DATA_DIR), and the README describes the project’s foundation as one ~/.mnemon database that any supported agent can read and write. A future direction notes PostgreSQL or Neo4j as possible adapters behind the same protocol; today’s backend is SQLite.
Recall is not keyword search and not only vector search. The README lists intent-aware recall as “graph traversal + optional vector search (RRF fusion)”, enabled by default for all queries, plus built-in deduplication where remember detects duplicates and conflicts and then skips or auto-replaces. Writing and reading are expressed through three primitives — remember, link, recall — which the README calls an intent-native protocol rather than database syntax, returning structured JSON with what it calls signal transparency. Whether an LLM takes part in a given write is a judgment call by your agent, not a fixed pipeline stage.
Requirements and what you have to do
The npm path to the core CLI needs Node.js 22 or newer on macOS, Linux, or Windows, per the README’s install section. Note the gap: this plugin’s own package.json declares engines.node: ">=20". Both numbers are in the sources; they describe different things.
The harness floor for the DSH plugin itself is not stated anywhere in these sources — the README describes DSH integration qualitatively and the manifest carries no harness version, peer ranges or dsh.compatibility block. This listing therefore records no dshTarget, and its verification level stops at L2 rather than asserting a compatibility the sources do not state.
Homebrew, go install, and source builds are documented alternatives, all macOS/Linux; source builds need Go 1.24+. Windows supports the core Memory commands, and mnemon agency — a separate preview surface for Pi agents, not memory — stays unavailable there until it has what the README calls a native Windows security boundary. No external service is required for the base feature set. The one optional dependency is an embedding provider: a local Ollama at http://localhost:11434 by default, or an OpenAI-compatible server. No API key is required for the supervisor, because there is no embedded LLM.
Then setup: the README’s DSH section tells you to open Settings → Plugin Config → Mnemon to choose a storage scope, and to use the Memory System tab inside a session to create or activate memory spaces.
Who pays for the LLM calls
Nothing extra, on the README’s account. Because the supervisor is the host LLM you are already running, Mnemon claims “no middleman, no extra inference cost”, and the README’s callout for Claude Max and Pro subscribers says Mnemon works entirely through the existing subscription with no separate API key. Read this as a statement about ownership rather than about cost: memory judgments are made by the model you already pay for, so they show up inside your normal usage. What you send is another matter — whether a recall or a write carries your memory graph into a hosted model depends on where that model runs, and the sources say nothing about that.
The README does note that sub-agent delegation is optional; when a runtime supports it, the main agent may ask a cheaper isolated worker to execute mnemon remember. That is an execution strategy, not a required part of the architecture.
Scope, sharing, and what leaves the machine
The README answers the sharing question directly: by default all sessions use the same default store, so a decision remembered in one session is available in every future session. Isolation is available through named stores (mnemon store create work), the MNEMON_STORE environment variable, or the DSH plugin’s storage-scope setting. Its Vision section is explicit about intent — “all your local agentic AIs, across sessions and frameworks, sharing one pool of live memory” — with one ~/.mnemon database that Claude Code, Codex, Cursor, DSH, and the other listed runtimes can read and write.
None of that is a cloud feature. No sync service, hosted account, or backup endpoint appears in the sources. Content can still leave the machine in two documented ways: the optional embedding provider, if you point it at a hosted API such as Voyage AI instead of localhost — the memory text is then submitted for embedding — and whatever the host model itself does with what it reads, which the README does not discuss. Telemetry is not mentioned in either direction. Neither are file permissions, encryption at rest, or a privacy policy; do not infer them.
What the sources do offer for auditing is receipts: export hashed operation receipts for “memory-boundary audits without raw memory contents or queries”. That is a boundary-audit aid, not a content-level access log.
Known limits
Capacity is bounded and pruning is automatic. MNEMON_MAX_INSIGHTS defaults to 1000 active insights (set it to 0 to disable automatic pruning), and MNEMON_AUTO_PRUNE_MIN_AGE gives a 24-hour default grace period. Every automatic deletion is soft, appears in the oplog as a prune operation, and is reported by ID in the triggering command’s auto_pruned_ids field — so deletions are traceable, but they do happen without asking.
Accuracy is unquantified. The README publishes no benchmark, no precision or recall figure, and no head-to-head evaluation; the only numbers on the page are one illustrative graph’s insight and edge counts. Deduplication is described as detection plus skip-or-replace, which is a behaviour, not a guarantee that two memories you consider distinct will stay distinct.
Integration depth varies per runtime and the README says so. MiniMax Code is “intentionally skill-only” because version 3.0.65 does not dispatch the user-prompt hook that dependable automatic recall needs; ZCode ignores project-level hook configuration; some runtimes get skills, some hooks and plugins, some TypeScript extensions. DSH’s own list of supported commands, tabs, and tools is not reproduced in these sources.
And several things a reader might assume are simply absent. There is no statement that everything stays on your machine, no claim of an accuracy edge over other memory tools, no packaging or release notes for the 0.1.0 wrapper, and no published list of what the DSH plugin writes into your profile beyond the patch file it declares.
When to use it — and when not to
Reach for Mnemon if you want memory that outlives a session without paying per-token for a second model inside the pipeline, and if you like the idea of one shared store your other agents can also read. The four-graph model, the decay and pruning lifecycle, and the receipts export are the parts a reader can actually hold the project to.
Skip it, or at least go in clear-eyed, in four cases. If your need is strictly within-session context, this is not that tool and its README does not claim to replace the harness’s context handling. If you require every write to pass a human approval gate before it lands, note that this README documents no such gate: writes flow through the agent’s judgment plus a behavioral guide, so a write can happen without you seeing it first. If you are on Windows and need mnemon agency, it is not there yet. And if your environment forbids third-party executables on PATH, remember the architecture is a separate binary invoked by CLI commands, not a library loaded into the harness.
One comparison worth making, since a second memory plugin sits in this same directory: dsh-memento keeps its store inside $DSH_HOME/dsh-memento/memory.db, is pure Node with no native code, and forces every write through DSH’s approval seam. Mnemon keeps a cross-framework store under ~/.mnemon, ships a native Go engine, and supervises writes with your own model instead of an approval prompt. memento’s own README lists dsh-mnemon in its comparison table as “memory store helper”, described against its own “protocol + gate + audit” positioning.
FAQ
Does Mnemon need an API key or a paid LLM account?
No API key is needed on the README’s account. The supervisor is the host LLM you already run, and the README explicitly notes that Claude Max and Pro subscribers can use it through their existing subscription. The only credential mentioned anywhere is optional: MNEMON_EMBED_API_KEY, for an OpenAI-compatible embedding server that wants one.
Where are my memories stored, and is anything uploaded?
In a local ~/.mnemon data directory by default, holding a SQLite-backed graph, with per-store isolation available. Nothing is uploaded by default. The documented exception is the optional embedding provider: point MNEMON_EMBED_ENDPOINT at a hosted service such as Voyage AI and your memory text is sent to it for embedding. The sources make no claim about telemetry either way.
Is the “single binary” story literally true?
For the core engine, substantially yes: the README calls the engine a single native binary installed for your host OS and CPU, with Node.js used only by the npm launcher. For this DSH plugin, no. The manifest here is a small patch bundle with a single dependency; it includes no executable, declares no OS or CPU constraints, and its README does not say it installs the Mnemon binary for you.
Does it replace the harness’s context or compaction handling?
No, and its README makes no such claim. Mnemon’s own lifecycle diagram treats the pre-compaction moment as one of four reminder phases, aimed at preserving “only critical continuity” — it supplements the host’s context management rather than replacing it.
Is memory shared between projects?
By default, yes: all sessions use one shared default store. If you want separation, the README documents named stores, the MNEMON_STORE variable, and a storage-scope setting in the DSH plugin. Note that the README does not document exactly where a named store’s data lands on disk, so treat per-store file layout as unstated.