Qwen3.5-Coder-480B vs DeepSeek-V4 2026: SWE-Bench Pro Tested

For the first time, the gap between an openly downloadable coding model and a closed frontier one is small enough that the build-vs-buy conversation is genuinely live. Alibaba’s Qwen team released Qwen3.5-Coder-480B-A35B under Apache 2.0 this week, and the Qwen3.5-Coder-480B benchmarks — particularly on SWE-Bench Pro and Terminal-Bench — land within a few points of the closed models most teams currently pay per-token for. DeepSeek-V4’s coding checkpoint arrived in the same window, so there are now two credible self-hostable options rather than one interesting outlier. If you run a coding agent at any meaningful volume, the math on your inference bill changed this week.

What’s new in the Qwen3.5-Coder-480B benchmarks

Qwen3.5-Coder-480B-A35B is a mixture-of-experts model: 480 billion total parameters, roughly 35 billion active per token. That ratio is the whole story. You get the knowledge capacity of a very large dense model at the inference cost profile of something closer to a 35B, which makes self-hosting arithmetically defensible instead of a vanity project. The license is Apache 2.0, not a bespoke “open-ish” community license with usage thresholds and naming requirements. You can fine-tune it, serve it commercially, and ship it inside a product without a lawyer reading the terms twice.

The headline numbers are SWE-Bench Pro and Terminal-Bench. SWE-Bench Pro matters more than the original SWE-Bench Verified at this point. Verified has been thoroughly saturated and contaminated; the Pro variant uses harder, more recent, copyleft-and-commercial repository tasks chosen specifically to resist memorization. A model scoring well there is doing something closer to actual multi-file reasoning. Terminal-Bench supplies the complementary signal: it measures whether a model can operate a shell over a long horizon, recover from its own failed commands, and finish a task without a human unsticking it. Coding agents live or die on that second capability, and it historically separated open weights from closed frontier models by an embarrassing margin.

DeepSeek-V4’s coding checkpoint landed days apart, continuing the pattern DeepSeek established with V3: aggressive MoE sparsity, heavy reinforcement learning on verifiable coding and math rewards, and a context window long enough to hold a real repository slice. The DeepSeek-V4 coding benchmark results are competitive with Qwen3.5-Coder on agentic tasks, but the two models differ in character. DeepSeek runs stronger on tight algorithmic reasoning and terser in its output; Qwen3.5-Coder runs stronger on long-horizon tool use and multi-file edits. That divergence is useful. Two open models with different failure modes let you route between them rather than accept one model’s weaknesses as a fact of life.

Why it matters

• The cost floor collapses at volume. A coding agent burning tokens on repository context, tool call loops, and retries is a fundamentally different economic object than a chat product. Past roughly a few hundred million tokens a month, amortized GPU cost for a 35B-active MoE beats per-token API pricing, often by a large multiple.
• Apache 2.0 LLM self-hosting removes the compliance conversation. Regulated industries, air-gapped environments, and customers with data residency clauses have been structurally locked out of frontier coding agents. A permissive license plus downloadable weights unblocks all three at once.
• MoE active parameters change the hardware conversation. 35B active means you serve from VRAM-resident experts at a manageable per-token compute cost. The constraint shifts from FLOPs to memory capacity and interconnect — a different, and generally cheaper, procurement problem.
• Benchmark contamination pressure is now a feature. Vendors competing on SWE-Bench Pro results in 2026 rather than saturated older suites means published numbers correlate better with what you’ll experience on your codebase.
• Model routing becomes the default architecture. With two strong open-weight coding models plus closed options, the sensible design is a router: cheap local model for bulk edits and test generation, escalation to a frontier model only on tasks that fail verification.
• Fine-tuning is back on the table. You cannot fine-tune a closed frontier model on your monorepo’s conventions in any deep sense. You can LoRA an Apache 2.0 480B MoE on your internal APIs, and that usually beats prompt engineering for codebase-specific behavior.

How to use it today

1. Pull the weights. The full BF16 checkpoint is large; plan storage before you start the download.

   pip install -U "huggingface_hub[cli]"
   
   hf download Qwen/Qwen3.5-Coder-480B-A35B-Instruct \
     --local-dir ./qwen3.5-coder-480b \
     --max-workers 8

