Local-first isn't a feature, it's a default

Plenty of tools describe themselves as local-first and mean it sincerely. Then the roadmap moves, the hosted path gets the new retriever first, the offline path keeps working but stops being the one anyone runs, and eighteen months later local-first means "there is a mode".

Nobody decided that. It is the natural drift of a project where the interesting work happens on the side that has more compute. The only defence we found is structural: make the offline configuration the one that everything is tested and benchmarked against, so that a regression there is a broken build and not a note in an issue.

What the default actually means here

• The test suite has no network. Not mocked; the runner has no route. A test that needs a network is a test that cannot run, which surfaces the dependency immediately, long before someone's air-gapped deployment finds it.
• Benchmarks report the local models first. Every number in the benchmark post is from the default offline configuration. Hosted-model numbers are published too, second, in the same table.
• No feature ships hosted-only. If it cannot be done with local models, it waits. This has delayed things. It is the whole commitment; the alternative is a promise with an asterisk.
• No telemetry, and nothing to opt out of. There is no collection path in the code. That is a stronger statement than a setting and much easier to verify.

A local mode that the maintainers do not use daily is a mode that is already broken and has not been noticed yet.

The cost, since it is not zero

Local models are worse than the best hosted models, and pretending otherwise is how people end up disappointed. On our own evaluation set the default offline configuration answers correctly 84% of the time against 91% for the strongest hosted model we tested. That gap is real and we publish it in the table rather than around it.

What closes most of the gap is parsing, chunking and retrieval quality: the unglamorous pipeline work that several other posts here are about. Moving from windowed chunking to layout chunking bought more accuracy than upgrading the model did, and it bought it for everybody including people running on a laptop with no network.

Note that attribution barely moves. Whether a claim is actually supported by the cited span is decided by the retrieval and the citation machinery, not by the model's fluency. That is the argument for spending effort on the pipeline and is also why the offline gap is narrower than the model gap suggests.

Why it matters more for documents than for most things

The corpora people point this at are contracts, invoices, mailboxes, HR files, medical letters. For a large number of users the question of whether the content leaves the machine is the reason they can use a tool at all, and a question their compliance team will ask in exactly those terms.

"We do not send it anywhere" is a sentence that has to remain true under every configuration, including the default one someone installs in a hurry without reading the flags. A default that quietly requires a key is a promise that depends on the user's attention, which is not a promise.

The honest caveat

Hosted models are supported, documented, and used by plenty of people running this, including some of us on corpora where nothing sensitive is involved. Nothing here is a position against hosted models. It is a position about which configuration gets the tests, the benchmarks and the burden of proof. Once that is decided, everything downstream tends to decide itself.

Model configuration is in quire.toml. The offline default requires no key, no account and no first-run download beyond the model weights you choose.

---