What is local-first AI development?
What stays local
- The chat surface, file tree, terminal, preview, and inspection panels.
- The compact memory store (local SQLite) and its embeddings.
- Validation gates: typecheck, test, build, smoke runs.
- Provider API keys, encrypted at rest in the OS keychain — never visible to the renderer.
What goes to the cloud (when you route it there)
- The prompt content you send through a BYO-key cloud lane.
- An OAuth session for a provider you have an existing account with.
Why local-first matters
Local-first preserves three properties: privacy (cloud lanes see only what you route there), cost separation (your DevAware OS subscription doesn't include cloud provider usage), and resilience (the local lane keeps working when the cloud is unavailable).
Frequently asked
- Does local-first mean fully offline?
- Not necessarily. The local lane runs offline on a user-installed open-source runtime. Cloud lanes need a connection, but they run only when you route an intent there. The workspace, memory, and validation work without a network.
- What does a cloud provider see?
- Only the prompt content you choose to route through a cloud lane. Memory storage, file contents you do not send, validation runs, and your API keys stay local. The provider never receives your local memory store.
- Where are my provider API keys stored?
- Encrypted at rest in the operating-system keychain (Keychain on macOS, DPAPI on Windows, libsecret on Linux). They are never exposed to the renderer process.