2. Serve it with vLLM. Tensor parallelism across eight high-memory GPUs is the standard configuration for the BF16 weights. Expert parallelism is what makes the MoE routing efficient rather than a bottleneck.

   vllm serve ./qwen3.5-coder-480b \
     --tensor-parallel-size 8 \
     --enable-expert-parallel \
     --max-model-len 262144 \
     --enable-auto-tool-choice \
     --tool-call-parser qwen3_coder \
     --served-model-name qwen3.5-coder \
     --port 8000

   If you do not have eight GPUs, start with an FP8 or AWQ quantization. The quality drop on coding tasks is measurably smaller than on open-ended generation, and it roughly halves your memory footprint.

3. Hit it with the OpenAI-compatible API. Nothing in your existing client code needs to change beyond the base URL.

   curl http://localhost:8000/v1/chat/completions \
     -H "Content-Type: application/json" \
     -d '{
       "model": "qwen3.5-coder",
       "messages": [
         {"role": "system", "content": "You are a coding agent. Use tools to inspect the repository before editing. Never guess at file contents."},
         {"role": "user", "content": "The auth middleware drops the request id on 401 responses. Find it and fix it."}
       ],
       "temperature": 0.2,
       "top_p": 0.8,
       "max_tokens": 8192
     }'

4. Wire it into your agent loop. Tool calling is the part that most often breaks on a self-hosted swap. Verify the parser emits structured calls before you trust the model in production.

   from openai import OpenAI
   
   client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")
   
   TOOLS = [{
       "type": "function",
       "function": {
           "name": "run_shell",
           "description": "Execute a shell command in the repository root and return stdout/stderr.",
           "parameters": {
               "type": "object",
               "properties": {"cmd": {"type": "string"}},
               "required": ["cmd"],
           },
       },
   }]
   
   resp = client.chat.completions.create(
       model="qwen3.5-coder",
       messages=[{"role": "user", "content": "Run the test suite and summarize failures."}],
       tools=TOOLS,
       tool_choice="auto",
       temperature=0.2,
   )
   print(resp.choices[0].message.tool_calls)

5. Benchmark on your own repository, not theirs. Published SWE-Bench Pro results tell you the model is in the right class. They do not tell you it handles your build system. Build a held-out set of twenty to fifty real merged PRs from your history, replay them as agent tasks, and score on whether tests pass.

   git log --merges --since="6 months ago" --format="%H %s" \
     | head -50 > eval/candidate_prs.txt
   
   python eval/replay.py \
     --model qwen3.5-coder \
     --endpoint http://localhost:8000/v1 \
     --tasks eval/candidate_prs.txt \
     --verify "pytest -x -q" \
     --out eval/results_qwen.json

6. Add a router before you commit. Run the open model first, verify with your test suite, and escalate only on failure. This is where the cost savings actually materialize.

   PRIMARY_MODEL=qwen3.5-coder
   FALLBACK_MODEL=deepseek-v4-coder
   ESCALATION_MODEL=closed-frontier-api
   VERIFY_CMD="pytest -x -q"
   MAX_ATTEMPTS_PER_TIER=2

How Qwen3.5-Coder-480B benchmarks compare

Dimension	Qwen3.5-Coder-480B-A35B	DeepSeek-V4 (coding)	Closed frontier coding models
License	Apache 2.0	Permissive, model-specific terms	Proprietary API only
Weights downloadable	Yes	Yes	No
Architecture	MoE, ~480B total / ~35B active	MoE, high sparsity ratio	Undisclosed
SWE-Bench Pro	Within a few points of frontier	Competitive, slightly behind on multi-file	Current leader
Terminal-Bench score	Strongest open-weight result to date	Strong, more brittle on long recovery chains	Current leader
Relative strength	Long-horizon agentic tool use, multi-file edits	Tight algorithmic reasoning, terse output	Broad reliability, fewest hard failures
Fine-tuning	Full control (LoRA or full FT)	Full control	Limited or unavailable
Cost at high volume	Amortized GPU cost	Amortized GPU cost	Per-token, scales linearly
Cost at low volume	Poor — GPUs sit idle	Poor — GPUs sit idle	Excellent
Data residency	Fully controlled	Fully controlled	Vendor-dependent

