Local-first AI development: what stays on your machine

"Local-first" is easy to claim and easy to blur. The useful version is specific: which bytes leave the machine, when, and under whose terms. Here is the line.

What stays local

The workspace runs on your machine — the chat surface, file tree, terminals, preview, and inspection panels. So does the compact memory store and its embeddings, the validation gates (typecheck, lint, test, build, smoke), and your provider API keys, which are encrypted at rest in the operating-system keychain and never exposed to the renderer.

A user-installed open-source local runtime answers most requests with no cloud round-trip at all. For many loops, nothing leaves the machine.

What goes to the cloud — only when you route it there

When you choose a cloud lane for a request, exactly one thing is transmitted: the prompt content you sent. Not your memory store. Not your file tree. Not the keys. The cloud provider sees the prompt, bills you directly on your own plan, and applies its own terms.

This is the BYO-key model: your tool subscription and your AI provider plan are two separate bills. It keeps cost transparent and avoids lock-in — switching providers is a settings change, not a migration.

Why the distinction matters

Three properties fall out of drawing the line clearly: privacy (cloud lanes see only what you route there), cost separation (no bundled, marked-up provider usage), and resilience (the local lane keeps working when the network or a cloud service does not).

Read more on local-first AI development and BYO-key AI development.