Qwen3.6-35B-A3B: What Changed in Qwen's 3B-Active Model

A point release that keeps the parameter count identical is easy to dismiss. Qwen3.6-35B-A3B has the same 35B total and 3B active parameters as Qwen3.5-35B-A3B, the same hybrid attention layout and the same 262,144-token native window. What changed is where the model spends its capability, and the changes are large in some places and slightly negative in others.

Qwen released it on 16 April 2026 as the first open-weight model of the Qwen3.6 generation, under Apache 2.0. The model card says the release "prioritizes stability and real-world utility", and the benchmark selection backs that up: the gains are concentrated in agentic coding.

The release in one table

Qwen's card compares the new model directly against Qwen3.5-35B-A3B. The coding and agent rows move the most:

• Terminal-Bench 2.0: 51.5, up from 40.5
• NL2Repo: 29.4, up from 20.5
• MCPMark: 37.0, up from 27.0
• SWE-bench Pro: 49.5, up from 44.6
• SWE-bench Multilingual: 67.2, up from 60.3
• SWE-bench Verified: 73.4, up from 70.0
• LiveCodeBench v6: 80.4, up from 74.6
• QwenWebBench: 1397, up from 978

An eleven-point gain on Terminal-Bench and nearly nine on NL2Repo, at the same active size, is a substantial change in a model's usefulness inside an agent harness. Vision moved too, more modestly: RefCOCO average 92.0 from 89.2, VideoMMMU 83.7 from 80.4.

One detail is worth noticing. The Qwen3.5 card reports its own 35B-A3B at 69.2 on SWE-bench Verified, while the Qwen3.6 card lists the same baseline at 70.0. Small re-scorings like this are normal when a harness changes, and they are a good reason to compare models on your own tasks rather than across two vendor tables.

Where it went backwards

The card is honest about the regressions, and they are small:

• TAU3-Bench: 67.2 against 68.9
• HLE: 21.4 against 22.4
• MMLU-Pro: 85.2 against 85.3

Broad knowledge is flat, and conversational tool-use with simulated users dipped slightly. If your workload is a customer-service style agent rather than a coding agent, the upgrade case is weaker than the headline coding numbers suggest. Test it before assuming it is better across the board.

preserve_thinking and why agents care

The one functional addition is thinking preservation. By default, like Qwen3.5, the model only keeps the reasoning from the latest user turn and discards earlier reasoning blocks. A new preserve_thinking option keeps reasoning from previous turns in the conversation.

For a multi-turn agent this can matter. When the model's earlier reasoning is thrown away, it has to reconstruct why it chose an approach from the visible actions alone. Keeping it gives continuity, at the cost of a longer context on every turn. Whether that trade is worth it depends on how long your sessions run, which is the subject of agent memory and context management.

Thinking is on by default. Disable it with enable_thinking: false in the chat template arguments; the /think and /nothink soft switches are not supported.

3B active against the dense 27B sibling

Qwen3.6 also shipped a dense 27B model, covered in the Qwen 3.6 guide, which reports 77.2 on SWE-bench Verified. The 35B-A3B reports 73.4. So the dense model scores higher on that benchmark, and the interesting question is what the MoE model offers in exchange.

The answer is compute per token. The 27B runs all 27B parameters for every token; the 35B-A3B runs about 3B. That makes the MoE model far faster to generate from on the same hardware, which matters for agent loops that produce a lot of tokens. The cost is memory: you have to hold 35B parameters rather than 27B.

Rough arithmetic: the Hub lists about 36B parameters in BF16, so 16-bit weights are around 72 GB and a 4-bit build is around a quarter of that, before cache. Pick the 27B if memory is your constraint and quality per task matters most. Pick the 35B-A3B if you have the memory and want throughput.

Hosted, OpenRouter lists the 35B-A3B at $0.15 per million input tokens and $1.00 per million output at the time of writing, with cached input at $0.05.

Settings from the card

• Thinking, general tasks: temperature 1.0, top_p 0.95, top_k 20, presence penalty 1.5.
• Thinking, precise coding: temperature 0.6, presence penalty 0.0.
• Non-thinking: temperature 0.7, top_p 0.8.
• Output length: 32,768 tokens for most queries, 81,920 for hard problems.
• Context: keep at least 128K available to preserve thinking quality. YaRN extends the window to about 1M, with a warning that it may affect short-text performance.
• Serving: the card recommends sglang>=0.5.10 or vllm>=0.19.0, and both can use its multi-token prediction heads for speculative decoding.

Should you upgrade from Qwen3.5-35B-A3B

1. If you run coding agents on the 3.5 model, yes, provisionally. The gains are where agents live. Confirm on ten of your own repository tasks, counting turns to completion as well as pass rate.
2. If you run conversational tool-use agents, run both on your own transcripts first. The small TAU3 regression may or may not show up for you.
3. If you mostly need knowledge answers, there is little to gain.

If you would rather call it hosted than run it, look at the Qwen3.6-Flash guide for the hosted 3.6 tier. How to benchmark LLMs on your own work has the harness for the comparisons above.