Qwen 3.8 27B's default xhigh reasoning spends 22,276 tokens and 21 minutes on an SVG
- Alibaba's Qwen 3.8 27B is an Apache 2-licensed, vision-capable 27B-parameter model whose self-reported benchmarks exceed both Qwen 3.6 27B and closed-weight Qwen 3.7-Plus, though independent results are still pending.
- The model defaults to xhigh reasoning effort, which exhausted LM Studio's default 8,192-token context on mundane prompts; loading its 262,144-token maximum context removed that immediate limit.
- On a local 17GB Q4_K_M quantization, Qwen used 22,276 reasoning tokens and took 21 minutes to create a 3,223-token pelican-on-a-bicycle SVG; disabling reasoning produced a weaker 3,715-token result in 137 seconds.
- For the prompt "draw an SVG of a circle," the xhigh trace began planning gradients, guide rings, animation, accessibility behavior, and a palette instead of emitting a basic
<circle>. - Hacker News users report that low or disabled reasoning, llama.cpp's thinking budget controls, and harness-managed planning steps can constrain the behavior, while some warn that token cutoffs can interrupt xhigh before it addresses the full task.
Hacker News opinions
On dense models, overthinking mostly hurts because of speed. Qwen 3.8 27B is about 7 to 8 times slower than 35B-A3B for me, so I have little patience for useless thinking tokens. Muse 30B is much terser and has been more token-efficient in my tests.
I ran the same HTML tool prompt on Qwen and Muse Glimmer 30B. Qwen used 17,576 reasoning tokens and produced an over-engineered but correct app. Glimmer used 1,021, made an ugly but functional app, and missed a CORS-related edge case that Qwen handled.
I like reading Glimmer's thoughts because it uses so few words.
Glimmer is less capable than Qwen 3.6 27B, so raw speed is not a sufficient comparison.
For agents, token efficiency is an operating cost. I would rather use a terse model that escalates hard cases than one that thinks excessively before every tool call.
That understates it. Qwen did the best job of any self-hostable model on a task I use for small-model testing, but it took 11 hours on my dual-GPU system. GPT 5.5 did a similar task in about 20 minutes, while most large models took about an hour.
Was that using the default xhigh setting? I would retry it with reasoning set to low or disabled.
Give it medium and as much context as possible, ideally 500K to 1M tokens. On large tasks it hits compaction repeatedly and rethinks the same work; xhigh explicitly tells it to check everything.
I use a proxy with 35B-A3B that stops reasoning at 2,000 tokens and injects, "We have thought enough, let's begin working." It usually completes the turn, and if it needs more reasoning there is always another turn.
In llama.cpp, --thinking-budget and --thinking-message can redirect it toward tool calls, summaries, or other work. You can set them per message and react to an expanding reasoning trace.
With xhigh, it goes so deeply down edge-case rabbit holes that cutting it off may happen before it has considered much of the prompt. Setting reasoning effort is probably better than a token budget: low still performs well, while medium can loop like 3.6.
I disable reasoning with {"reasoning_effort":"none"} and force a short planning turn before requesting code. It is a hack for the harness or template, but it gets reasonable plans and code in reasonable time.
Reasoning disabled lets you set the granularity, such as a three-sentence plan, while thinking mode can override prompt instructions. It may reduce performance, but it fits trivial pipeline and image-recognition tasks.
Qwen has four thinking levels and can disable reasoning. I disabled it by default in earlier releases too, and xhigh appears to be new. LM Studio does not expose the dropdown because of the chat template, though Unsloth's version does.