How it works

A small program runs quietly on your computer and looks after a folder of memories. When your assistant needs to remember or recall something, it asks that program. The assistant never gets your whole vault — only the few notes that answer the question it's working on, with the date and source attached.

If you point it at a folder of your own documents, it asks for your confirmation in person, on that computer, before it reads anything. A change proposed from anywhere else doesn't take effect on its own.

Where things live
Your assistant
Claude, Cursor, or anything else that speaks MCP. Asks questions; gets a handful of notes back.
↓ ↑
ModelBrain, on your computer
Does the searching locally. Only it is allowed to write to the vault.
↓ ↑
Your vault
Files on your disk, in a location you chose. Back it up like anything else you care about.

Changing your mind, and deleting things

A correction

"Actually, we moved the launch to March." The new note replaces the old one for future answers, and the old one is kept as history.

An undo

"Forget that, I was wrong." The correction is removed and what you said before becomes current again. Nothing is invented in between.

A deletion

"Forget that document." All of it goes, including every piece of it the system had broken out, not just the paragraph you mentioned.

One honest caveat: in the first release, recall treats every note equally rather than automatically preferring your latest correction. Preferring the newest version is the next piece of work after the first release, not something we're claiming now.

From here down it gets technical Nothing above depends on reading this.

Local vault → MCP server → any compatible host

Hosts

Any MCP client over stdio. The thin client forwards five tool names and no others.

remember · recall · forget
expand · connector_sync
Transport

One Unix domain socket, checked against the OS peer UID. Nothing administrative is reachable from a model.

connector_add is TTY-gated
no --yes override exists
Daemon + vault

Single writer over append-only segments. Embeddings via llama.cpp, in-process. Full-text and vector indexes over the same objects.

index: ULID → (segment, offset)

One memory, one object

Objects, tags and edges, searched by full text and vector similarity together rather than vector-only. visibility is a real field in the record header that the model can never set; connector provenance is written at ingestion and is not model-writable either.

id           ULID, 16 raw bytes
body         type, text, block_type,
             heading_path, table_data,
             source_uri, sync_connector_id
visibility   header enum — never model-set
parent_id    chunk → document grouping
tags         inline list per object
edges        inline adjacency (supersedes)

Tiered storage, and which tiers exist

Tier
Role
Status
Memory
Active context, hot indexes.
in v1
Regular disk
Hot segments, uncompressed and mmap'd for zero-copy traversal — which is why neither compression nor encryption happens here.
in v1
Compressed disk
Cold but local, zstd with a corpus-trained dictionary over text, tags and JSON.
designed
Server
Authoritative collection and shared team knowledge. Opt-in, separately billed.
designed

Private and local-only blocks are removed from the server-eligible set before placement runs. Privacy is a hard filter, never a cost term. And moving a block between tiers never changes what a memory means — eviction is not forgetting.