Qwen3-Coder-Next Review: Can an 80B MoE Replace Claude Code on a Single RTX 4090?

TL;DR

• Qwen3-Coder-Next is the latest open-weights coding model from Alibaba's Qwen team: 80B total parameters, ~3B activated per token (MoE), 256K context natively (extendable to 1M with YaRN), Apache 2.0.
• On the official SWE-bench Verified subset Qwen reports ~70.7%, putting it within 4–6 points of Claude Sonnet 4.5 (77%) and ahead of GPT-4o-2024-11 (50%). I have not independently re-run the full benchmark suite — numbers below are from the Qwen technical report + replications I could find on GitHub.
• A single RTX 4090 (24GB) can run it usable-fast at ~18–24 tok/s with Q4_K_M GGUF + llama.cpp, ~12–16 tok/s with Q5_K_M, provided you offload the inactive experts to system RAM. You will need ~48–64GB of system RAM for a smooth experience.
• On a Mac M3 Max (64GB unified) you get ~22–28 tok/s at Q4_K_M via MLX/llama.cpp — slightly faster than the 4090 because the experts never leave unified memory.
• Cost honesty: at $0/token locally vs Claude Code's ~$3/M input + $15/M output, a typical agentic coding day (200K input + 30K output tokens) is $1.05 on Claude — which means the 4090 + electricity pays for itself only if you code agentically every day for ~2.5 years. The case for local is privacy + offline + no rate limits, not pure cost.
• The honest verdict: for standalone code generation Qwen3-Coder-Next is the first open model I'd actually keep in my toolchain. For full agentic loops (Claude Code-style file editing, multi-step plans), it's still 1 generation behind — tool-use reliability is the gap, not raw coding ability.

This is the kind of model that makes you re-think whether you still need a closed-source subscription. Below is what I actually ran, what worked, and what didn't.

---

What Qwen3-Coder-Next Actually Is

Qwen3-Coder-Next is the third major iteration of the Qwen-Coder series (after Qwen2.5-Coder and Qwen3-Coder-32B from late 2025). The "Next" variant is the 80B-A3B Mixture-of-Experts model: 80 billion total parameters split across 128 experts, of which only 8 are active per token, yielding ~3B activated parameters. That's the design trick that makes it run on a single 4090 — you only need enough VRAM for the 3B active path plus a routing layer, not the full 80B.

Key spec sheet (from the official Qwen3-Coder-Next model card):

Spec	Value
Total parameters	80B
Activated parameters	~3B
Architecture	MoE (128 experts, top-8 routing)
Native context	262,144 tokens (256K)
Extended context	1,048,576 tokens via YaRN
Vocabulary	152K tokens (multilingual)
License	Apache 2.0
Training cutoff	December 2025
Supported languages	92 programming languages

The 256K native context is the headline number for coding. It means you can paste an entire mid-sized Next.js repo, an Apache Spark module, or a couple hundred kilobytes of design docs into a single prompt and the model can reason across all of it without your toolchain having to chunk and embed. For comparison, Claude Sonnet 4.5 ships with 200K and GPT-4o with 128K — Qwen now leads the open-weights pack on context.

What's actually new vs Qwen3-Coder-32B

Three changes matter:

1. MoE instead of dense. The 32B was a dense model. Going MoE means more total knowledge for the same per-token compute, which is why benchmarks jumped without a corresponding tokens/sec hit.
2. Multi-Token Prediction (MTP) head trained alongside the base model. In coding workflows where the next 2–3 tokens are highly predictable (think closing brackets, repeated keywords in JSON), MTP lets vLLM and recent llama.cpp builds speculate ahead, giving a real 15–25% throughput bump on my Mac. (I covered MTP in detail in Qwen 3.6 Coding Performance: MTP Benchmarks.)
3. Agentic tool-use post-training. The Qwen team explicitly fine-tuned on function-call and file-edit traces. In practice this means Aider and Cline can drive Qwen3-Coder-Next more reliably than Qwen2.5-Coder. It's still not Claude Sonnet 4.5, but the gap closed meaningfully.

SWE-bench Verified: The Numbers I Trust and the Ones I Don't

SWE-bench is the cleanest available proxy for "can this model do real coding work" — agents have to read a real GitHub issue, navigate a real repo, and produce a real patch that passes the project's own test suite. The Verified subset (500 hand-checked issues) is the one to look at; the original full 2,294-issue benchmark has known noise.

Numbers below: Qwen's reported comes from their tech report. Reproduction comes from a community run by @aider-ai on GitHub using the same scaffolding. I have not personally run the full 500-issue suite — the compute cost is non-trivial and I'd rather be honest than fabricate.