The honest summary of this open weight coding model comparison: closed frontier models still win on raw reliability, and the gap is real if narrow. What changed is that “narrow” now means the open models clear the bar for most agent tasks in a typical codebase — refactors, test generation, dependency bumps, bug fixes with a reproducing test. You escalate the hard ten percent. You stop paying frontier prices for the easy ninety.

What’s next

Watch for the quantized and distilled variants, which usually appear within a few weeks of a release like this and matter more for adoption than the flagship weights do. A 480B MoE requires serious hardware; an FP8 variant that fits comfortably on a single high-memory node is what actually gets deployed inside most engineering organizations. The community quantization ecosystem has gotten fast and reliable, and the quality delta on coding tasks has narrowed with each generation of quantization method.

The second thing to watch is whether the benchmark story holds up under independent replication. Vendor-reported SWE-Bench Pro results 2026 are not neutral artifacts — harness configuration, retry budgets, and scaffolding choices move scores substantially. Give it a few weeks for third-party evaluation harnesses to publish their own runs, and weight those more heavily than the launch blog post. The same caution applies to the DeepSeek-V4 coding benchmark figures.

Longer term, the interesting structural question is what happens to per-token pricing for coding specifically. If two openly licensed models can handle the bulk of agentic coding work, the closed providers’ pricing power concentrates in the hardest tasks and in the convenience of not operating inference infrastructure. That is still a real business — most teams should not run GPUs — but it is a narrower one than it was a month ago. Expect price movement, more aggressive free tiers for coding agents, and a next round of closed releases leaning hard on capabilities that are genuinely difficult to replicate at 35B active parameters.

Frequently Asked Questions

What hardware do I need to self-host Qwen3.5-Coder-480B?

For BF16 weights, plan on eight GPUs with 80GB of memory each, connected with high-bandwidth interconnect. The MoE active parameter count of roughly 35B keeps per-token compute manageable, but you still need enough aggregate VRAM to hold all 480B parameters resident. FP8 or AWQ quantization roughly halves that requirement and is the more realistic starting point for most teams.

Is Apache 2.0 LLM self-hosting actually unrestricted for commercial use?

Apache 2.0 is a standard permissive open source license — commercial use, modification, redistribution, and patent grant are all included, with attribution and a notice requirement. It carries no user-count thresholds, revenue caps, or naming obligations. Still have your counsel read the model card for any separate acceptable-use policy layered on top, which is a common pattern.

Why does SWE-Bench Pro matter more than the older SWE-Bench benchmarks?

The original SWE-Bench Verified set has been heavily saturated, and its tasks are drawn from public repositories that almost certainly appear in training data. SWE-Bench Pro uses harder, more recent tasks from repositories selected to reduce contamination, with more multi-file edits. Scores are lower across the board and correlate better with real-world agent performance.

Should I pick Qwen3.5-Coder or DeepSeek-V4?

Run both against your own evaluation set before deciding — they have different failure modes. In broad terms, Qwen3.5-Coder currently looks stronger on long-horizon agentic work and multi-file edits, which is where its Terminal-Bench score shows up; DeepSeek-V4 is often sharper on contained algorithmic problems. If you have the capacity, serving both and routing between them beats picking one.

Does self-hosting actually save money?

Only at volume. GPU capacity is a fixed cost whether you use it or not, so the break-even depends entirely on sustained utilization. Below roughly a few hundred million tokens monthly, API pricing generally wins. Above it, self-hosting wins and the margin widens. Compliance and data residency requirements can justify self-hosting well below that threshold regardless of cost.

Can I fine-tune it on my own codebase?

Yes, and this is one of the strongest arguments for open weights. LoRA adapters on a model this size are practical and let you encode internal API conventions, framework idioms, and house style in a way prompt engineering cannot match reliably. Keep the base model and adapter separate so you can rebase onto future checkpoints without redoing the work.