A post from founder Alex Ellis hit Hacker News a few days ago and the title became the meme: “Local Qwen isn’t a worse Opus, it’s a different tool.” Within hours it was bouncing around X because it cut against the dominant narrative – that a local Qwen 3.6 on a single GPU is basically free Claude.
Ellis writes as a founder running a real software business, with receipts. His core claim reframes the whole conversation: local Qwen is not a discount Opus. It’s a different shape of tool, useful for things Opus is wasted on, and dangerous for things Opus handles fine.
The takeaway, upfront
If you’re choosing between “all local Qwen” and “all Claude Opus,” the question itself is wrong. The setup that works in practice is routing: send small, bounded, repetitive, or privacy-sensitive work to local Qwen; escalate hard, long-horizon, or unsupervised agentic tasks to Opus. The rest of this article shows you how to wire that up – and where Qwen quietly breaks.
Why the comparison keeps happening
Qwen3 launched April 28-29, 2025, Apache 2.0, with MoE and dense models from 0.6B up to 235B-A22B. The more recent Qwen variants (the 3.5 and 3.6 families) tightened coding scores enough that the benchmark gap with Anthropic’s flagship narrowed to single digits on some tests.
That’s where the hype came from. Qwen 3.6 27B scores 77.2 on SWE-bench Verified against Claude Opus 4.8’s 88.6% – per Ellis’s benchmark comparison. “12% behind frontier” on a GPU you already own reads as a bargain. The number is real. The conclusion is where people go wrong, because benchmarks measure bounded, repeatable tasks, not the long-horizon reasoning where Opus earns its cost.
Two approaches – one works
Approach A – “Replace Opus.” Point your coding agent at a local Qwen endpoint and hope it covers everything. Most tutorials sell this. It fails in a specific, ugly way (more on that below).
Approach B – “Route by task.” Run Qwen locally for cheap, high-volume, low-risk work. Keep an Opus API key for the hard stuff. Switch via a config flag.
Approach B wins – not because Qwen is weak, but because the two models optimize for different jobs. The gap between them is smaller inside bounded workflows: document parsing, screenshot QA, UI generation in a constrained loop. For steady-state extraction or classification, running Qwen on your own infrastructure costs a fraction of API calls at volume. That’s the actual sweet spot.
The walkthrough: a routing setup that works
You need Ollama, a Qwen3 pull, and an agent that accepts a custom OpenAI-compatible base URL.
1. Install and pull a sensible model
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3:8b # around 5-6GB depending on quantization
ollama serve
The 8B is the right entry point for most setups. The 30B-A3B MoE moves faster on a MacBook because – per the Qwen3 release post – only 3B parameters are active at generation time. Ellis flags this as a speed-for-quality trade many people accept without realizing it. If VRAM allows, the dense 14B or 32B gives better answers per token even at half the throughput.
2. Fix the Ollama defaults before anything else
Almost every tutorial skips this. The Qwen3 GitHub README explicitly warns about Ollama’s defaults: num_ctx is 2048 and num_predict is -1 – infinite generation inside a 2048-token window. Your model’s reasoning gets silently truncated mid-thought. You blame the model. It was the context window.
In your Modelfile or via the API, set num_ctx to something realistic for your VRAM (32768 is a solid start) and cap num_predict to something finite like 8192.
3. Wire your agent to the local endpoint
Ollama’s OpenAI-compatible API lives at http://localhost:11434/v1/ by default (confirmed in the Qwen3 README). Point Aider, Continue, Cline, or any OpenAI-SDK tool at that URL:
export OPENAI_API_BASE=http://localhost:11434/v1
export OPENAI_API_KEY=local-no-key-needed
export OPENAI_MODEL=qwen3:8b
4. Add a Claude escape hatch
Keep your Anthropic key in a second env file. The point of routing is that you flip one variable when you hit something hard. Don’t bury it in code.
In your editor, define two run configs side by side – “local” and “opus” – bound to keyboard shortcuts. If switching costs more than three seconds, you’ll stop doing it and drift back to one model.
5. Use Qwen’s thinking switch deliberately
Qwen3 has two modes you can toggle inline. Add /think or /no_think to a user prompt to switch reasoning behavior turn by turn – that’s a confirmed feature from the Qwen team’s release post. Use /no_think for autocomplete and simple lookups. Use /think when you want real chewing. Leaving thinking on for trivial calls burns tokens for nothing.
A question worth sitting with
At what point does maintaining two model configs become more overhead than just paying for the API? The routing setup above takes maybe twenty minutes. But it assumes you’ll actually enforce the discipline of sending tasks to the right model – and that discipline breaks down under deadline pressure. Worth testing your own habits before optimizing the infrastructure.
Edge cases nobody mentions
The Ollama tag aliasing trap
Turns out the Qwen README has an explicit warning about this: qwen3:30b-a3b in Ollama actually points to qwen3:30b-a3b-thinking-2507-q4_K_M as of August 2025 – naming that doesn’t match Qwen’s original conventions. When a tutorial tells you “just toggle /no_think,” your model might already be a thinking-only variant where that toggle behaves differently. Always check what you actually pulled before following a guide.
Two distinct loop failure modes
Ellis documents both from real usage, and they have different fixes:
“Read-everything” looping: He asked Qwen to produce a forensic report on a machine. It started reading every file one by one, filled its context, then hallucinated filenames – ~/faas-netes became ~/faaned. Fix: scope the task aggressively and pre-filter what the agent can see.
“Stuck-fix” looping: Qwen corrupted a file mid-edit and kept reporting it didn’t know how to fix it, going progressively off the rails without giving up. Fix: a hard step cap in your use, plus an auto-revert on file corruption. As the MindStudio analysis notes, smaller models in agentic settings lose track of the task or hallucinate tool outputs – Qwen avoids this most of the time, but quantization down to fit a consumer GPU brings it back.
The 64K context cliff
The model card says 256K. In practice, per ofox.ai’s benchmark report (mid-2025), Qwen 3.6 27B’s effective context degrades past 64K tokens under load – Claude Opus 4.6 maintains coherence over its 200K window in ways the local model still can’t match, as of that comparison. You won’t get an error. You’ll get quietly worse output. Chunk it.
Where does that leave the “is it as good as Opus” question?
Wrong question. Opus is a generalist trained for long-horizon agentic reliability. Qwen is a strong open-weight model you control end-to-end, with predictable failure modes you can engineer around. Different axes.
The teams getting real value from local Qwen aren’t trying to replace anything. They’re sending it the tasks where its specific shape – fast, private, cheap at the margin, good at reading code – actually fits. That’s not a consolation prize. That’s a workflow.
FAQ
What hardware do I actually need to start?
Roughly 8GB of VRAM handles qwen3:8b at typical quantization levels – though the exact number shifts depending on which quant you pull. Below that, you’re in 4B territory: fine for autocomplete, limited for anything else.
Should I bother with the 30B-A3B MoE on a MacBook?
It’s tempting – only 3B parameters active at any moment makes it feel snappy on Apple Silicon, and the tokens-per-second numbers look great. The honest answer: try it on actual work for a week, not toy prompts. For autocomplete and short explanations it’s genuinely good. Ask it to reason through anything non-trivial and you’ll often wish you’d loaded a dense 14B instead, even at half the speed. One founder I know ran it for three days, loved the speed, then noticed every third refactor had a silent logic error. Switched to the 32B dense. The speed difference stopped mattering.
Can I use Qwen with Claude Code or similar agent harnesses?
Yes – most harnesses accept a custom OpenAI-compatible base URL, so you point them at the Ollama endpoint and they treat Qwen like any other model. Tool-calling works because Qwen3 was explicitly trained on function-calling datasets. But “works” doesn’t mean “works reliably on long tasks.” The loop failure modes above are real. Keep step limits aggressive, add file-state checkpoints, and don’t give it more repo surface area than it needs for the specific task. Trust it incrementally, not upfront.
Your next move: spin up Ollama, pull qwen3:8b, fix the num_ctx default, and run the same prompt through both your local endpoint and Claude this week. Ten tasks in, you’ll have a real routing table – not a theoretical one.