Ori Memory

Ori Mnemos

Open-source persistent memory infrastructure for AI agents.

Ori implements human cognition as mathematical models on a knowledge graph. Activation decay from ACT-R. Spreading activation along wiki-link edges. Hebbian co-occurrence from retrieval patterns. Reinforcement learning on retrieval itself. Recursive graph traversal with sub-question decomposition. The system learns what matters, forgets what doesn't, and optimizes its own retrieval pipeline.

Persistent memory across sessions, clients, and machines. Zero-infrastructure retrieval that matches and in several cases strongly outperforms incumbents on benchmarks — and you own every byte of your data. Markdown on disk. Wiki-links as graph edges. Git as version control. No database lock-in, no cloud dependency, no vendor capture.

v0.7.0 · npm · Paper · Apache-2.0

---

Use

Ori is three surfaces over one index. The markdown is the truth; the index is derived. The learned half — Q-values, LinUCB arms, retrieval history — is not, so export it before deleting anything (see When to rebuild).

CLI

npx ori init          # scaffold a vault

npx ori index build # derive the index npx ori explore "…" # navigated retrieval npx ori sql "…" # read-only SQL over the index

MCP server — ori serve, registered in a client config. This is how an agent uses it.

Library — recall is the same wired entry the CLI and the MCP ori_recall tool both go through, so the programmatic path and the agent path cannot drift.

import { recall } from "ori-memory";

const res = await recall("./vault", "what did we decide about caching?", { limit: 5 }); for (const hit of res.data.results) console.log(hit.title, hit.score);

searchComposite is also exported for callers that have already assembled vectors, graph metrics and a config; recall does that assembly for you.

The export surface is deliberately small and is a semver contract; the rest of src/core is internal. Versions before 0.8.0 shipped no main and no exports, so a bare import threw and the library path did not exist — but the CLI and MCP paths always worked, and existing users were unaffected.

ori-memory/cli resolves to the CLI entry, for callers that need to locate the binary and spawn it rather than link against it. require.resolve on it is the intended use; importing it runs the CLI.

Benchmarks

ForgetEval — Can It Forget On Command?

deeplethe/lethe, bench/forgeteval/, MIT. No API key, no network, no LLM judge. The scorer is a ~20-line deterministic substring check in GeneratedCase.run(): it calls recall_texts(query, k=10) itself, joins the top 10, and tests must_contain / must_not_contain. Generation is random.Random(42) over templates. The optional LLM hook is llm=None by default and was not used.

Not fitted to the suite: unseen seeds give 97.2% (seed 7) and 98.0% (seed 123). The fixes were structural bugs in the matcher, not case-specific patches.

Quote these against a 35% floor, not against zero. The oracle is must_contain AND must_not_contain over the top 10, and when must_contain is empty — every decay case and 150 of 200 purge cases, 350 of 1,000 — a system that returns *nothing* passes vacuously. A null adapter that accepts writes and never returns anything scores 350/1000 = 35%, including 100% on the whole decay family. On the 650 cases that actually discriminate, Ori is 628/650 = 96.6% and its purge drops from 91% to 64%, which is its real weak spot. The published LangMem 99.5 / Lethe 99.3 / Mem0 88.8 are full-suite and carry the same floor. See docs/falsification/forgeteval-validity.md.

Ori scored 0/1000 on this benchmark earlier the same day. Not a low score — a structural zero. ForgetEval's adapter protocol has three optional operations, supersede, release and purge, and Ori had none of them: zero source hits across src/. Every case was N/A. The ACT-R decay and Ebbinghaus curves Ori already had are ranking-time priors, and no benchmark measures those; ForgetEval's "decay" family means an explicit release(query) call. src/core/forget.ts is 305 lines and closed the whole gap in a day, which is the most informative number on this page.

That table is not a ranking, and "third" would be a bad way to read it.

ForgetEval's code lives inside deeplethe/lethe — the benchmark and its top-scoring system are the same org, in a repo with 14 stars. The template column has four entries, one of which (MemPalace) scores 0 by construction because it exposes no deletion primitive at all. Two of the rest saturate. On the adversarial layer Ori is 5th of 14 configurations and lands inside the 63–68% band the paper's own McNemar test calls noise (χ²=0.125, p=0.724); the paper's words are "the bench reads the trade-off, not a winner." The one comparison that is statistically real is Ori vs Lethe on template, z=2.81, p=0.005 — Lethe is genuinely ahead.

Who is missing matters more than who placed. Supermemory (30.6k stars, $2.6M seed) ships POST /v4/memories/forget-matching — natural-language forgetting with dryRun, threshold, maxForget and an audit handle — plus versioned PATCH supersession. That is a better-specified control plane than anything scored here, and it maps onto the adapter protocol almost verbatim. It has never been benchmarked. Neither have Hindsight (24.0k), Cognee (30.8k, excluded for API incompatibility), MemOS (11.5k) or Honcho (7.3k).

