memory

What it is

memory gives your coding agents persistent, local-first memory: facts, preferences, context, and records stored in a SQLite database on your machine.

It also provides dreaming, an LLM-first curation pass over a scoped memory corpus via the memory_dream and memory_dream_apply MCP tools or the od3sa-memory dream CLI.

It works with any stdio MCP client — Claude Code, Cursor, or anything else that speaks MCP.

How it works

1. Remember — your agent stores a fact or context via memory_remember.
2. Embed — the binary embeds the content as a 256-dim vector.
3. Store — the memory and vector go into ~/.memory/default.db.
4. Recall — later, your agent asks memory_recall; memory returns the closest matches by cosine similarity.

Common tasks

• Install and verify
• Connect your client
• Read the tools reference
• Build a knowledge packet
• Set up multi-device sync
• Browse skills
• Curate memories with dreaming

Data stays local

There is no cloud account, no external API, and no network call for recall. First run extracts the embedded runtime and model weights to your platform cache; the SQLite database stays under ~/.memory/. Optional encrypted multi-device sync runs through a self-hosted relay so the contents stay opaque to the relay operator.

Release binaries

Each 0d3sa release ships two related single-file Go binaries:

• od3sa-memory — this component: memory, MCP server, sync, and pairing.
• od3sa-relay — dedicated relay server for multi-device sync. See relay docs.