Comparisons
Honest comparisons.
Each tool below does something genuinely well — that's why people reach for it. The comparisons name what those things are before naming where they fall down. Memophant earns its place by solving a problem the others don't.
Memophant vs basic-memory
The foundation we started on — and what we added.
Where basic-memory is strong
basic-memory is an excellent open-source CLI + MCP server for note-taking with observations and relations. Memophant started by orchestrating it: the .memory/ tier in your repo is basic-memory's grammar, kept verbatim because it's right. If all you want is a CLI for knowledge graphs, basic-memory is a great answer and you should use it.
Where Memophant fits
Memophant is what happens when you make basic-memory the foundation of a full project-memory system. Four additional tiers (wiki / design / code / tasks) cross-link with the memory graph. A native macOS UI replaces terminal output with a reader/editor, kanban board, and dashboard. The memory engine moved in-process to pure Swift + SQLite — same grammar, same files, but roughly 45× faster on a 42-query battery. And the pipeline gains drift detection, session distillation, secret-scan, and Run-with-Claude — none of which basic-memory tries to do.
| Feature | basic-memory | Memophant |
|---|---|---|
| Surface | Python CLI + MCP server | Native macOS app + in-process Swift MCP server (and the CLI when you want it) |
| Memory format | Observations + relations in markdown | Same grammar, kept verbatim — your basic-memory notes work in Memophant unchanged |
| Memory tiers | Memory only | Memory + Wiki + Design + Code + Tasks — five tiers that cross-link |
| Performance | Python + SQLite (FastEmbed for vectors) | Pure Swift + system SQLite + NaturalLanguage embeddings — ~45× faster on a 42-query battery |
| Drift detection | not really | Provenance-stamped notes flag when their source code changes |
| Session distillation | not really | Consolidate a Claude Code transcript into durable memory with full review |
| Secret-scan on commit | not really | Two-tier scan gates every commit and every wiki publish |
| Run agentic memory work | not really | Queue Claude-powered tasks; review the diff before applying |
| Visualization | Terminal output | Native reader/editor, kanban board, dashboard with health signals |
Memophant vs a long CLAUDE.md
When the project context is the only file your session reads.
Where CLAUDE.md is strong
A CLAUDE.md is the right answer for a small project. It loads with every Claude Code session, costs little, and is grep-able by the model itself. The minute the project gets serious, though, a single file grows past the model's effective context window — and worse, it grows in a way the model can't query.
Where Memophant fits
Memophant treats CLAUDE.md as a pointer to a structured memory system. The session loads a thin index + the top relevant notes for the request, not a 30k-token doc dump. As the project grows, the index stays small. The substance moves to .memory/ where it's searchable, link-aware, and provenance-stamped.
| Feature | CLAUDE.md | Memophant |
|---|---|---|
| Where it lives | One file in your repo | Structured tiers (.memory/, wiki/, design/, code/, TASKS.md) in your repo |
| Searchable | Full re-read every session | Indexed FTS + semantic search; sub-second queries |
| Token cost as project grows | Grows linearly until truncation | Bounded — top-N relevant notes per session, never the full corpus |
| Stale-detection | not really | Provenance-stamped notes flag when their source code drifts |
| Cross-references | not really | [[bidirectional links]] resolved in-app and via the MCP server |
| Distillation from sessions | not really | Consolidate proposes durable memory from session transcripts |
| Works with non-Claude clients | Claude-specific | MCP server — Cursor, Codex, any MCP-aware client |
Memophant vs .cursorrules
When the editor's own rules file is the memory.
Where .cursorrules is strong
.cursorrules works well inside Cursor — it's loaded automatically, edited inline, and version-controlled. For a Cursor-only project, it's a reasonable answer.
Where Memophant fits
Memophant doesn't replace .cursorrules — it lives alongside it, and gives every other AI tool the same context. Claude Code, Codex, any MCP-aware client reads the same memory the Cursor agent has. And memory is more than rules: it's the decisions, the drift signals, the wiki pages, the task board.
| Feature | .cursorrules | Memophant |
|---|---|---|
| Editor scope | Cursor only | Any MCP-aware client (Claude Code, Cursor, Codex, …) + a native macOS UI |
| Format | Plain text rules | Markdown notes + observations/relations grammar + wiki/design/code tiers |
| Cross-machine sync | Git-committed file | Git-committed files; CloudKit syncs project registry between your Macs |
| Searchable at session time | not really | MCP search_notes + memophant code find — both sub-second |
| Health tracking | not really | Drift detection, freshness, consolidation pass |
| Multiple AI clients in one project | Cursor only | All MCP-aware clients see the same memory |
Memophant vs a Notion or Confluence wiki
When project knowledge lives in a SaaS wiki.
Where Notion / Confluence is strong
Notion and Confluence are excellent at long-form prose, real-time collaboration, and acting as a team's living document. If your knowledge is mostly written by humans for humans, they're hard to beat.
Where Memophant fits
Memophant is what you reach for when the primary reader is an AI session and the primary writer wants to commit alongside the code. Notion knows nothing about your repo; Memophant treats your repo as the source of truth. The wiki tier keeps Notion's strengths (long-form, browsable) without the SaaS lock-in or the disconnection from code.
| Feature | Notion / Confluence | Memophant |
|---|---|---|
| Where it lives | Hosted SaaS | Your git repo, as plain markdown |
| Reachable by your AI session | Indirect (copy/paste or third-party integrations) | Native MCP — the agent reads/writes directly |
| Versioned with code | Separate history, separate review | Commits with the rest of your work — code review, blame, time-travel |
| Works offline | Limited | Fully — search and code index are local |
| Vendor lock-in | Proprietary export, complex re-import | Plain markdown — leave anytime, no migration |
| Long-form prose | Strong | Strong — wiki tier is dedicated to it |
| Collaborator-friendly editing | Strong (real-time) | Async via git PRs (no real-time multi-cursor) |
Use what fits.
Most teams won't replace their team wiki with Memophant — they'll keep Notion for the team narrative and use Memophant for what AI sessions need to know. And every Memophant project is also a valid basic-memory project, because we kept the file format. That's the shape: Memophant's job is to make your repo the source of truth for the AI work, while the rest of your stack keeps doing what it does well.