BASEMOUSE comparison Get your key

UNIT: COMPARISON REV: 2026-07-31 STORE: HONEST

WHAT PEOPLE USE INSTEAD.

The five real BaseMouse alternatives, what each one is genuinely good at, and the one question that separates them. No feature-matrix theatre, no competitor scoreboard we control the pen on. The section at the bottom lists the cases where BaseMouse is the wrong tool, because you will find those out anyway.

the question that separates them
$ curl -s "$BASEMOUSE/api/context-pack?q=rollback" | jq '.entries[0]'
{
  "id": "runbook-rollback",
  "title": "Rollback procedure",
  "version": 7,
  "citation": { "label": "[runbook-rollback] Rollback procedure v7",
                "source": "docs/runbook.md",
                "checksum": "sha256:4f1c…" },
  "retrieval": { "signals": ["lexical", "graph", "vector"] }
}
# six weeks later, the same question, answerable:
# what did the agent read, which revision, and did it change?
alternativeswhat it is good at · where basemouse differs

PER-TOOL MEMORY FILES

A CLAUDE.md, a Cursor rules file, an AGENTS.md. Genuinely good: they are free, they live in the repo, they diff in code review, and for one tool on one project they are hard to beat. The ceiling is that each file is read by the tool it belongs to. Add a second tool and you are hand-syncing prose, and neither tool can read what the other one worked out yesterday. BaseMouse keeps one store that every tool reads and writes through a single MCP endpoint, with each edit kept as its own revision rather than overwritten in place.

PER TOOLmemory scope

A VECTOR DB YOU WIRE UP

pgvector, Chroma, Pinecone and friends. Genuinely good: maximum control, your choice of embedding model, and the right answer when retrieval quality is the product you are building. What you are signing up for is the rest of the pipeline — chunking, ingestion, re-embedding on change, citation plumbing, and version history — plus keeping it in sync forever. BaseMouse ships that assembly. Its vector step is local, computed in Node with hashed features, so there is no external vector service and no embedding API in the path; retrieval blends it with lexical overlap and one-hop graph expansion, and each result says which signal surfaced it.

DIYyou own the pipeline

A MANAGED RAG API

Upload docs, get answers. Genuinely good: fastest path from zero to a working retrieval feature, and the operational load is someone else's. The comparison worth running is not feature counts, it is what comes back with each passage. Ask whether you get a source, a version, and a checksum you can verify yourself; whether the full edit history is readable; and what your exit looks like. BaseMouse answers those with a checksum on every entry and an MIT-licensed core you can run on your own servers, so leaving is a redeploy rather than a migration project.

VERIFYask for provenance

A GENERIC MEMORY MCP SERVER

The closest neighbour, and the comparison most worth doing carefully. Genuinely good: an agent saves a note, reads it back later, and that alone removes a lot of repeated explaining. The distinction is scratchpad versus repository. BaseMouse writes are versioned, append-only revisions addressed by a stable id, so an upsert_document that changes nothing writes nothing and one that does never destroys what was there before. Reads come back as cited, checksummed context packs. The test to apply to any candidate: six weeks from now, can you say what the agent was told, which revision it read, and when that changed?

RECORDnot a scratchpad

A WIKI OR DOCS SITE

Notion, Confluence, an internal docs site. Genuinely good, and mostly not a competitor: this is where humans write things down, and it should stay that way. They are built for people reading pages, so an agent pointed at one gets whole documents and a general-purpose API rather than the specific passages that answer its question with a source attached. The two compose — humans author in the wiki, agents read a context pack.

HUMANSdifferent reader

WHERE IT DOES NOT FIT SAVE YOURSELF THE TRIAL

WHEN IT IS THE WRONG TOOL.

One tool, one file. If you work entirely in one agent and a single rules file covers the project, that file is doing the job. Come back when there is a second tool or a second person.

You want chat history synced. BaseMouse is the shared knowledge and memory layer, not a transcript-sync service. The live conversation inside each tool stays local to it.

You want a general-purpose vector database. Retrieval here is deliberately local and hashed-feature; it is not a place to put arbitrary embeddings for arbitrary workloads.

Your sources are not markdown yet. Import is folders of markdown today, with GitHub Action and CLI sync on top. Other source types are exactly what the design partner track exists to work through, so start there rather than with a plan.

FAQ PLAIN ANSWERS

COMPARISON QUESTIONS.

What is the best alternative to keeping a CLAUDE.md per project?

If one tool and one file cover you, keep the file. The alternative starts to matter once you use more than one agent tool: a per-tool file is read only by that tool, so Cursor cannot see what Claude Code worked out. BaseMouse replaces the copies with one MCP endpoint every tool reads and writes, and keeps a version history of each change.

Is BaseMouse a vector database?

No. A vector database stores embeddings and returns nearest neighbours; you still build chunking, ingestion, citation, and versioning around it. BaseMouse is the assembled layer: import, hybrid retrieval, citations, checksums, and append-only history behind one endpoint. The vector step runs locally in Node with hashed-feature embeddings, so there is no external vector service and no embedding API call in the path.

How does BaseMouse compare to a managed RAG API?

Both save you from building a pipeline. What is worth comparing is provenance and portability: whether every returned passage carries a source, a version, and a checksum you can verify; whether the full edit history is readable; and whether you can run the same engine yourself. The BaseMouse core is MIT-licensed and self-hostable, so the exit path does not depend on us.

How is BaseMouse different from a memory MCP server?

Many memory servers model a scratchpad: the agent saves a note and reads it back. BaseMouse models a repository. Writes are versioned, append-only revisions addressed by stable id, reads return cited and checksummed context packs, and nothing is silently overwritten. Apply one test to any candidate: six weeks later, can you say what the agent was told and when it changed?

When should you not use BaseMouse?

If you work in a single tool and one rules file is enough, you do not need it yet. It does not sync chat transcripts between tools. It is not a general-purpose vector database for arbitrary embeddings. Import is folders of markdown today, so other source formats go through the design partner track first.