From Cloud-Only to Local-First
For most of the early 2020s, AI coding meant cloud. You installed an editor extension, typed a prompt, and your code — together with context, file paths, and sometimes whole repositories — traveled to a vendor's servers and came back as a suggestion. That model was fast to adopt and easy to sell, and it is still how the majority of professional developers work today. As of 2026, 84% of developers report that they use or plan to use AI coding tools, according to industry surveys, while only 33% say they trust them — a 51-point adoption-trust gap that says more about architecture than about model quality.
Local-first AI development is the model that closes part of that gap. In a local-first setup, the agent runtime — task planning, file access, shell execution, indexing, session history — runs on your own machine. Where the model runs is a separate, configurable decision: you can point at a cloud API you hold the key for, or at a local runtime such as Ollama or vLLM with weights on your own disk.
The distinction matters because cloud-only tools concentrate two risks at once: a network dependency you do not control, and a data path that ends outside your perimeter. Local-first separates "the intelligence" from "the infrastructure," so teams can choose per project rather than per vendor.
This article looks at where local-first AI development is heading: the four forces pushing it from niche to default, the honest case for what stays in the cloud, and what teams should actually do about it in 2026. For a deeper treatment of the privacy mechanics, see our companion piece on why your code should never leave your machine.
The Four Forces Converging
Local-first is not a single product trend. It is four independent curves that happen to be peaking at the same time, and their intersection is what makes 2026 different from 2023.
1. Open-weight models that are good enough
Open-weight families — DeepSeek, Qwen, GLM, Kimi, MiniMax, and the Llama lineage among them — have closed much of the practical gap with frontier cloud models on mainstream coding tasks. "Good enough" is the operative phrase: the question is no longer whether a locally hosted model can produce a competent diff, but whether it can produce a competent diff within your hardware budget.
That said, be precise about the trade-off. A 70B-class open-weight model is not a frontier model, and the gap widens on long-horizon agentic work: multi-step refactors, large-repository reasoning, and tasks that require holding many constraints at once. Open weights changed the floor, not the ceiling — which is exactly why local-first tools should also let you reach for a cloud model when the task demands it.
2. On-device hardware that can actually run it
The hardware picture has become predictable enough to plan around. The rough rule of thumb for quantized models is about 1 GB of VRAM per 1 billion parameters: a 7B model fits in roughly 4–5 GB, 14B in 8–10 GB, 32B in 20–24 GB, and 70B in 48 GB or more. On Apple Silicon, 16 GB of unified memory is a practical minimum and 32 GB is where local models become genuinely useful for agentic coding.
That puts capable local inference in reach of a well-specced developer laptop or a single high-end GPU (a 24 GB card handles a good 32B coding model comfortably). It does not put full 70B-class fine-tuning there — that remains effectively cloud-only, which is one reason the hybrid model below persists.
3. BYOK as the commercial norm
Cloud-only tools have historically bundled inference into a subscription, which means the vendor owns the cost model, the quota, and the reset schedule. BYOK — Bring Your Own Key — inverts that: you supply your own provider key, the provider bills you directly at list price, and the tool adds no token markup. A related pattern extends the same idea to weights: point the tool at a self-hosted vLLM or Ollama endpoint and the "provider" is your own machine.
BYOK matters for local-first because it makes the two halves separable. You can buy the orchestration once and the inference however you like — cloud API for hard tasks, local weights for sensitive repos or high-volume routine work. It also removes the vendor from your request path, which is a privacy property, not just a billing one.
4. Standards that make local viable: MCP
A local agent with no access to your tools is a local agent you cannot use. The Model Context Protocol (MCP) is the standard that fixes this: it gives agents a uniform way to talk to file systems, databases, issue trackers, browser automation, and internal services, without every tool building a bespoke integration.
MCP is the quiet enabler of the local-first story. It decouples the agent from the environment, so the same orchestrator can run on a developer's laptop, in a regulated on-premise network, or in an air-gapped lab and still reach the systems it needs — as long as those systems are described as MCP servers. For a working example, see our multi-agent getting-started guide.
The table below summarizes how the four forces interlock:
| Force | What it provides | Why local-first needs it |
|---|---|---|
| Open-weight models | Capable models you can host yourself | Makes on-device inference viable at all |
| On-device hardware | ~1 GB VRAM per 1B parameters; 32 GB unified memory is the practical sweet spot | Determines the largest model you can run locally |
| BYOK | Direct provider billing, no token markup, model freedom | Separates orchestration cost from inference cost |
| MCP | Open standard for tool and data access | Lets a local agent reach real systems |
The "local gap" is still real
It would be dishonest to describe local-first as the mainstream. As of late 2026, the field splits sharply. Only a handful of tools offer meaningful local or on-device operation: Goose, which runs on your machine and supports local models via Ollama; Kilo Code, which combines 500+ models with Ollama and LM Studio support; OpenHands, whose MIT-licensed core self-hosts entirely on your infrastructure; and Warp, where the BYOK option and a local terminal keep the interactive layer on your machine, though Warp documents no local model support and its cloud-agent features run in the cloud.
The big-name cloud agents sit on the other side of the line. Google's Jules runs on Google VMs with Gemini only. AWS Kiro is AWS-hosted. Amp routes every request through its own curated model layer — it explicitly does not support BYOK or local models, because routing is the product. Windsurf, now under the Devin Desktop banner after Cognition's June 2026 rebrand, remains a subscription platform with cloud-side quota. The gap between "AI coding" and "local-first AI coding" is therefore still the gap between the default and the minority. Each of these tools is assessed in more detail on its own comparison page — see Doforu vs Goose and Doforu vs OpenHands for the closest architectural neighbours.
What Stays in the Cloud
An honest local-first argument has to concede where cloud wins. It wins in several places, and pretending otherwise would be the fastest way to lose credibility with the engineers evaluating these tools.
Frontier reasoning on hard problems. When a task needs the strongest available model — novel architecture decisions, ambiguous large-repository refactors, deep debugging across unfamiliar code — the frontier cloud models are still ahead of what most teams can host. Per JetBrains Research in 2026, roughly 39% of professional developers used Claude Code at work, up from 18% in January. That shift reflects real capability advantages, not just marketing.
Elastic burst capacity. Local inference is bounded by the hardware you own. If you need sixty concurrent agents for an hour and you have one laptop, the cloud is the only answer. That asymmetry is structural.
Massive context and long-running sessions. Serving very large context windows and multi-hour autonomous sessions is economically brutal locally and straightforward on someone else's GPU fleet.
Training and fine-tuning. Full fine-tuning of a 70B-class model needs on the order of 300 GB of memory — effectively cloud-only for most teams today.
Collaboration and shared state. Hosted control planes are genuinely good at multi-user coordination, audit logs, and org-wide policy. A purely local tool has to earn that back deliberately.
The practical conclusion is not "cloud or local" but routing. A mature setup uses local models by default and escalates to cloud models when the task justifies it — which is the same reasoning that makes a heterogeneous model strategy sensible in the first place.
What This Means for Teams
If the four forces keep converging, the operational questions change shape. A few concrete implications for 2026–2027:
Procurement shifts from seats to licenses and keys. Per-seat subscriptions scale linearly with headcount and reset monthly. A perpetual, BYOK-capable tool turns inference into a variable cost you control and software into a capital-ish one-time purchase. The three-year math on subscription versus perpetual is unflattering to per-seat pricing for teams that stay put.
You should be able to state your data path in one sentence. "Prompts go from this laptop directly to the provider whose key I hold, and nothing else leaves" is a sentence a security reviewer can verify. "Requests go to our vendor, who forwards them to a model" is not. Local-first tools make the first sentence possible.
Regulated teams get an actual option. Air-gapped and on-premise development used to mean forgoing AI assistance entirely. With local weights, MCP for internal tool access, and an orchestrator that runs on your own hardware, a regulated team can adopt agentic coding without a data-processing agreement that nobody wants to sign.
Lock-in becomes a routing decision. When the model layer is swappable by design, a vendor's pricing change or a model's deprecation is an inconvenience rather than a migration project. The 2026 market has already produced both kinds of turbulence — a prominent VS Code agent extension shut down in May 2026 and its users had to move, and at least one vendor withdrew a free tier mid-year. Tools that separate orchestration from inference are structurally more resilient to that.
The evaluation criteria change. Instead of asking "which tool has the best model?" — a question whose answer changes quarterly — teams should ask: can it run offline, is the request path auditable, can I bring my own key and my own weights, and does it speak MCP. Those are durable properties.
Doforu's Bet on Local-First
Doforu is a desktop AI agent orchestrator for macOS, Windows, and Linux, built on the premise that the orchestration layer belongs on your machine. That is the bet: not that local models will beat frontier models, but that a local orchestrator with a swappable model layer is the more durable architecture.
Concretely, that means:
- Orchestration runs locally. Plan / Agent / Orchestrator modes, task decomposition, and execution all happen on your desktop. Doforu does not route your traffic through a Doforu server.
- Model freedom, including local. 15+ model families are available — OpenAI (GPT-6 Astra), Anthropic (Claude Opus 5.5), Google (Gemini 4 Argon), DeepSeek (V4.1), Qwen (Qwen3.8-Max), Moonshot (Kimi K3), MiniMax (M3), Zhipu (GLM-5.3), plus local models via Ollama/vLLM.
- BYOK, no markup. Connect directly to providers with your own keys; Doforu adds no token markup. Point at a local endpoint and marginal inference cost can approach zero.
- Parallel multi-agent execution. Orchestrator 2.0 splits a goal and dispatches multiple subagents simultaneously, rather than running a single agent one step at a time.
- Skills and MCP. Reusable natural-language Skills (SKILL.md) describe a workflow once and reuse it forever; MCP connects the agent to your real systems.
- $49, one time. A perpetual license including one year of updates, with a free trial available.
Where local-first peers lead, we should say so: Goose is free and Apache-2.0 with broad MCP coverage, OpenHands has an MIT core and mature sandboxed execution, and Kilo Code offers the widest model catalogue of any of these. Doforu's contribution is the orchestration layer — the part that decides what to run, in what order, and how many agents to run at once — combined with a commercial desktop product rather than a bare open-source agent.
FAQ
Final Thoughts
Local-first AI development is not going to win by being the loudest option, and it does not need to. It wins by making a specific guarantee that cloud-only tools structurally cannot: the execution layer, the index, and the history stay under your control, and the data path from your machine to a provider is one hop you can audit.
The four forces — open-weight models, on-device hardware, BYOK, and MCP — have each matured enough that the guarantee is now practical rather than aspirational. Hardware is predictable, models are good enough for most work, the billing model is yours to choose, and the tooling standard exists. What is still missing is breadth: most of the market is cloud-only, and only a handful of tools (Doforu among them) put the orchestrator on your desktop.
The reasonable expectation for the next two years is not that local replaces cloud. It is that the question "where does this run?" becomes a configuration choice rather than a product category — and that teams which answered that question early will have an easier time with the compliance, cost, and lock-in conversations that follow.
Ready to try a local-first desktop agent orchestrator? Download Doforu for macOS, Windows & Linux
