Does my project memory get uploaded anywhere?

No. Memory lives in SQLite files in the app config directory on your machine. There is no sync, no server copy, and no LLM API call involved in indexing or searching.

Do different projects share a memory?

No. Each project has its own isolated store, so facts from one client's repository can never surface in another's session.

Project memory

Open Free Max keeps a local, per-project memory — every past agent conversation indexed for search, plus human-validated facts your agents can read at launch. Nothing leaves your machine.

Agent CLIs forget. Open the same project next week and the agent has no idea what you decided, what you tried, or why you rejected the obvious approach. Open Free Max fixes that with a local memory, isolated per project.

Two layers, one store

Memory has two distinct layers, and the difference matters:

Layer	What it holds	Who writes it
History	Everything your agents already did — messages, file edits, commands, errors — ingested from each CLI’s own transcripts	Automatic
Project knowledge	Short, durable facts: decisions, constraints, conventions, gotchas	You, after validation

History is raw and large; you search it. Knowledge is small and curated; agents read it. See History search and Project knowledge.

Isolated per project, by design

Each project gets its own SQLite store, keyed by a hash of its canonical path, under project-memory/ in the config directory. A small projects.db registry maps projects to stores.

That isolation is not cosmetic. If you work for several clients on the same machine, a fact learned in one repository must never leak into another one’s agent context. Separate files make that a structural guarantee rather than a filtering rule that could go wrong.

Local, deterministic, unbilled

Indexing and search are plain code — SQLite full-text search, optionally an on-device embedding model. No LLM call, no API key, no network. The only step that involves a model is distillation, and it runs as a normal interactive Claude session on your subscription, like everything else in OFM.

How agents actually see it

Indexing memory is useless if the agent never reads it. OFM has two delivery paths, and they work differently on purpose:

Path A — a tool. OFM hands the agent an MCP server so it can query the memory when it decides it needs to.
Path B — a file. OFM writes the top validated facts into the project’s guidance file (CLAUDE.md, AGENTS.md) at launch, so the agent reads them whether or not it thinks to ask.

Both are described in Memory injection, including which CLIs support which path.

Where it fits next to Obsidian

Project memory is OFM’s own store, managed by OFM. It is not the same thing as connecting an Obsidian vault, which gives agents read/write access to your notes through the vault’s own MCP server. The two are independent: turning one on or off never affects the other. Use memory for knowledge about the project, and the vault for content that belongs to you.

Frequently asked

Does my project memory get uploaded anywhere?: No. Memory lives in SQLite files in the app config directory on your machine. There is no sync, no server copy, and no LLM API call involved in indexing or searching.
Do different projects share a memory?: No. Each project has its own isolated store, so facts from one client's repository can never surface in another's session.