Model	SWE-bench Verified (reported)	Reproduction within ±3pt?
Claude Sonnet 4.5 (closed)	77.2%	Yes (Anthropic eval card)
GPT-5-medium (closed)	74.9%	Yes
Qwen3-Coder-Next 80B-A3B	70.7%	Yes, community run reports 68.4%
Qwen3-Coder-32B (dense)	62.5%	Yes
DeepSeek V4 Pro	71.4%	Yes (see DeepSeek V4 Pro Price Cut review)
GPT-4o-2024-11	49.2%	Yes
Aider (Claude Sonnet 4.5 backbone)	79.4%	Yes

Two things stand out for me. First, the gap between best closed model and best open model is now ~6 points on SWE-bench, the smallest it has ever been. Second, Qwen3-Coder-Next and DeepSeek V4 Pro are statistically a tie within reproduction error — but Qwen runs locally on 4090-class hardware, and DeepSeek V4 Pro currently does not (it's a 671B-A37B model that needs a multi-GPU node).

A caveat I haven't seen discussed: SWE-bench is mostly Python. On JavaScript/TypeScript repos my anecdotal experience (more on this below) is that Qwen3-Coder-Next is closer to Claude 4.5 than the benchmark suggests, possibly because the training mix oversampled JS. If anyone has a reproducible TS-only eval suite, I'd love to see numbers.

How I Tested (And What I Couldn't)

This is the section I want to be transparent about. I do not own an RTX 4090 — my daily driver is a Mac Studio M3 Max (64GB unified) and a Linux workstation with a single RTX 3090 (24GB). For 4090-specific numbers I am citing community runs, not claiming my own.

What I personally ran:

• MLX 0.21 on M3 Max 64GB with the official Qwen3-Coder-Next-80B-A3B-Instruct-MLX-4bit weights. Setup: pip install mlx-lm, mlx_lm.generate --model Qwen/Qwen3-Coder-Next-80B-A3B-Instruct-MLX-4bit ...
• llama.cpp build b5400 (Q4_K_M GGUF from bartowski/Qwen3-Coder-Next-80B-A3B-Instruct-GGUF) on the same Mac and on the 3090 box.
• Aider 0.86 with --model openai/qwen3-coder-next pointed at a local llama-server instance.
• Cline 3.30 inside VS Code, same local endpoint.

What I'm extrapolating from others (clearly cited where used):

• RTX 4090 tokens/sec: I'm relying on three independent reports — a LocalLLaMA thread from early May 2026, bartowski's GGUF README, and llama.cpp issue #11200 — that converge on 18–24 tok/s at Q4_K_M with experts offloaded to system RAM.
• Full SWE-bench Verified replication: I trust the Aider community's run because their methodology is public.

Mac M3 Max 64GB results (my own, run 2026-05-22 to 2026-05-25)

Setup: 8-core P + 4-core E + 40-core GPU, macOS 15.4, no other large processes running, model loaded in MLX 4-bit.

Workload	Tokens/sec	First-token latency	Notes
Single-file Python edit (200 tok in, 400 tok out)	27	0.6s	Best case, model is warm
Multi-file refactor via Aider (8K in, 1.2K out)	22	1.4s	Realistic agentic load
Large repo context (64K in, 800 tok out)	18	6.1s	Context fill dominates
Pasted-doc analysis (140K in, 600 tok out)	14	18s	YaRN scaling kicks in

For comparison, the same workloads on the same Mac with Qwen3-Coder-32B-Dense Q5_K_M ran at 11–14 tok/s — so the MoE design genuinely buys you ~2× throughput at this scale.

Reported RTX 4090 results (from community, NOT mine)

Workload	Tokens/sec	Source
Q4_K_M, 8K context	22–24	LocalLLaMA, bartowski
Q5_K_M, 8K context	14–16	llama.cpp issue thread
Q4_K_M, 64K context	9–11	LocalLLaMA
Q4_K_M, 200K+ context	4–6	Single report, treat as rough

The 4090 results require CPU offloading of inactive experts — the model is 80B total, only 3B active. llama.cpp's --n-gpu-layers flag with the right tuning keeps the attention layers and a chunk of routing on GPU while inactive experts sit in 48–64GB of system DDR5. On DDR4 systems the numbers drop by ~30%.

Real-World Coding Tasks: What It's Actually Like

Benchmarks are signal, but they don't tell you what it feels like to use a model for 8 hours. Over the past two weeks I've been running Qwen3-Coder-Next as my primary local model on three real tasks:

Task 1: Adding a calendar webhook handler to a Next.js 15 app

Aider + Qwen3-Coder-Next was given a 12K-token spec, the existing src/app/api/ directory, and access to package.json. It needed to add a new route, wire up Zod validation, and add an integration test.

What worked: First-pass code compiled. Zod schema was correct. Test scaffold matched the existing pattern in the repo.

What didn't: It invented a @vercel/edge-config import that I'd never installed. When I pointed this out it apologized and switched to the existing lib/redis.ts, but only after I named the file. Claude Code on the same task would have read package.json first.

Verdict: B+. Code quality fine, agentic discipline weaker.

Task 2: Debugging a Python data pipeline with a 30K-line stack trace

Pasted the stack trace plus three relevant .py files (~50K tokens total) into a single prompt and asked "what's the root cause and what's the minimal fix?"

What worked: Correctly identified the issue (a pandas .apply with axis=1 on a category dtype was silently downcasting). Suggested fix was correct.

What didn't: Took 22 seconds to first token. The 64K context fill on my Mac is just not as snappy as a cloud API.

Verdict: A-. This is exactly the use case where local + 256K context shines. Privacy matters here — this was internal data I would not want hitting an API.

Task 3: Translating a 1.2KLOC React component from JS to TS

Pure code-rewrite task. Easy mode for any modern coding model.

What worked: Output was clean, types were sensible (not over-engineered with any), JSDoc preserved.

What didn't: Nothing notable.

Verdict: A. I would happily use it for this kind of mechanical refactor every day. (Cursor at $20/mo can do this too, but with Qwen there's no per-request thinking about cost. See my Cursor AI Pricing breakdown.)

The Real Comparison: Qwen3-Coder-Next vs Claude Code vs DeepSeek V4

Tabular form, opinionated:

Dimension	Qwen3-Coder-Next	Claude Code (Sonnet 4.5)	DeepSeek V4 Pro
Raw coding quality	8.5/10	9.5/10	8.7/10
Agentic tool-use	7/10	9.5/10	8/10
Long-context reasoning	9/10 (256K native)	8/10 (200K)	7/10 (128K)
Local execution feasibility	Yes (24GB VRAM)	No	No (671B)
Price for 200K in + 30K out	$0 (electricity)	~$1.05	~$0.20
Privacy	Total (local)	Trust Anthropic	Trust DeepSeek
Speed (4090, agentic load)	18 tok/s	60+ tok/s (cloud)	50+ tok/s (cloud)
Best for	Privacy-sensitive work, indie devs offline	Complex agentic workflows, max quality	Cheap cloud coding

If I had to summarize in one line per scenario:

• Closed-source contractor / startup with sensitive code → Qwen3-Coder-Next, local. The $1.05/day saved is nothing; the IP protection is everything.
• Solo indie dev shipping fast on a side project → Claude Code subscription, still. Tool-use reliability matters more than cost here.
• Volume cloud coding (think: bulk PR triage, doc generation) → DeepSeek V4 Pro. Cheapest per token by a wide margin.

(I went deeper on the agentic-loop side in Claude Code vs Aider — most of what I said about Aider applies here, just swap in Qwen as the backbone.)

Setup Walkthrough: 4090 + Ollama (The 30-Minute Path)

If you want to try this on a 4090 today, the easiest path is Ollama + a 4-bit quant. Caveat: Ollama lags llama.cpp on bleeding-edge models by 1–2 weeks. As of writing the 80B-A3B GGUF is up on Ollama's registry.

# 1. Install Ollama (skip if you have it)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Pull the 4-bit quant (~45 GB download)
ollama pull qwen3-coder-next:80b-a3b-q4_K_M

# 3. Verify it runs
ollama run qwen3-coder-next:80b-a3b-q4_K_M "Write a Python function to flatten a nested dict"

# 4. Bridge to Aider via the OpenAI-compatible endpoint
pip install aider-chat
aider --model openai/qwen3-coder-next:80b-a3b-q4_K_M \
      --openai-api-base http://localhost:11434/v1 \
      --openai-api-key ollama

Expected first run: 3 minutes to load weights into VRAM + system RAM, then queries respond in 1–6 seconds for short prompts. If you get OOM on the 4090, drop to qwen3-coder-next:80b-a3b-q3_K_S (38GB) — quality dips slightly but it still beats Qwen3-Coder-32B-Dense.

For Cline in VS Code, point its custom API endpoint at the same http://localhost:11434/v1 and select model qwen3-coder-next:80b-a3b-q4_K_M. Cline does some prompt manipulation that confuses smaller models but Qwen handles it fine in my testing.

Where It Falls Short (and Why I'm Still Excited)

The honest list:

1. Tool-use is the gap. When Aider asks the model to emit a diff in a specific format, Qwen3-Coder-Next gets it right ~88% of the time vs Claude's ~98%. Those last 10 percentage points are what makes Claude Code feel like an autopilot and Qwen feel like a copilot.
2. First-token latency on large contexts is rough. 18 seconds to first token on a 140K context is fine if you're thinking, painful if you're flow-coding.
3. The "vibes" of generated code feel slightly more textbook-y than Claude. Hard to quantify. Claude's code reads like it came from someone who has shipped to production; Qwen's reads like someone who has read a lot of code on production.
4. MoE means inference engines need to handle expert routing. llama.cpp, MLX, vLLM all do — but if you're using something exotic, check support first.

And still, I'm excited because we are watching the open-source frontier close the gap fast. Qwen2.5-Coder was 15 points behind GPT-4o on coding 18 months ago. Qwen3-Coder-Next is 4 points ahead. At this rate of improvement, by mid-2027 the local-first option will be obviously superior for most coding work, with cloud reserved for the hardest agentic loops.

If you're already paying $20/mo for Cursor or $200/mo for Claude Max, run Qwen3-Coder-Next for a week before you renew. The break-even math doesn't matter — the question is whether the quality is good enough that you stop reaching for the cloud option by default. For about 60% of my work, it now is.

FAQ

Can Qwen3-Coder-Next really replace Claude Code for daily coding?

For pure code generation, yes — quality is within 5% on real tasks. For agentic workflows where the model autonomously edits multiple files, runs tests, and iterates, Claude Code is still 1 generation ahead. The honest answer: Qwen replaces Claude for about 60% of typical solo-dev work as of mid-2026.

What's the minimum hardware to run Qwen3-Coder-Next at usable speeds?

24GB VRAM (RTX 3090, 4090, 7900XTX) plus 48GB+ system RAM for 4-bit quant. Mac Apple Silicon with 64GB+ unified memory works well. Lower spec setups can run smaller Qwen3-Coder variants (8B, 14B, 32B-dense) instead.

How does the 256K context compare to Claude's 200K in practice?

Native 256K means you don't need RAG for most codebases under 1MB. For very large repos extend with YaRN to 1M tokens — quality holds reasonably well to ~512K based on Qwen's needle-in-haystack tests. Claude's 200K is sufficient for most tasks but you'll hit it on large repos faster.

Is the SWE-bench score of 70.7% trustworthy?

Reasonably. Qwen's published number was independently reproduced within ~2 points by community runs using the same scaffolding. SWE-bench is mostly Python — TypeScript/JavaScript performance may differ. I have not personally re-run the full suite due to compute cost.

What's the cost difference vs Claude Code over a year?

Heavy agentic coding day (200K input + 30K output tokens) costs $1.05 on Claude Sonnet 4.5. That's ~$380/year for daily use. A used RTX 4090 setup is ~$1800 + electricity ($60/year). Break-even at year 5 for pure cost — but you also get privacy, offline, no rate limits.

Does Qwen3-Coder-Next support tool calling for Cline / Aider / Continue?

Yes. The Instruct variant is post-trained on function-call and file-edit traces. Reliability is ~88% on diff-emission tasks vs Claude's ~98%. Works with the OpenAI-compatible endpoint that Ollama and llama-server expose.

What quantization should I use on an RTX 4090?

Q4_K_M (45GB on disk) is the sweet spot — quality loss vs FP16 is < 2 points on SWE-bench, throughput is 18–24 tok/s. Q5_K_M (53GB) gains 1 point quality but loses 30% throughput. Q3_K_S (38GB) is the fallback for tighter VRAM but I'd avoid it for production work.

Is this Apache 2.0 license really commercial-friendly?

Yes. Apache 2.0 permits commercial use, modification, and distribution. No revenue cap, no "acceptable use policy" escape hatch like some other "open" models. You can fine-tune, deploy, and ship Qwen3-Coder-Next in a product without paying Alibaba anything.

What I'd Do If I Were Starting Today

1. Keep your Claude Code subscription for another month — don't cancel yet.
2. Set up Qwen3-Coder-Next locally this weekend (Ollama path is 30 minutes).
3. For one full week, default to Qwen and only fall back to Claude when it fails.
4. Track which tasks you fell back on. If the list is mostly "complex multi-file agentic edits," renew Claude. If it's mostly "ah, I just wanted Claude's UX," consider switching primary.

I'll publish a 30-day follow-up with my own fallback rate. If you're running this setup, I'd genuinely like to compare notes — what works on your hardware, where it falls down for you.

---

Jim Liu has been shipping AI-assisted code across OpenAIToolsHub, LowRiskTradeSmart, and a portfolio of indie sites since 2023. He writes the Qwen 3.6 Coding MTP Benchmarks, Claude Code vs Aider, Cursor vs Windsurf, and DeepSeek V4 Pro Price Cut Review deep-dives.