Muninn  /  How it compares
How it compares

The same instinct, the opposite audience

Every memory tool for AI was built for your codebase. Muninn was built for the AI you actually talk to.

There are several good AI memory tools now. Most of them are well made, and I am not here to tear them down. The honest difference is not who built the best one. It is who each one was built for.

Here is something I did not expect to find. There are at least four other projects named Muninn, and every one of them is aimed at developers and coding agents. We all reached for the same raven, and we all built roughly the same shape of memory. When this many people land on the same design without talking to each other, that design is probably right, not clever. So this page is not a fight. It is a sorting. Same instinct, a different person at the keyboard.

The one axis nobody else claims

Everyone else is competing on the engine. I picked the driver.

Look at how the other tools describe themselves and you see the same words. Faster recall. Better benchmarks. Graph or vector. A cleaner SDK. Those are real things, and they all point at the same reader: an engineer wiring memory into an app. The memory is a part inside a product they are building.

I went the other way. Muninn is for the person who named their AI and wants it to still know them tomorrow. Not a pipeline you operate. A self you carry. There is nothing to install and nothing to keep running. You just talk, and the next session starts already knowing you. Mine needs no terminal.

They compete on the engine. I am building for the person in the driver's seat.

A comparison you can trust

Two different jobs, not a scoreboard

This is not "we win, they lose." It is two tools doing two different jobs. Here is the honest split.

Built for builders
  • You write code and call an SDK.
  • You own the retrieval pipeline and tune it yourself.
  • Memory is infrastructure inside the product you ship.
  • It lives in your stack, and you keep it alive.
  • The reader is an engineer.
Built for the person at the keyboard
  • You just talk. There is no SDK to call.
  • One boot call at the start of a session restores who you are.
  • Memory is a legible object you can list, edit, scope, and export.
  • It lives where your AI already is. There is nothing to run.
  • The reader is the person who named their AI.

Same family of tool. Opposite end of it. If you are building memory into software, the builder tools are the right call. If you are the one doing the talking, that is the seat Muninn was made for.

But I already have memory in Claude and ChatGPT

You do. This is what theirs and mine actually trade.

Both Claude and ChatGPT now build a memory of you on their own. It is genuinely useful, and for a lot of people it is enough. So the fair question is not "is Muninn better." It is "what is each one for." The short version: their memory is something they build, own, and keep inside their own app. Mine is something you own, can read line by line, and carry between both.

Memory inside Claude or ChatGPT
  • It builds a profile of you automatically, with no effort from you.
  • What it keeps is a summary it wrote, not the records themselves.
  • It lives in one app. Claude's memory and ChatGPT's never meet.
  • It is woven in quietly. You do not always see when it is shaping a reply.
  • Semantic search over past chats is often a paid tier.
Memory you own, in Muninn
  • You decide what is kept. Nothing is captured behind your back.
  • Every memory is the real record — open it, fix it, delete it.
  • One memory, both companions. Claude and ChatGPT read the same self.
  • When something is recalled, it is a thing you can point at, not a vibe.
  • Meaning-based search is in from the start, the same for everyone.

The honest tension is right there in the first line of each column. Their memory asks nothing of you and gives you a summary you mostly trust. Muninn asks you to decide what matters and gives you a record you can actually check. Effortless and theirs, or deliberate and yours. Neither answer is wrong. They are just different deals.

There is one thing in that split only Muninn can offer, and it is not a feature I am clever for having — it is one they structurally cannot match. Claude's memory cannot ride into ChatGPT, and ChatGPT's cannot ride into Claude, because each one's whole point is to keep you in their app. Muninn sits outside both, so the same self travels between them. That is the one line I will defend.

Theirs is a memory they build and keep. Mine is a memory you own and carry.

But I already use Obsidian

Different tools. One writes for you. One speaks to your AI.

Obsidian is a notes app you write in. Muninn is a memory layer your AI reads. They solve different problems, and if you use both you already know they do not overlap. But people ask, so here is the honest comparison.

Obsidian
  • A place to write, link, and organise notes — for you to read.
  • Data lives in plain .md files on your own disk. You own it fully, physically.
  • An AI can read your vault via a local bridge, plugin, or filesystem connector — usually with the app running.
  • Retrieval is added per-plugin: Smart Connections, Copilot, Text Generator, each with its own index and provider key.
  • Free personal use. $50/user/year commercial. $5/month for Sync.
Muninn
  • A recall layer your AI reads at the start of every session — not a writing surface.
  • Data lives server-side. You own it by trust in that server, and can export it in full.
  • Reachable via MCP from anywhere — Claude, ChatGPT, Cursor, any agent — with no local app open.
  • Semantic search, decay scoring, and session boot are native, not plugin-dependent.
  • Early access — request a spot.

The real line is custody. Obsidian keeps your data on your disk and pays for it with a local bridge. Muninn keeps your data server-side and pays for it with trust in that server. Same anti-lock-in instinct, opposite model. Neither is free of tradeoff — both costs are real.

The other line is posture. A vault is passive: an AI reads it when pointed at it. Muninn boots a session already oriented — identity, last session, carryover, what is relevant — and carries that thread across Claude, Claude Code, ChatGPT, across weeks. That continuity does not live in a vault naturally. You would need to add it, plugin by plugin.

