The default assumption in AI deployment is that data travels to the model. For most workloads that is fine. For some it is unacceptable, and for a growing number it is unacceptable to the customer even when it is technically defensible.

Local-first inverts the arrangement: the model runs where the data already is.

When local-first is the right call

Regulatory constraint. Some data cannot cross certain boundaries — jurisdictional, contractual or sector-specific. When the constraint is legal rather than preferential, the architecture decision is already made.

Contractual obligation. Enterprise customers increasingly require that their data not be processed by third-party model providers. This shows up in security reviews and it is not negotiable at the point it appears.

Volume economics. At sufficient scale, sending everything to an API becomes the dominant cost line. Local inference on owned hardware has a high fixed cost and a very low marginal one; past a crossover point it is simply cheaper.

Latency floor. A network round trip has a floor you cannot optimize below. For genuinely interactive work — an editor suggesting as you type, a keyboard predicting the next word — that floor is the whole product experience.

Availability requirement. If the function must work when the internet does not, local is the only answer.

What you give up

Honesty matters here, because local-first is frequently oversold.

Capability. The models you can run on local hardware are meaningfully less capable than frontier hosted models. The gap has narrowed and it has not closed. For hard reasoning, the difference is still obvious.

Operational burden. You now own model updates, hardware, monitoring and capacity. That is a real function with real staffing implications.

Iteration speed. Hosted models improve without your involvement. Local models improve when you do the work of upgrading them.

The hybrid pattern that usually wins

The most practical architecture is rarely all-local or all-hosted. It is a split by sensitivity and difficulty.

Run locally: classification, extraction, redaction, embedding, prediction, and anything touching raw sensitive records. These are high-volume, latency-sensitive, and well within local model capability.

Run hosted: complex reasoning, long-form drafting, and multi-step synthesis — after the local layer has extracted, redacted and structured what needs to leave. The hosted model sees a sanitized abstraction rather than the underlying records.

This pattern gets you frontier capability where you need it while keeping raw sensitive data inside the boundary. It requires being genuinely rigorous about the redaction step, which is where these designs usually fail in practice.

How we deploy it

Local-first is available on the platforms where it matters most. SnowyButterfly keeps personal vocabulary on the device and never transmits it — for a keyboard, anything else would be indefensible. Phantom offers a local deployment for monitoring environments where the systems being watched cannot be described to an external service. Writewell's suggestion layer runs against local models for the sentence-level work and escalates only when a user explicitly asks for heavier assistance.

The decision framework

Three questions, in order.

Is there a hard constraint — legal, contractual, or availability — that forbids the data leaving? If yes, local, and the rest is implementation.

If not, is the task within local model capability? Extraction and classification, almost certainly. Complex multi-constraint reasoning, probably not.

If both are open, it is an economics question: fixed infrastructure and staffing cost against per-request API cost at your projected volume. Run the numbers over three years rather than three months, because the crossover point moves.

What you should not do is choose local-first as a security gesture without the constraint that justifies it. It is a real architecture with real costs, and it should be chosen for a real reason.