Qwen3 30B A3B Thinking 2507: Reasoning at 3.3B Active

A reasoning model that activates only 3.3B parameters per token sounds like a contradiction. Reasoning is supposed to need scale. Qwen3-30B-A3B-Thinking-2507, released on 31 July 2025, is a fair test of that assumption, because it buys its quality with token count rather than parameter count. That is a useful trade to understand, and a dangerous one to deploy without measuring.

This is the thinking half of the 2507 split. Its sibling, Qwen3 30B A3B Instruct 2507, never reasons; the original Qwen3 30B A3B could do both from one checkpoint.

What thinking-only means in practice

The model always reasons before it answers. There is no switch: enable_thinking is no longer needed, and the /no_think soft switch from the original release does not apply. If a task does not benefit from reasoning, this is the wrong checkpoint, not a checkpoint you should try to tame.

Qwen also notes that this version has an increased thinking length compared with the original. That is the headline in one phrase. The architecture is unchanged (30.5B total, 3.3B active, 48 layers, 128 experts with 8 routed per token) and the context window moved to 262,144 tokens natively, so most of the quality gain comes from training the model to think longer and better.

Where the extra tokens pay

Qwen's comparison against the original model in thinking mode, with Gemini 2.5 Flash in thinking mode as the outside reference:

• AIME25: 70.9 to 85.0 (Gemini 2.5 Flash: 72.0)
• HMMT25: 49.8 to 71.4 (64.2)
• LiveCodeBench v6: 57.4 to 66.0 (61.2)
• GPQA: 65.8 to 73.4 (82.8)
• MMLU-Pro: 78.5 to 80.9 (81.9)
• BFCL-v3: 69.1 to 72.4 (68.6)
• TAU2-Airline: 36.0 to 58.0 (52.0)
• Arena-Hard v2: 36.3 to 56.0 (56.7)

The pattern is clear. Competition maths and code improved sharply and beat the outside reference. Knowledge-heavy evaluations like GPQA and MMLU-Pro moved less and still trail it, which is what you would expect: thinking longer helps you use what you know, it does not add facts a 30B model never stored.

The agentic rows are the most interesting for production. The TAU benchmarks simulate multi-turn customer-service tasks with tools, and TAU2-Airline jumped by 22 points. TAU2-Telecom moved only from 22.8 to 26.3, so do not generalise from one domain. All of these are vendor-run; build your own eval before trusting them for your workload.

The output budget is the real cost

Qwen recommends an output length of 32,768 tokens for most queries and 81,920 tokens for hard maths and programming problems. Read that again: the vendor expects a single answer to run to tens of thousands of tokens, most of which you never show the user.

This is where per-token prices mislead. OpenRouter lists the model at $0.20 per million input tokens and $2.40 per million output at the time of writing, against $0.10 and $0.30 for the Instruct build. The output price is the one that matters here, because reasoning traces are billed as output. A request that thinks for 20,000 tokens can easily cost more than the same request answered directly by a larger non-thinking model. The token cost of reasoning models works through the arithmetic.

Two practical consequences follow. First, cap max_tokens deliberately: too low and the model is cut off mid-thought with no answer, too high and a confused run burns budget. Second, check the provider's limits. Some hosted listings show a context far below the vendor's 262,144 tokens; if the provider's window is smaller than your prompt plus an 80K thinking budget, the long-reasoning configuration will not fit.

A parsing trap in the chat template

The chat template inserts the opening <think> tag automatically as part of the prompt. The model's output therefore often contains only the closing </think> tag, with reasoning before it and the answer after.

Code that looks for a matched pair of tags will fail on this. The robust approach is to split on the last closing tag:

reasoning, sep, answer = text.rpartition("</think>")
if not sep:
    answer = text  # no tag: treat everything as the answer, or flag a truncated run
answer = answer.strip()

If your serving stack offers a reasoning parser for Qwen3, use it so the trace arrives in a separate field. Either way, test the case where generation hits the token cap before the closing tag appears; that is the failure you will see in production, and it should be logged rather than shown to a user as a half-finished thought.

When to pick it over Instruct

• Pick Thinking for maths, algorithmic code, planning steps in an agent, and multi-turn tool tasks where a wrong early decision wrecks the run.
• Pick Instruct for chat, extraction, short tool calls and anything latency-sensitive. It also scores higher on some preference evaluations: 69.0 on Arena-Hard v2 against 56.0 here.
• Combine them: let the Thinking model write a plan, then have the Instruct model execute the cheap steps. The two share an architecture, so self-hosting both is a memory question rather than an operational one.

How to test it on your own work

Pick fifteen tasks where your current model fails at least some of the time. Run each three times with Qwen's recommended sampling (temperature 0.6, top-p 0.95, top-k 20, no greedy decoding) and record three things: whether it succeeded, total output tokens, and wall-clock time to the final answer.

Then divide total spend by successful tasks. If cost per solved task beats your current setup, the long traces are earning their keep. If the success rate barely moves while tokens triple, the task did not need a reasoner, and the Instruct build is the better answer. The pattern to look for is a task with several dependent steps: those reward a reasoner, while single-step lookups and reformatting rarely do.