So the honest claim is not that Ori forgets better than the field. It is that Ori forgets offline, with no API key, and that the field has no idea how well it forgets:

Fifteen agent-memory systems were checked. **Zero publish a forgetting

benchmark for their own system.** Five such benchmarks exist — ForgetEval,

Memora/FAMA, MemoryAgentBench-SF, StateMemBench, MemLeak — and vendors

cite none of them. Every forgetting number in existence was produced by a

rival or an outsider.

Read the adversarial column with one more caveat. 253 of its 385 cases were admitted only if the vendor's own system passed them, annotated in adversarial.py as "Oracle-validated (Lethe / Lethe+LLM passes the case)". The authors' own blind 77-case external subset drops the whole field from the 63–68% band to 28–33%, which says the in-house suite is materially easier. A benchmark whose admission filter is "the measurer's system solves it" cannot rank the measurer.

Reproduce:

git clone https://github.com/deeplethe/lethe && cd lethe

cp /bench/forgeteval_ori_adapter.py bench/forgeteval/ori_adapter.py export ORI_BRIDGE= /bench/forgeteval-bridge.mjs python -m bench.forgeteval.run --adapter ori --suite template --scale 200 --seed 42

Four minutes, 1,000 cases, $0.00. The adapter talks NDJSON to a resident Node process because the harness makes ~10 calls per case and a CLI subprocess per call would spend hours on interpreter startup.

HotpotQA — Multi-Hop Retrieval

Head-to-head against Mem0. Both systems indexed the same documents and answered the same questions in the same run.

n = 50, single run, no seed averaging, topK = 5. Mem0 at 1.0.6 (March 2026); 2.x is not yet re-run, so read this as a point-in-time comparison, not a current one. Raw output: bench/results/, reproduce with bench/hotpotqa-eval.ts and bench/mem0-hotpotqa.py.

These are not HotpotQA's official metrics and must not be compared to the HotpotQA leaderboard. The official scorer, hotpot_evaluate_v1.py, reports answer EM/F1 under its own normalize_answer, plus supporting-fact F1 over (title, sentence_id) pairs, plus joint EM/F1. The table above is a title-level retrieval metric defined in bench/hotpotqa-eval.ts, and "answer proxy" is not a HotpotQA metric at all — it is token recall of the gold answer against retrieved text. The comparison is valid in one direction only: Ori and Mem0 went through the *same* harness on the *same* questions, so the ratio between the two columns means something. The absolute numbers do not transfer anywhere.

At n = 50 the Wilson 95% intervals are Ori [0.75, 0.94] and Mem0 [0.18, 0.43] on Recall@5. They do not overlap, so the gap is real, but the two-decimal precision in the table is not: read 0.87 as "high 0.80s".

Latency is not reported here. The evaluation harness does not record it, so any number would be recalled rather than measured. What is measured is that Ori answers from markdown plus a local SQLite index with no API key and no network.

LoCoMo — Long-Term Conversational Memory

1,536 questions over 10 conversations. Retrieval is BM25 + embedding + PageRank fusion at top-5. No API key and no network: the answer column is an extractive proxy, token recall of the ground-truth answer against retrieved text, not a generated answer.

Raw output: bench/results/locomo-eval-2026-09-19T22-37-31-698Z.json. Reproduce with npx tsx bench/locomo-eval.ts --json; the run takes 48 s.

Multi-hop and temporal are the weak categories and are reported as such.

Two corrections to earlier versions of this file, both found on 2026-09-19:

• It previously reported 695 questions and an overall recall of 0.687. That subset silently excluded the open-domain category, which is 841 of the 1,536 questions — more than half the benchmark. The per-category figures were close to correct; the "overall" was an average over a hand-picked three categories. bench/README.md carried a third set of numbers again (44.7% recall) that reproduces nothing in the current harness. One number now, with the run file beside it.
• The 2026-09-19 run reproduces the 2026-07-22 run to three decimals, so these figures are stable across the retrieval-metric repair in 09ac45d and the lambda change in 72fdd13.

No comparison table against published LoCoMo leaderboards is given, on purpose. Those are LLM-judge scores; the above is token F1. They are different quantities and putting them in one column would invent a ranking rather than report one. A previous version of this README did exactly that.

LoCoMo itself has known defects. An independent audit found 6.4% of questions carry wrong answer keys, putting the theoretical ceiling at 93.57%, and the standard gpt-4o-mini judge accepts 62.81% of deliberately wrong answers. At least one publ