Why local-first

Local-first is usually sold as a privacy feature. It is one. But if privacy were the only argument, most people would trade it away for convenience, the way they always have.

The better argument is that keeping memory on your machine makes the product work better. Privacy is what you get for free once the architecture is right.

Latency you can feel

A memory layer is only useful if it is ready before you ask. Open the notch and the context should already be assembled — the person you are talking to, the project you are in, the threads still open on it.

Our budget for that is 100 milliseconds from idle to expanded, and 150 for the actions to appear beside it. You cannot hit those numbers over a network. Not because networks are slow in the abstract, but because they are unpredictable: the median round trip is fine and the ninety-fifth percentile is a spinner. A local index has no ninety-fifth percentile problem. It reads from disk.

The same goes for capture. Context is reassembled every time you switch windows, dozens of times an hour. Done locally that is a few hundred milliseconds of background work. Done as a round trip it is a running cost in latency, bandwidth, and battery, paid all day, for data that never needed to leave.

Cost that does not scale with your day

The text index is the clearest case. The shipped app builds a lexical index on your Mac; it does not bundle or download an embedding model. Indexing a heavy day and indexing a light one therefore have no per-token cloud fee, and your memory is not uploaded to an embedding service just to make it searchable.

A cloud-indexed competitor has to choose. Either they sample your day, or they charge for the volume, or they subsidize it with something they get from your data. All three are worse products.

It works on a plane

Search, recall, the daily review, the morning brief — these run without a network. What needs the network is generation: drafting a reply, reasoning over a hard question, taking an action in a connected tool. Offline, ShogunAI still knows your day. It just cannot write the email yet.

That split is deliberate. The layer that must always work is the layer that never leaves.

What actually goes out, and why

Local-first is not a claim that nothing ever leaves the machine. That claim is almost always false, and a false absolute is worse than an honest boundary.

Here is the boundary. Raw memory stays. What goes out are the specific chunks needed for a specific request you made — the thread to summarize, the context for the draft. Connected services see only what that service needs. Every egress is written to a traceability log with its purpose, and where a request crosses a third party rather than going straight to the model provider, the log says third party and the setup asks for consent first.

Two of those crossings exist today, both opt-in, both documented in the product rather than buried here: mail moves through an integration provider, and live meeting transcription uses your Deepgram key with model-improvement opt-out enabled. We would rather name them than round down to "nothing leaves."

Bring your own everything

Because inference is the only part that has to be remote, you can decide who does it. Bring your own API key, or point ShogunAI at the assistant plan you already pay for and let it work inside that. Your memory does not care which model reads it, and switching providers does not cost you a single day of history.

That is the real payoff of local-first. Not a badge on a pricing page — independence. The models will keep changing. Your ten years of context should not have to move house every time they do.