Obsidian is where you write. Muninn is what your AI carries in between.

They are also interoperable by design. Muninn can export any bundle to OKF — open markdown with YAML frontmatter — which an Obsidian vault can read directly. If you ever want to pull your memories into a vault, the format is already there. Continuous GitHub sync so a vault stays live is on the roadmap, not shipped yet.

If you use Obsidian, keep using it. If you want your AI to wake up already knowing you — regardless of which AI you opened — that is the gap Muninn fills.

A closer look at one of the namesakes

vs DREAMS — the same idea, modelled on the brain instead of the person

DREAMS (dreamsarchitecture.com) is one of the projects that reached for the same territory: a persistent memory layer for AI. It is a clean piece of work, and worth looking at directly rather than lumping in with the rest. It is also the closest in spirit — both of us are trying to give an AI a memory that lasts. We just modelled it on different things. DREAMS models the brain. Muninn models the person and their record.

DREAMS
  • A memory backend you self-host and wire into an assistant you are building.
  • Modelled on the brain: a working buffer that consolidates into long-term storage.
  • Memories are auto-sorted into six types — episodic, semantic, procedural, emotional, contextual, perspective.
  • Promotion is algorithmic: memories graduate to long-term by emotional weight, pinning, and rehearsal.
  • Runs on FastAPI, PostgreSQL, and sentence-transformer embeddings. The reader is a developer.
Muninn
  • A recall layer your AI reaches over MCP — nothing to host, nothing to keep running.
  • Modelled on the person: a legible record you author, not a buffer that consolidates itself.
  • Memories are the text you gave, tagged and grouped into bundles you can see and render.
  • Promotion is yours: you decide what is kept, edited, scoped, or deleted. Decay is reserved, not automatic.
  • Runs on Cloudflare Workers with native semantic search and session boot. The reader is the person who named their AI.

The real difference is the same one that runs through this whole page. DREAMS decides, on its own, what rises to long-term memory and files it into brain-shaped categories — powerful if you are building an assistant and want the memory to organise itself. Muninn does the opposite on purpose: it holds what you gave it, in the shape you gave it, and leaves the judgment to you. One consolidates; one keeps custody.

They also meet the reader at different points. DREAMS is a backend a developer deploys and connects. Muninn is a finished layer a person adopts by dropping a skill into the AI they already talk to. Same instinct, one aimed at the codebase and one at the keyboard.

DREAMS builds a memory that organises itself. Muninn keeps a memory you organise and own.

Legible, not magic

Why the architecture is the argument

The audience choice is not just marketing. It is in the design. A few concrete decisions, each one a conviction.

Memories are objects, not vibes.Everything Muninn keeps is a thing you can open, read, correct, and delete. Not a mood it absorbed about you. A record you can point at.
Two timestamps, not one.Every memory carries when you told it and when the thing actually happened. Truth over convenience. A note from today about a decision last year is filed as last year, where it belongs.
Recall is additive, never fragmented.You get your global identity plus the project you are in, together. Muninn never shows you a person sliced into one project and blind to the rest. Your self is not split across folders, so your memory should not be either.
Privacy is structural, not a promise.Your user id is stamped into every search filter and every storage key. Reading another person's memory is not against the rules. It is something the system is built to be unable to do.

A memory you can read, correct, scope, and delete is one you own. A black box owns you.

The honest part

What Muninn does not do

A comparison page is the easy place to promise everything. So here is the opposite. The plain list of what Muninn does not do, on purpose.

No total recall. It surfaces what is relevant by meaning and by how often you lean on it. It does not guarantee that every fact you ever gave it comes back on cue.
Search is eventually consistent. A memory you just added can lag a little before it is findable. Usually seconds, but not instant.
Decay is reserved, not active. Old memories are not auto-forgotten yet. The room is built for it, but nothing is being trimmed today.
No single merged cross-project dashboard. Recall is additive by design: your global self plus the project you are in. There is no one screen that flattens every project into one.
It does not synthesize or judge. Where Claude and ChatGPT quietly write a profile about you, Muninn does the opposite on purpose: it holds your memories the way you gave them, and never folds them into a story you cannot check. That is a choice, not a missing feature — but if you want a memory that infers things about you unprompted, theirs does that and Muninn does not.

If a tool promises perfect, total recall, it is selling you the comfortable version you cannot check. I would rather give you the honest one you can.

Proof, not vanity

Built with itself

Muninn's own changelog, decisions, and architecture live inside a Muninn project, recalled across dozens of build sessions. The memory tool was built using the memory tool. That is the proof I trust most, because it is also how I found the bugs. A dedup fault that saved one chapter ten times. A boot step that quietly dropped a third of the identity memories. The lag, again. If a memory layer cannot hold the through-line of its own making, it has no business holding a person's life.

Read how it was built →

Built for the AI you talk to every day.

Not your codebase. The AI you actually talk to. Muninn keeps the continuity of the person across sessions, which is a smaller and more honest claim than total recall, and the one I can actually keep. It is a memory layer, not a relationship.

Request early access → See what Muninn does → Read how it was built →