Local-First vs Cloud-First: Why AI Dev Tools Should Run on Your Machine

TL;DR. Most AI coding tools route your code through cloud APIs. Fabriq is built local-first: the engine runs on your machine, artifacts stay in your workspace, and the agent connects through a local protocol. This isn't Luddism — it's a calculated bet that privacy, latency, offline resilience, and team control matter more than the marginal model quality gain from a cloud gateway. This post unpacks each dimension of that bet.

---

The default is cloud#

It's easy to see why most AI coding tools default to cloud architecture. The API keys are already there (OpenAI, Anthropic, Google). The model inference happens server-side. The convenience of "install an extension and start coding" with no local compute requirement is real.

But the default has costs that are invisible in the demo and painful at scale.

The four local-first arguments#

1. Data privacy — what leaves your machine?#

Every keystroke, every file context, every prompt sent to a cloud AI agent is data that leaves your control. For individual developers on open-source projects, this might be acceptable. For teams building commercial software — especially in regulated industries (finance, healthcare, defense) — it's a non-starter.

The question isn't "do you trust OpenAI/Anthropic?" It's "do you have a contractual right to send your entire codebase to a third party's servers?" Most companies' legal teams answer "no" to that question — once they're asked.

Cloud path: Send code context to API → receive completions. No local model option. Local-first path: Agent runs locally → connects to any LLM backend → code never leaves the workspace boundary unless explicitly routed to a configured API.

Fabriq's agent bridge (ACP) is designed for this: the agent process is local, the protocol is local stdio JSON-RPC, and the LLM API key is configured by the team — or replaced entirely with a local model via Ollama or llama.cpp.

2. Latency — the round-trip cost#

AI agent loops are already slow. Each cycle involves: read context → reason → generate edits → apply → verify. Adding a cloud round-trip on top of model inference time adds 200–1000ms per API call.

For a single completion, 500ms of latency is acceptable. For an agent loop that makes 20 API calls per task, that's 10 seconds of pure network overhead — before the model has done any work.

Cloud path: Every tool call, every file read, every prompt must cross the network. Local-first path: Agent process lives on the same machine as the workspace. IPC is stdio — literally process-local pipe communication.

At Fabriq, we measured the difference. A local agent session completes a typical "implement this function" cycle in ~60% of the wall-clock time of a cloud-only session — not because the model is faster, but because the coordination overhead vanishes.

3. Offline resilience — development happens everywhere#

Developers work on planes, in cafes with spotty WiFi, on trains through tunnels, in client offices with restricted networks. A cloud-bound tool simply stops working in these environments.

The argument "just use a local model when offline" assumes the switch is seamless. In practice, it's not — different API formats, different capabilities, different context windows.

Cloud path: No connectivity = no AI assistance. Period. Local-first path: The workspace shell, the engine, and the agent protocol all work offline. The LLM endpoint is swappable — Ollama for offline, Anthropic for heavy lifting, with seamless switching.

Fabriq's architecture means the workspace is always functional. You can review features, browse knowledge artifacts, and prepare work even without any LLM connected. The AI layer is a pluggable capability, not a runtime dependency.

4. Team control — audit trails shouldn't be hosted#

When code context travels to a cloud provider, the audit trail of "what the AI was asked and what it produced" lives on the provider's servers — if it's logged at all.

Cloud path: Limited or no audit logging. Provider-dependent retention policies. No unified view of "what AI actions affected this repo." Local-first path: Every capability call is logged to .dapei/audit/ as structured JSONL. The audit log is in the workspace, version-controlled, queryable by any tool.

In Fabriq, the audit log isn't an afterthought — it's a core data structure. Every state change records: timestamp, channel, payload, dimension, user, and result. Teams can query their own AI activity without exposing it to a third party.

The counterarguments#

A local-first approach isn't free. There are real downsides:

"You can't run the best models locally"#

True — for now. The best proprietary models (Claude Opus, GPT-5) require cloud inference. Fabriq's architecture handles this: the workspace shell is local, the agent process is local, but the LLM call can route to any configured API. You get local-first data control with cloud model quality.

The key difference: the tool works without the cloud. The cloud is an optimization for model quality, not a dependency for tool operation.

"Local setup is harder"#

Also true. Installing a desktop app vs. a VS Code extension is a higher friction starting point. We've tried to minimize this — one-click download, workspace auto-detection, sensible defaults. But the install barrier is real, and we accept it as the cost of the local-first architecture.

"You can't offer a hosted service"#

Not yet. A hosted offering (Fabriq Cloud — managed workspaces, team sync, hosted agent backends) is on the roadmap. But it will be additive to the local-first core, not a replacement for it.

The hybrid reality#

"Local-first" doesn't mean "no cloud." It means the local workspace is the primary, authoritative copy. The cloud is a supplement, not the source of truth.

In practice, Fabriq works like this today:

Capability	Local	Cloud (optional)
Engine (CDR, validation, code analysis)	✅ Inline or subprocess	—
Agent backend (OpenCode / Claude Code)	✅ Local ACP process	—
LLM inference	✅ Ollama / llama.cpp	✅ Anthropic / OpenAI
Audit log	✅ JSONL in workspace	(future: sync)
Team knowledge sync	—	(future: Fabriq Cloud)
Workspace sharing	—	(future: Fabriq Cloud)

The default path works fully offline. Cloud features add convenience, never remove autonomy.

Why this matters for AI tooling#

The AI coding industry is converging on a cloud-first model — partly because it's easier to build, partly because it's easier to monetize, partly because "just route through our servers" is the path of least resistance.

We think that's a mistake for the long term. Software development is the act of creating valuable intellectual property. The tools used to create that IP should respect the boundary between the creator and the cloud. They should work when the network doesn't. They should produce audit trails the team controls. They should be transparent about what data leaves the machine and why.

Local-first is harder to build. But it's the right foundation for tools that developers trust with their most valuable asset: their code.

---

Fabriq is local-first by design. Download it and see the difference, or read the architecture documentation.