        
        Deterministic memory for Claude Code & Obsidian
      

Connects the dots.
The same way, every time.

The only agent memory that connects the dots across your [[links]], deterministically. Same note-chain every time, fully auditable, ~99% fewer tokens than pasting your whole vault. No GPU, no vector DB, no LLM in the loop.

Get started See the comparison

−99%

tokens vs. pasting the whole vault
~5k vs ~482k · real 356-note vault

100%

multi-hop / link-only answers reached
flat search (BM25 & dense) scores 0%

0/0/0

in the retrieval loop
GPUs · vector DBs · LLM calls

We measured it

Why not just let Claude manage its own context?

We ran it head to head. An agent that browses the notes folder itself gets the same answers, multi-hop included. It just pays for it.

~10x

cheaper, same answers

12/12 ✓ Both reach the right answer. The agent is not the problem. What it costs is.

Claude prunes its own contextagent loop

4-6 model round-trips / question

~10x the billed tokens

~9 s per answer

re-sends the whole transcript every step

WikiMoth1 pass

0 model calls to retrieve

1 deterministic retrieval pass

ms not seconds

shows the exact note-chain (auditable)

Real run, Claude Sonnet 4.6, 12 multi-hop questions on a reproducible vault. The ~10x counts a reader on both sides. Corpus-specific, not a universal law.

In the agent loop

Claude calls it. You paste nothing.

One line wires WikiMoth into Claude as an MCP tool. Ask something that lives in your notes and Claude calls recall itself, gets the deterministic note-chain, and answers. No copy-paste, and no model call to retrieve.

you ask a question → Claude calls recall(query) → deterministic [[note-chain]] → answer ✓

terminal · Claude Code

$ claude mcp add wikimoth -- npx -y wikimoth-mcp
or, pip-native:
$ python -m pip install wikimoth
$ claude mcp add wikimoth -- python -m wikimoth mcp

The npx launcher finds a Python that has WikiMoth (or installs one on the fly via uvx) and injects your vault path, so there is no toolchain to match. On the pip path, use the same python in both steps (python3 on some systems). Pure-stdlib MCP server over stdio: recall, status, and the memory-hygiene tools (conflicts, lint, duplicates, fading, supersede). Works with any MCP client; point it at a vault with --vault or WIKIMOTH_VAULT.

re: Karpathy's LLM Wiki

You know Karpathy's LLM Wiki, markdown [[wikilinks]], no vector DB? WikiMoth is the deterministic retrieval layer for that pattern: it walks those links in code, no LLM in the loop, returns the same note-chain every time, and shows you exactly which notes fed an answer.

How it works

Retrieve, compact, read, then capture back.

No index to build, no model to call. Your [[wikilink]] notes are the memory.

01Retrieve

Follows your authored [[links]] hop by hop to the notes flat search can't reach.

02Compact

Returns just the relevant note-chain, about 5k tokens instead of 482k for the whole vault.

03Read

Hands the agent plain markdown plus the exact note-chain behind it, auditable, same result every time.

↻ capture loop

Deterministic, API-free auto-capture writes new notes back as markdown and links them in, no LLM in the loop, nothing to re-index.

Comparison

It matches the basics. The edge is the combination.

Nobody else checks every box at once, connect-the-dots and determinism and audit and plain markdown.

Capability matrix WikiMoth vs. flat search vs. RAG vs. LLM-curated memory

              ✓yes
              ✕no
              ~partial / n.m.
            

Capability

WikiMoth

BM25

Vector RAG

claude-mem

LLM WikiKarpathy

Connects the dotsmulti-hop over authored [[links]]

✓

✓*

Deterministic retrievalsame query → same result

✓

No LLM call to retrieve

✓

Auditable note-chain

✓

Direct-lookup recall@8real vault

1.00

No GPU / no vector DB / no index

✓

Plain-markdown storeopen in any editor

✓

Token-minimal vs dumping the vault

✓−99%

✓

Deterministic, API-free auto-capture

✓

* LLM Wiki follows links, but the LLM does the navigating, agentic, non-deterministic, one LLM call per retrieval.

WikiMoth uniquely combines connect-the-dots + determinism + audit + plain-markdown. It matches flat search on the basics, the edge is the combination, not higher recall. Complementary to Karpathy's LLM Wiki: richer curated pages there, deterministic retrieval here.

By the numbers

Measured across real vaults, not synthetic data.

−99%

tokens vs. pasting the whole vault

~5k vs. ~482k tokens on a real 356-note vault, same answers.

0% → 100%

multi-hop / link-only answers

Flat search, BM25 and dense, scores 0% on these. WikiMoth follows the links to reach them.

5 → 1

distinct result across k=5 runs

Five repeated runs collapse to one identical result. LLM-based memory varies run to run.

1.00

recall@8 on direct lookups

On the basics it's a tie, 1.00 = 1.00, on par with the best flat retriever. The edge is the combination, not the recall.

0 / 0 / 0

in the retrieval loop

GPUs · vector DBs · LLM calls. None, retrieval is pure deterministic link-walking.

Determinism

Same query, run five times.

Retrieval is a pure function of your vault: the same question returns the exact same note-chain every run. LLM-summarised memory drifts run to run.

WikiMoth1 distinct

run 1→ a1f3c
run 2→ a1f3c
run 3→ a1f3c
run 4→ a1f3c
run 5→ a1f3c

LLM-based memoryvaries

run 1→ a1f3c
run 2→ 7b2e9
run 3→ c40a1
run 4→ a1f3c
run 5→ f1d77

Result hashes shown for illustration. Same input, same output.

Two lines and you're running.

Point it at an existing Obsidian vault or your Claude Code notes. No services to provision, no embeddings to compute.

terminal

$ pip install wikimoth
$ wikimoth demo
instant multi-hop over a bundled vault, no setup
already have a vault?
$ wikimoth serve --vault ~/obsidian-vault