This article was originally published on aicoderscope.com
TL;DR: Qwen3-Coder-Next (80B total, 3B active) scores 70.6% on SWE-bench Verified — compelling for an open-weight model — but the leaderboard has moved significantly since its February launch. Its real value proposition in May 2026 is cost: at $0.11/M input tokens, it's the cheapest credible coding agent API by a wide margin, and on local hardware it runs on a single 24GB GPU with system RAM offloading.
| Qwen3-Coder-Next API | Claude Sonnet 4.6 API | Qwen3-Coder-Next Local | |
|---|---|---|---|
| Best for | Budget agentic loops, high-volume Cline/Aider runs | Hard reasoning, novel architecture problems | Privacy-first teams, zero API cost |
| Price | $0.11/M in · $0.80/M out | $3/M in · $15/M out | Hardware cost only |
| SWE-bench Verified | 70.6% | ~77% | Same model |
| The catch | 7th among open-weight models in May 2026 | 27× more expensive per input token | Needs 46GB+ VRAM or 24GB GPU + system RAM offload |
Honest take: If you're running Cline or Aider with aggressive token budgets and your tasks are in the "refactor this module / fix this bug" range, Qwen3-Coder-Next at $0.11/M input is the best dollar-per-task ratio on the market right now. For greenfield architecture work or subtle multi-file bugs, the Claude Sonnet 4.6 gap at 70.6% vs 77% SWE-bench is real enough to matter.
What Qwen3-Coder-Next actually is
Alibaba's Qwen team released Qwen3-Coder-Next on February 4, 2026. The model is built on Qwen3-Next-80B-A3B-Base — 80 billion total parameters, 3 billion active per forward pass. That ratio is the point of the whole exercise.
Standard dense models like DeepSeek-V3.2 (73.0% SWE-bench) or Kimi K2.5 (76.8%) activate all their parameters on every token. Qwen3-Coder-Next uses a hybrid attention + Mixture-of-Experts (MoE) architecture: most of the 80B parameters sit in expert layers that route tokens to only the relevant slice of the network. The result is that your hardware does roughly the same arithmetic as a 3B dense model on each token while the model can draw on the breadth of a much larger system.
The training recipe leans heavily on agentic data: 800,000 verifiable coding tasks mined from real GitHub pull requests, each paired with an executable environment for reinforcement learning. The goal was not just code completion but multi-turn tool use — the kind of 50-300 sequential actions you need when running an autonomous coding agent.
The model supports 256K tokens of context natively (extendable to 1M via YaRN), covers 358 coding languages, and ships under an Apache 2.0 license, meaning you can run it commercially without restrictions.
Benchmark reality check: where 70.6% actually stands
When Qwen3-Coder-Next dropped in February 2026 it set a new efficiency record: the highest SWE-bench Verified score from any open-weight model with fewer than 10B active parameters. That was genuinely notable.
By May 2026, the leaderboard looks different:
| Model | SWE-bench Verified | Type |
|---|---|---|
| MiniMax M2.5 | 80.2% | Open-weight |
| MiMo-V2-Pro | 78.0% | Open-weight |
| GLM-5 | 77.8% | Open-weight |
| Claude Sonnet 4.5 | 77.2% | Closed |
| Kimi K2.5 | 76.8% | Open-weight |
| GLM-4.7 | 73.8% | Open-weight |
| DeepSeek-V3.2 | 73.0% | Open-weight |
| Qwen3-Coder-Next | 70.6% | Open-weight |
Qwen3-Coder-Next is no longer the open-weight frontrunner — it's seventh among open models. That's fine and expected; the AI coding space moves fast. The question is whether 70.6% is good enough for your actual workloads.
With different agent scaffolds, the score improves slightly: 71.1% with MiniSWE-Agent and 71.3% with OpenHands. On SWE-bench Multilingual (which tests non-English repos) it hits 62.8%, and on SWE-bench Pro (the harder curated subset) it reaches 44.3%. The model performs well on routine maintenance tasks — bug fixes, refactors, test generation — and less well on novel, architecturally complex work where top models separate themselves.
The practical translation: Qwen3-Coder-Next handles the 80% of coding tasks that fit the "understand the codebase → make a targeted change → run tests" pattern. It's less reliable when the fix requires understanding an undocumented interaction between three subsystems or when you need it to design a new API surface from scratch.
API pricing: the actual competitive advantage
This is where the model earns its place in a 2026 coding stack.
Qwen3-Coder-Next API through DashScope (Alibaba Cloud's model platform) or OpenRouter costs $0.11 per million input tokens and $0.80 per million output tokens. To put that in perspective:
| Model | Input (per M tokens) | Output (per M tokens) |
|---|---|---|
| Qwen3-Coder-Next | $0.11 | $0.80 |
| Qwen3-Coder-480B-A35B | higher | higher |
| Claude Sonnet 4.6 | $3.00 | $15.00 |
| Claude Sonnet 4.6 (batch) | $1.50 | $7.50 |
| GPT-4o (est.) | $2.50 | $10.00 |
At those rates, you can run approximately 9 million input tokens for the price of a single Cursor Pro month ($20). A typical Cline agentic session that rewrites a 500-line module burns roughly 50,000–150,000 input tokens. That's $0.005–$0.017 per session. You could run 1,200 such sessions per dollar.
This changes the economics of autonomous coding loops. With Claude Sonnet 4.6 at $3/M input, you'd spend $0.45 per 150K-token session — which adds up fast if you're running an agentic loop 20+ times per day on a complex codebase. With Qwen3-Coder-Next, the same volume costs $0.02. Most developers burning Claude tokens on repetitive refactoring or test generation should seriously evaluate whether the quality delta justifies the 27× price gap.
The caveats: DashScope has a free tier with monthly token grants but rate limits that make it unsuitable for heavy agentic use without a paid tier. OpenRouter routing introduces occasional latency variance. And the model's 256K context means you'll need to be selective on very large codebases — the 1M extension via YaRN is available but adds latency.
Local deployment: hardware and what you actually get
Qwen3-Coder-Next's MoE architecture makes it uniquely practical for local deployment compared to equivalently-scoring dense models.
VRAM requirements by quantization:
| Quantization | VRAM / RAM needed | Notes |
|---|---|---|
| Q8_0 | ~85 GB | Full quality; needs 2× RTX 4090 or a workstation GPU |
| Q4_K_M | ~46–52 GB | Recommended sweet spot; fits 24GB GPU + 24+ GB system RAM offload |
| Q2_XL | ~30 GB | Noticeable quality drop on complex reasoning |
On a single RTX 4090 (24 GB VRAM) with Q4_K_M quantization and system RAM offload, expect 40–60+ tokens per second at typical coding context lengths. That's fast enough for interactive use in Cline or Aider — you won't be watching a cursor blink.
For practical local setup, three tools handle this today:
Ollama (simplest):
ollama run qwen3-coder-next
Ollama handles the GGUF conversion and layer offloading automatically. It exposes an OpenAI-compatible endpoint at localhost:11434/v1.
llama.cpp (most control):
Download the GGUF from unsloth/Qwen3-Coder-Next-GGUF on Hugging Face. Update llama.cpp to at least the version that ships with Qwen3 hybrid attention support — older builds have a known key computation bug. Then:
llama-server -m qwen3-coder-next-q4_k_m.gguf --n-gpu-layers 60 --ctx-size 65536
vLLM (best throughput for shared / multi-user setups):
vllm serve Qwen/Qwen3-Coder-Next \
--port 8000 \
--tensor-parallel-size 2 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder
The --tool-call-parser qwen3_coder flag matters for agentic use — without it, tool call formatting degrades and your Cline sessions will produce malformed JSON on function calls.
If you're building the hardware setup for this, see our local LLM hardware guide at runaihome.com for current GPU options in the 24–48 GB VRAM tier.
Top comments (0)