What Is Truly Local-First AI? A Local Model Is Not Enough
Quick answer: Truly local-first AI makes the user's device the primary home of the workspace—not merely the place where model inference can run. Core work remains available offline; files, rules, history, memory, and artifacts are durable and portable; and every external model, tool, telemetry, or provider path is explicit and enforceable. Model portability improves resilience but is not required by the category. A product that only “supports local models” is local-capable, not necessarily local-first.
The decisive question is: when the network disappears, does your work remain yours and keep working?
Key facts
- Local inference answers where a model runs; local-first answers where the whole work system lives.
- Primary data should be readable and changeable on the user's device without a cloud service.
- Offline core work, durable artifacts, export, migration, and recovery are part of the test.
- Optional networking is compatible with local-first when the user controls it and local work remains primary.
- A Vault-style privacy mode counts only when the egress boundary is technically enforced and fails closed.
Local model support vs true local-first AI
| Dimension | Supports a local model | Truly local-first AI |
|---|---|---|
| Model inference | Can run on-device | Can run on-device for core offline work; model portability is a resilience benefit |
| Primary files and state | May live in cloud or app account | Live on the user's device as the primary workspace |
| Offline work | Model may answer; app may still fail | Core read, edit, execute, and artifact work continues |
| History and memory | May depend on hosted storage | Durable, inspectable, and locally retained |
| Tools and retrieval | May call remote services silently or by default | External paths are explicit, bounded, and observable |
| Artifacts | May remain in chat or provider storage | Are user-owned files that can be exported and migrated |
| Telemetry | Unclear or account-dependent | Documented, controllable, and disabled inside strict privacy boundaries |
| Failure behavior | May fall back to cloud | Strict mode blocks or fails visibly rather than weakening the boundary |
Local-first does not mean “never use a network.” It means the network is optional for ownership and core work, not the hidden owner of the workspace.
The five-part local-first test
1. Primary-data test
Where do source files, instructions, rules, history, memory, and outputs live? Can the user inspect, copy, backup, and remove them without asking a provider?
2. Offline test
After required local models and assets are installed, disconnect the network. Can the user open the project, continue core work, run permitted local tools, and produce an artifact?
3. Egress test
Block outbound traffic. Does the application fail visibly when a cloud model, web search, remote embedding, telemetry, update service, or network tool is requested? Or does it quietly route around the boundary?
4. Portability test
Can the user export source files, project metadata, important history, rules, and artifacts in usable formats? Can compatible software continue the work? Model portability is useful for reducing lock-in, but a system may still be local-first while binding inference to one local model.
5. Recovery test
Can local backups restore the project? Are originals preserved? Does a model-provider outage leave the workspace readable and its artifacts usable?
Illustrative example: disconnected contract review
This is a synthetic workflow, not legal advice, a customer result, or a security certification.
An analyst must review confidential contract copies while disconnected.
System A runs a local model but stores projects and chat history in a hosted account. Its document index uses a remote embedding service, and the final table exists only inside the app. When disconnected, the model process may run, but the workflow is not available end to end.
System B keeps copied source files, project rules, local embeddings, session history, memory, execution evidence, and the final review table in a local-primary workspace. The local model and tools complete the core task offline. External search or a cloud model can be chosen in normal work, but strict privacy mode hard-denies those paths and fails closed.
System B has the stronger local-first claim because ownership and continuity extend beyond inference.
What local-first does not mean
Local-first is not the same as open source: closed software can keep user data local, and open software can depend on a cloud service. It is not the same as self-hosted: a browser client on a team server can still make the server the primary owner rather than the user's device.
It does not require a single device forever. Local-first systems can sync or collaborate, provided the local copy remains primary and the user retains control. It is also not a compliance certification or proof of security.
Why tools and embeddings matter
A local chat model can receive passages created by a remote embedding API. A tool can upload a file, query the web, call a remote MCP server, or run a command with network access. Telemetry can export filenames, prompts, or task metadata depending on design.
Trace the complete execution path. “No cloud model” is only one row.
Where Agenaxy fits
Agenaxy is designed around a local-primary Space containing files, rules, memory, model preferences, permissions, sessions, execution evidence, and artifacts. It works on copies supplied to the workspace so originals remain untouched. Models are replaceable rather than becoming the owner of the project.
Standard mode can use selected local or cloud models. Vault—Agenaxy's Local Privacy Mode—locks the Space to local models, local embeddings, local tools, and local logs, disables project telemetry, enforces network deny below the prompt layer, and fails closed instead of silently falling back to cloud capabilities.
That whole-workspace boundary is why a Vault-like architecture qualifies as real local-first while “supports Ollama” alone does not. Review the local-first AI agent workbench, Vault Mode, and local AI vs cloud agents for the adjacent layers.
Test one offline-sensitive workflow
Describe the source types, offline steps, required artifact, and acceptable external paths in an Agenaxy beta request. Do not submit contracts, confidential documents, customer records, credentials, or production data.
FAQ
Does running Ollama or another local model make an app local-first?
No. It proves that a model can run locally. Inspect where the app stores projects, history, memory, embeddings, artifacts, logs, and tool traffic.
Can local-first AI use a cloud model?
Yes, in normal mode, if the user explicitly chooses the external path and the local workspace remains primary. A strict privacy mode should be able to prohibit that path technically.
Is self-hosted AI local-first?
Not automatically. Self-hosted describes who operates a service. Local-first requires the user's local copy to remain the primary, durable, offline-capable work surface.
Is local-first AI automatically secure or compliant?
No. It can improve control and resilience, but security and compliance still depend on implementation, configuration, operations, law, and evidence.
Sources and Fact-Checking Notes
- Ink & Switch, Local-first software provides the foundational principles of local data ownership, offline work, longevity, and user control applied here to AI work.
- LM Studio offline documentation and Ollama API documentation show why local inference and offline runtime capability are component-level facts.
- OpenClaw FAQ and Open WebUI provider connection illustrate how self-hosted or local-capable products can still connect external models, embeddings, channels, or tools.
- Product documentation was checked on 2026-07-24. The five-part test is this article's operational evaluation framework, not a legal standard.
- Agenaxy statements are checked against its local-first Space, source-copy, Standard mode, Local Privacy Mode, network gate, model freedom, telemetry, Trace, and Artifact canon.