Two different things get called "local", and conflating them is why people end up disappointed. One is where your code lives. The other is where the model runs. They have completely different costs.
Local code, local model
The middle arrangement - your project on your disk, a hosted model called per request with only the context that request needs - satisfies most of what people mean by privacy, and costs nothing in capability. It is how most agents work. It is what most desktop and terminal agents do, W1 included.
The right-hand one is what "local AI coding agent" usually means in a search box, and it is a real engineering decision with a real price.
The price of a fully local model
Small models are startlingly good at single-shot tasks now. Agent work is not single-shot, and that is exactly where the gap shows.
An agent's errors compound. Over a forty-step task, a model that follows instructions slightly less reliably does not produce a slightly worse result - it produces a run that drifts, gets stuck in a loop, or confidently completes the wrong task. The difference between models is amplified by the loop rather than averaged out by it.
Why does a small gap in model quality become a large gap in agent outcomes?
Because each step's output is the next step's input. A 5% chance of a wrong turn is a coin flip you take forty times, and a wrong turn does not just cost that step - it puts a wrong fact into the conversation that every subsequent step reasons from.
This is also why "it works fine when I ask it a question" is not evidence that a model will work as an agent.
When fully local is the right call
- You have a legal or contractual obligation that no data leaves your infrastructure. This is not a preference and there is no negotiating with it - go local, accept the capability cost, and scope the work accordingly.
- You work offline for real. Not "sometimes on a plane" - actually disconnected, regularly.
- You are learning how these systems work. Running the model yourself teaches you more in a weekend than a year of using a hosted one.
- You have hardware sitting idle that is genuinely capable, and the marginal cost really is zero.
When it is a detour
If your reason is "I do not like sending my code somewhere", check what is actually sent first. A well-built agent sends the context a request needs, not your repository. You cannot read that off the wire - the traffic is encrypted - but you can check the tool's own run trace, which lists what it read and sent, and an open-source agent lets you read the code that decides.
If your reason is cost, price your own time and electricity honestly against a hosted model's per-task cost. Local is frequently more expensive once your weekend is in the calculation.
The arrangement most people end up with
A local model for the cheap, high-volume, low-stakes steps - reading files, summarising, obvious edits - and a hosted model for the reasoning. It is more moving parts than either pure option, and it is where the practical answer usually lands once the novelty wears off.
Did that land?
Three questions.
Someone says they want a "local" agent for privacy. What should you clarify first?
They are different decisions with different costs. Local code with a hosted model satisfies most privacy concerns at no capability cost; a locally-run model is a much bigger trade.
Why do small models struggle more as agents than as chat assistants?
A small per-step reliability gap turns into a large outcome gap over dozens of steps, because a wrong turn poisons everything that reasons from it afterwards.
Which is the weakest reason to run fully local?
Once hardware, electricity and your own hours are counted, local is often more expensive per task. The other three are sound reasons; cost usually is not.
Sources
Your project stays on your machine
W1 sends only the context a request needs, never your codebase, and never asks for a provider key. Free during beta.
Read exactly what leaves