The editorial synthesis concludes that despite dramatic improvements in local models like Qwen2.5-Coder-32B and DeepSeek-Coder-V2, nobody in the high-karma replies reports a successful full replacement with improved output. Context window economics, multi-file refactoring, and long-context debugging remain decisive advantages for hosted frontier models.
The original poster's framing implicitly acknowledges this is an open question by demanding rigor — 'fully swapped,' 'main coding tool, not just for side experiments,' with setup and tok/s required. The precision of the ask suggests skepticism that casual claims of replacement hold up under scrutiny.
The editorial identifies a substantial cluster of practitioners using Continue, Aider with Ollama, or Zed's local provider for tab-completion and small inline edits, while reaching for Claude/GPT for multi-file changes or tool use. This split-workload approach captures the latency and privacy benefits of local inference without sacrificing capability on hard tasks.
The editorial acknowledges a smaller group of hobbyists and privacy maximalists who run local-only setups and consider the capability tradeoff worthwhile. For them, sovereignty over their tooling and data outweighs the productivity delta versus frontier hosted models.
The editorial highlights that this same question has been asked on HN every two months since 2023 with the same answer, despite Qwen2.5-Coder-32B benchmarking competitively with GPT-4 on HumanEval and MBPP. The persistent disconnect between benchmark parity and daily-driver viability suggests benchmarks fail to capture what matters most — context handling and multi-file reasoning.
An Ask HN post — 'Has anyone replaced Claude/GPT with a local model for daily coding?' — climbed to 423 points and several hundred comments. The framing is precise: not side experiments, not 'I tried it for a weekend,' but full replacement as the primary daily driver, with setup details and tok/s numbers required.
The replies cluster into three honest groups. The first and largest: people who tried hard and went back. They run Qwen2.5-Coder-32B-Instruct or DeepSeek-Coder-V2-Lite on a 4090, an M3 Max with 64–128GB, or a dual-3090 rig, get 15–40 tokens/sec on quantized weights, and report that for single-file edits and shell scripting it's genuinely fine — but the moment they need a real multi-file refactor or a long-context debugging session, they reach for Claude again.
The second group: people who split the workload. Local model in the editor for tab-completion and small inline edits (Continue, Aider with Ollama, Zed's local provider), Claude or GPT for anything that touches more than one file or requires tool use. The third, smallest group: hobbyists and privacy maximalists who genuinely run local-only, accept the quality gap, and consider it a fair trade.
Nobody in the high-karma replies says 'I fully replaced Claude with a local model and my output went up.' That is the actual finding from the thread, and it's been the finding every time this question has been asked since 2023.
This question gets asked on HN roughly every two months. The interesting thing is that the answer has barely moved, even as the local models have gotten dramatically better. Qwen2.5-Coder-32B benchmarks competitively with GPT-4 on HumanEval and MBPP. DeepSeek-Coder-V2 is genuinely strong. Llama 3.3 70B exists and runs on consumer hardware if you're willing to suffer. And yet the lived experience reports keep landing in the same place.
There are three reasons, and the thread surfaces all of them.
Context window economics. Claude Sonnet ships with 200K context and you pay per token. A 32B local model technically supports 32K–128K but RoPE-extended attention degrades, and KV cache for long contexts blows out your VRAM. The frontier labs aren't winning on raw code-completion quality anymore — they're winning on how much code you can stuff into one prompt without the model getting confused. One commenter benchmarks this directly: feed both Qwen2.5-Coder and Sonnet 80K tokens of a real codebase and ask for a cross-file refactor; Sonnet finds the call sites, the local model invents them.
Tool use and agentic loops. Claude Code, Cursor's agent mode, and Aider all depend on the model reliably calling tools, reading errors, and looping. Open-weight models are improving here but the gap is visible in production. A top reply in the thread describes a local Qwen agent loop that 'works until it doesn't — then it confidently writes 200 lines of code against an API that doesn't exist.' Sonnet does this too, but less often, and the recovery is better.
The price floor keeps dropping. The economic argument for going local was 'API costs will eat me' — but Sonnet input is ~$3/M tokens and Haiku is under a dollar, while a 4090 is still $1,800 and depreciates. Unless you're running a code-completion product at scale, or your data genuinely can't leave the building, the math doesn't work. Several commenters do this calculation explicitly: at $40/month of Claude usage, the 4090 pays for itself in 45 months — by which point the model on it is three generations behind.
The one place local is uncontested: regulated environments. Defense contractors, healthcare, banks with hard data-egress rules. For them the question isn't 'is local as good' — it's 'is local good enough,' and increasingly the answer is yes. Qwen2.5-Coder-32B running on an air-gapped box is a perfectly serviceable pair-programmer for someone who can't legally use Claude.
If you're asking this question seriously, the honest answer from the thread is: don't fully replace, augment. The setup that the most credible commenters report using:
- Local model for tab-complete and inline edits. Qwen2.5-Coder-7B or 14B via Ollama, plugged into Continue or Zed. Fast, private, zero marginal cost, good enough for the 80% of edits that are mechanical. - Frontier model for agent loops and multi-file work. Claude Sonnet via Claude Code or Aider for the 20% of work where context, tool use, and reasoning actually matter. This is where you spend money, and it's worth spending money there. - Local 32B for offline. Keep a quantized Qwen2.5-Coder-32B on disk for flights and outages. It will not match Sonnet, but it will keep you shipping.
The split-stack approach is what actually works in production today, and it is what the high-karma replies in the thread describe. If you're optimizing for privacy, accept that you're trading quality and move on. If you're optimizing for cost, you're probably miscounting your own time. If you're optimizing for shipping code, use the best tool for each subtask and stop relitigating the question.
One thing the thread does *not* engage with seriously: the M-series unified-memory story is genuinely different from the 4090 story. A 128GB M3 Max running a 70B model at 8 tok/s isn't fast, but it's usable for batch jobs and it doesn't need a separate machine. If you already own one for other reasons, the local-coding story is more defensible than it looks in the GPU-centric replies.
The interesting question isn't 'when will local match Sonnet.' Local already matches Sonnet on a lot of narrow tasks. The interesting question is whether frontier labs will keep widening the moat on context and agentic tool use faster than the open-weight community can close it on raw generation quality. So far the answer is yes, by a comfortable margin. Ask this question again in October and the replies will look almost identical — better numbers, same conclusion.
Has anyone here fully swapped Claude/GPT for a local model as their main coding tool, not just for side experiments? If so, please share your setup and performance (e.g tok/s)
→ read on Hacker NewsTop 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.