--- title: "Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things" url: https://daily.dev/posts/qwen-3-8-27b-is-excellent-but-it-defaults-to-wildly-overthinking-things-qs6mhrvru source_url: https://simonwillison.net/2026/Aug/16/qwen-38-27b type: article source: "Simon Willison" published: 2026-08-16T22:03:20.253Z updated: 2026-08-18T12:31:51.061Z tags: ["ai-agents", "qwen", "llama-cpp"] reading_time: 11 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things **[Simon Willison](https://daily.dev/sources/simonwillison)** · 11 min read · 0 upvotes · 0 comments ## Summary Qwen 3.8 27B, a new Apache 2 licensed vision-capable LLM from Alibaba, delivers impressive benchmark gains over its predecessor and even the closed-weight Qwen 3.7-Plus, but ships with a default 'xhigh' reasoning effort that leads to absurd overthinking—taking 21 minutes and 22,276 reasoning tokens to draw a simple pelican SVG, or turning a request for a plain circle into an elaborate animated artwork. Testing on an M5 Max MacBook Pro and an NVIDIA DGX Spark shows the model excels at bounding-box detection and can drive coding agents like Pi reasonably well, but inference speed (15-30 tokens/sec) lags well behind hosted API models. Running the model with llama.cpp's Multi-Token Prediction (MTP) support gave a roughly 72% speed boost over the default LM Studio GGUF. The strong recommendation is to disable or lower the default reasoning effort when running the model. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What reasoning effort does Qwen 3.8 27B default to and why is that a problem? Qwen 3.8 27B defaults to 'xhigh' reasoning effort, which causes extreme overthinking even on trivial prompts. A request to draw a simple SVG circle produced pages of reasoning about palettes and animation before returning something entirely different from what was asked, and a pelican SVG took 21 minutes and 22,276 reasoning tokens. Running with reasoning off or on 'low' is recommended, cutting the same pelican task down to about 137 seconds. _Anyone tuning local LLM reasoning settings can track real-world model quirks like this on daily.dev._ ### How much faster does Qwen 3.8 27B run with llama.cpp Multi-Token Prediction compared to the default LM Studio GGUF? Using llama.cpp's Multi-Token Prediction (MTP) support with the flags --spec-default and --spec-type draft-mtp gave roughly a 72% speed improvement over the default LM Studio Q4_K_M GGUF build, tested on an NVIDIA DGX Spark with a comparative benchmark run by GPT-5.6 in Codex. MTP works by having a cheaper mechanism guess several tokens ahead that the main model then verifies. _Developers optimizing local model inference speed can follow tricks like this via daily.dev._ ### Can Qwen 3.8 27B run as the model behind a coding agent like Pi? Yes, Qwen 3.8 27B successfully drove the Pi coding agent, answering questions about a codebase's authentication setup and writing working Python code to convert a JSONL transcript to markdown after being configured as a custom OpenAI-compatible provider pointing at an LM Studio server shared via tailscale serve. Pi was chosen for its shorter system prompt, which suits smaller local models better. _Developers evaluating small local models for agentic coding workflows can follow reports like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 691 comments across hackernews, lobsters (as of 2026-08-18). **TL;DR:** Developers are impressed that a 17-27GB local model can deliver this level of capability on consumer-ish hardware, but many report frustration getting good speeds without a beefy GPU/high memory bandwidth, and the default overthinking behavior is seen as a real usability flaw. **Sentiment:** 45% positive · 40% mixed · 15% skeptical **The case for** - Running a capable model locally on a laptop or modest GPU feels like a genuine milestone in local AI progress. - Several people report usable speeds (25-100 tok/s) on Macs or mid-range GPUs when the model fits in VRAM. - Some praise the model's vision/bounding-box and motion-graphics capabilities as genuinely impressive. **The pushback** - Performance falls off a cliff when the model doesn't fully fit in VRAM, making it impractical on many 'consumer' machines. - Memory bandwidth, not RAM capacity or raw compute, is repeatedly cited as the real bottleneck for local inference. - The default excessive reasoning effort ('xhigh') is called out as a broader pattern of frontier models overengineering simple tasks, wasting time and compute. - Users report confusing, inconsistent guidance on correct templates/settings across llama.cpp, Ollama, LM Studio, and quant variants, making optimal local setup hard to achieve. **By community** - hackernews (mixed): Enthusiasm about local model progress is tempered by extensive debate over hardware requirements, memory bandwidth bottlenecks, and a long tangential argument about whether LLMs pass the Turing test. - lobsters (mixed): No comments were provided for this discussion, so there isn't enough signal to characterize the community's take. **Hottest debate:** Whether memory bandwidth/VRAM capacity or compute power is the real bottleneck for running these models on consumer hardware. **Open questions** - Will a smaller or MoE variant (like a 3.8 MoE) be released to make the model more practical on limited hardware? - What is the actual mechanism behind the 'reasoning_effort' setting (deterministic API parameter vs. prompt engineering)? - How can users reliably determine the 'correct' template and inference settings for a given model across different runtimes? **Highlights** > “The fact that a 17GB file can do all of this stuff on my home machines is a miracle. Once again, I’m delighted and amazed at how much progress local models have made this year.” I think that should be the blinking headline - this shows what can be done with consumer hardware. > — [chvid on hackernews · 10 comments](https://news.ycombinator.com/item?id=49326409) > what??? not true! for inference the compute is the last thing we need more of. memory bandwidth is the numebr one blocker, after that the inefficiencies that where introduced with MoE models (and all new large models are made that way) Here is a quick read: https://news.ycombinator.com/item?id=49324600 > — [mhaberl on hackernews](https://news.ycombinator.com/item?id=49327590) > The other implication here is that this is all software improvements and optimization. There might be a lot more wiggle room for improving quality over time. It seems the model and reasoning quality is improving faster than the hardware currently. The over reasoning that Simon Willison highlights here is a real issue though. I've observed it with some of the OpenAI models as well. They are prone to overthinking and overengineering things. What I would love is models that figure out their own appropriate reasoning effort given a task. I'm spending too much brain cycles worrying on what model speed, reasoning, and quality settings to pick. It's not just a cost concern it's also a time concern. Wasting a lot of time for simple UI tweaks because the model is set to high or ultra or whatever is counter productive. The last few iterations of frontier models seem to emphasize benchmarks and reasoning effort. But of course the day to day reality of many developers is that they are trying to solve relatively simple problems compared to e.g. proving some so far unproven theorems, solving some Nobel prize level problems, etc. I'd love my tools to start making sane choices based on what I ask rather than defaulting to "boil the oceans". These tools need some kind of Auto select. Mostly Ultra is overkill and a waste of time and resources. And of course with local models, keeping simple things local is a nice option. It's nice to have Sol Ultra extra fast as an option in my back pocket. But it's complete overkill 99% of the time. And it's not like most users make good choices here or are even capable of making good, informed choices. The models are more intelligent than the tool UX. Arguably, a local model of very modest size might be able to do better for this specific choice. > — [jillesvangurp on hackernews](https://news.ycombinator.com/item?id=49328512) > For me that moment was Gemma 4 12B QAT. You're not suddenly going to start throwing your hardest programming problems at Gemma 4 12B QAT, it is still 15B parameters less. It's more that, aside from pelican art which isn't what local models are for, I didn't see anything on Simon's post that it couldn't assist with or largely succeed at. It can run 80-100t/s on a laptop, can understand images natively and do bounding boxes, read tiny text, understands audio natively as well and can transcribe or translate anything you say, can do accurate long context retrieval with pretty large context windows, tool calling, excellent reasoning and is very token efficient. It's only 7GB including the mmproj or 8GB with MTP. The Qwen 3.8 27B model Simon was using is ~18GB with MTP+mmproj, rather than 17GB alone. The point is not really that you compare these models directly, but that Gemma 4 12B QAT was really a special moment in model releases deserving of a similar reaction relative to its size, but was mutilated by Google themselves, Unsloth and Llama.cpp. The overall appreciation I think we're seeing this year in particular is that people are easily surprised when multiple things are improving simultaneously which produce seemingly exponential changes. It isn't just that models are getting smaller, or that reasoning is getting better, or that speculative decoding is becoming mainstream, or that models can understand audio and images better now, or that they can reliably call tools which expands their capabilities, or that context windows are getting larger, or that accurate retrieval is improved, or that.... and so on. It's all of them narrowing in at once that is starting to make local models incredible and truly useful for far more use cases on the existing hardware people already have. > — [CMay on hackernews · 4 comments](https://news.ycombinator.com/item?id=49327574) > Do these self hosted models avoid "protecting the user" or protecting big businesses? In other words can I just ask it any question and if it has the answer, I will get an answer rather than telling me it can't answer the question? I ask because Claude is fun for rewriting abandoned code and I am not a proper developer so it's been great for me. Claude refuses to answer questions about science and medicine that stray outside of the officially supported narratives of the AMA and I have issues that have surpassed anything a doctor can do so I am entirely on my own. Will the self hosted models answer such questions or will it also try to put walls or bumper guards around topics? > — [Bender on hackernews · 2 comments](https://news.ycombinator.com/item?id=49332406) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49324985) · 690 points · 688 comments - [lobsters](https://lobste.rs/s/k7myyp/qwen_3_8_27b_is_excellent_it_defaults) · 10 points · 3 comments --- Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#qwen](https://daily.dev/tags/qwen), [#llama-cpp](https://daily.dev/tags/llama-cpp) [View this post on daily.dev](https://daily.dev/posts/qwen-3-8-27b-is-excellent-but-it-defaults-to-wildly-overthinking-things-qs6mhrvru)