Local vs Cloud AI Coding: When Local Loses

Summary:

1. The green/amber map that tells you local-or-cloud before you fire a task.
2. Why the “local is terrible” reviews are almost always wrong-zone, not wrong-tool.
3. The three task types where cloud genuinely still wins.
4. How the boundary moves in your favor over time, and how to re-test it.

The real question isn’t whether local AI is cool. It’s: are local coding models good enough for your actual work? The honest answer is that for most of your day they are, and for a specific slice of hard tasks they aren’t. The skill that makes local worth it is knowing which task is which before you waste thirty minutes finding out the hard way.

Where does local win, and where does it lose?

Local wins on the work that fills most of your day, and loses on the rare heavy lifts. Here’s the map, with the exact task types and an honest boundary between them.

Read it top to bottom and notice the shape: the tasks you do constantly live in the green zone, and the big architectural lifts you do occasionally live in the amber. That’s the whole business case. The frequent work is free and private; the rare heavy work is where you spend a little cloud money on purpose.

Why local genuinely crushes the green zone

Local crushes the green zone because those tasks don’t need a giant context window or a long chain of tool calls. They need a competent model that’s seen a million functions like yours, and the open coding models have.

Take a single-file edit: add input validation to a loadConfig() function so it rejects missing keys. The context fits, the task is well-defined, the answer has a known shape. A model like qwen2.5-coder does that as well as you need it to, on your machine, with the Wi-Fi off. For green-zone work, “good enough” and “frontier” produce the same diff, and one of them is free. You run local by default:

codex --oss --local-provider ollama -m qwen2.5-coder

Multiply one clean edit by every test, every boilerplate file, every small change in your week, and you see where the “$300 to $2” feeling comes from. It’s not one magic task. It’s the hundred small ones that stop costing anything.

Where local still loses, honestly

Local struggles, today, with two kinds of work, and they’re worth naming so you spot them coming.

The first is huge-context reasoning: holding a large amount of code in its head at once, tracing a bug across a dozen files, understanding a sprawling system before changing it. A local model in a modest context window loses the thread and makes a change that’s locally sensible and globally wrong.

The second is long chains of tool calls, the one that bites hardest in an agent. A developer on Hacker News put the whole tradeoff in one honest line:

at the moment, I think the best you can do is qwen3-coder:30b, it works, and it’s nice to get some fully-local llm coding up and running, but you’ll quickly realize that you’ve long tasted the sweet forbidden nectar that is hosted llms. unfortunately.

Source: news.ycombinator.com/item?id=46767464 (user: mittermayr). That’s the map in a sentence. Local works, and for the hardest multi-file, long-chain tasks, the frontier still pulls ahead. The honest move isn’t to suffer through an amber task locally to prove a point. It’s to open the cloud tool, pay for that one task, and come back to local for everything else.

The angry reviews, decoded

The best way to internalize the map is to run the loudest complaints through it. Every one makes sense the moment you ask which zone the person was standing in.

“Local models are terrible.” Usually someone who lived in the amber zone, asking a local model to do the multi-file features and cross-repo reasoning it’s worst at, constantly. The fix isn’t a better model. It’s the map: stay green for daily work, go cloud for the heavy lifts.

“Qwen will completely destroy a codebase if it’s not restrained.” True, and not a model-quality problem. It’s a guardrails problem. Run with approvals on, work on a clean git branch, and recovery is two moves:

git status && git diff   # see exactly what the agent changed
git restore .            # throw away the working-copy mess, back to your last commit

“One call took 52 seconds. Unusable.” That’s the tuning trap, not a verdict. The model is too big for the hardware or the context is set wrong. Every one of those has a knob. Not one of these complaints is “local can’t code.” They’re wrong-zone, wrong-guardrails, and wrong-tuning, three fixable problems reported as one unfixable verdict.

The map moves, so re-draw it

The boundary between green and amber isn’t fixed. It moves in your favor, for two reasons: tuning your setup pushes borderline tasks into green, and the open models keep improving on exactly their weak points, tool-call reliability and context handling. A model a few months newer can quietly push a whole row from amber to green. So re-test it: every so often, pull a fresh contender and run a task that used to live in the amber zone.

ollama pull qwen3.6   # re-run an old amber task and see if it's gone green

The trend has been one direction. The green zone grows, the amber shrinks, and the work you have to send to the cloud gets rarer.

What should you actually do?

• For single-file edits, tests, boilerplate, and explaining code, run local. It’s free, private, and good enough.
• For multi-file features, big refactors, and long-context debugging, reach for cloud on purpose, then go back to local.
• Before you fire a task, glance at the map. Decide green or amber with your eyes open instead of finding out after three wrong edits.

The bottom line

• Local isn’t good or bad. It’s good at green and weak at amber, and the skill is telling them apart before you start.
• Most “local is terrible” stories are wrong-zone, wrong-guardrails, or wrong-tuning. All three are fixable.
• Run local by default, keep cloud on the bench for the genuine amber tasks, and re-draw the boundary as the models improve.