Local-first is a process boundary, not a cache

“Local-first” has become elastic enough to describe almost anything. Sometimes it means the browser keeps a copy. Sometimes it means the cloud service synchronises quickly. Sometimes it means the desktop app is a web client with a generous offline cache.

Those can be good products. They are not the boundary I care about.

For Miton, local-first begins with a plain question: which process holds the work? Project files, conversations, goals, workflow history and indexes live on the machine running Miton. A hosted model request crosses that boundary only because the user connected that provider and allowed the task to use it. A local model keeps inference inside its own local process. Diagnostics are separate choices, off by default.

That definition is less romantic and more useful. It admits that a hosted model call sends context off-device. It does not claim that an API request somehow remains local because a desktop app made it. It gives us a concrete place to apply permission, redaction, injection checks and egress recording.

It also changes product design. The app must work with files already on disk rather than uploading a shadow repository. Secrets need OS-backed storage. Search should not require a remote index. A workflow schedule should be understandable as a local service. When the network disappears, the workspace should fail at the provider boundary rather than forgetting the project.

Local-first is therefore not the promise that nothing ever leaves. That would make most hosted models unusable and the promise false. It is the promise that crossing the boundary is deliberate, legible and limited to the service the user chose.

Trust comes from accurate nouns. “Sync” is not storage. “Private” is not local. “On your device” is not a meaningful claim if every useful action immediately uploads the project. Name the process, name the crossing and give the user control over both.