Qwen3-Next 80B A3B Thinking: Cheap Reasoning, Long Traces

Reasoning models are usually sold on quality and paid for in tokens. Qwen3-Next-80B-A3B-Thinking makes the second half of that trade cheaper in an unusual way: rather than shrinking the model, it shrinks the per-token compute, with only about 3B of its 80B parameters active and most of its attention layers swapped for a linear-time variant.

That does not make the reasoning trace shorter. Qwen's own model card warns that thinking output may run longer than in earlier Qwen3 releases. What changes is the cost of each of those tokens, which is the part that compounds when a model writes several thousand of them before answering.

What you are getting

The Thinking edition shares its architecture with the Qwen3-Next 80B Instruct release: 48 layers, three Gated DeltaNet layers to every gated full-attention layer, and a 512-expert MoE with 10 routed and 1 shared expert active per token. Context is 262,144 tokens natively, and the card documents YaRN scaling to about 1M. Weights are Apache-2.0.

The difference is post-training. This edition always reasons first. The card states that it supports thinking mode only, so if you want a direct answer you deploy the Instruct model instead.

The parsing gotcha

The first thing to break in a new integration is usually the output parser. The chat template inserts the opening <think> tag itself, so the model's raw completion often contains only the closing </think>. Qwen's card calls this expected behaviour.

If your code looks for a matched pair of tags to split reasoning from answer, it will either fail or return the whole trace as the answer. Split on the closing tag instead, and treat everything before it as reasoning. Most OpenAI-compatible servers with a reasoning parser enabled do this for you and return the trace in a separate field, but check before you build on it, because a trace that leaks into a user-facing reply is a bad first impression.

Where it sits on Qwen's table

Qwen compares it against its own thinking models and against Gemini 2.5 Flash in thinking mode:

• AIME25: 87.8, against 72.0 for Gemini 2.5 Flash Thinking and 92.3 for Qwen3-235B-A22B-Thinking-2507
• HMMT25: 73.9, against 64.2 and 83.9
• LiveCodeBench v6: 68.7, against 61.2 and 74.1
• MMLU-Pro: 82.7, against 81.9 and 84.4
• GPQA: 77.2, where Gemini 2.5 Flash leads at 82.8

So it beats the Google model on most of the maths and code rows and loses on the graduate-science one, while the 235B Thinking model stays ahead on all five. These are vendor-run numbers, and benchmark maths has a contamination problem worth knowing about; benchmark contamination explained covers why a high AIME score is weaker evidence than it looks.

The comparison with its own Instruct sibling is the more practical one. On AIME25 the Thinking edition scores 87.8 to Instruct's 69.5, and on LiveCodeBench 68.7 to 56.6. On Arena-Hard v2, a chat-preference benchmark, the Instruct model's card reports the higher figure. Thinking buys depth on hard, checkable problems, not a better conversation.

Budgeting output tokens

Qwen recommends a 32,768-token output budget for most queries and 81,920 for the hardest maths and programming problems. Those numbers are the real cost model. A question that a non-thinking model answers in a few hundred tokens can cost many times that here, and you pay for every hidden token.

OpenRouter listed the model at $0.15 input and $1.20 output per million tokens at the time of writing, close to the Instruct edition's per-token rate. The price difference between the two is therefore almost entirely volume, and it shows up only once you measure output tokens per task. The token cost of reasoning models walks through that arithmetic.

Two practical controls follow. Set a hard max_tokens that matches the task class rather than leaving the provider maximum in place, and log reasoning length separately from answer length so a runaway trace is visible. Recommended sampling is temperature 0.6, top-p 0.95, top-k 20; Qwen notes that a presence penalty above zero can reduce repetition but may cause language mixing.

Tool calls inside a reasoning loop

Qwen describes the model as strong at tool calling and recommends its Qwen-Agent framework, which wraps the tool-call templates and parsers. The card goes further: when serving through an OpenAI-compatible endpoint, it suggests disabling the server's own reasoning and tool-call parsing and letting Qwen-Agent handle both.

That is a hint that tool-call formatting inside a long reasoning trace is fragile across serving stacks. If you use your own agent loop instead, test the specific combination you will ship: same server version, same parser flags, a dozen multi-step tool tasks. Malformed calls tend to show up only after several turns.

When to pick it

• Pick Thinking for maths, algorithmic code and multi-step analysis where a wrong answer is expensive and you can verify the result.
• Pick the Instruct edition for chat, extraction, summarisation and anything where latency matters more than depth.
• Escalate to a larger thinking model when your own tests show it failing the hardest tail of tasks; Qwen's table shows a consistent gap to the 235B on the maths and code rows, though not on every agent row.

The cleanest test is to run the same twenty verifiable problems through both Qwen3-Next editions and record accuracy, output tokens and wall-clock time per problem. If Thinking only wins on three of them, route just that class to it and keep the rest on Instruct.