Qwen 3.8 27B is excellent, but it defaults to overthinking things

According to the paper "Stealing reasoning traces from proprietary llms" [0] all frontier models overthink.

Thinking is good.

You just don't see it in proprietary harnesses because it's literally cryptographically hidden from you.

To me, the amazing thing is that we now have local models that rival the reasoning of high end models from about a year ago.

I hope this trend continues.

All current era models overthink as it's a product of their RL incentives (or distillation of models with them...)

From my reading of the Fable 5 and Opus 5 System cards, my reconstruction is something like:

Finish the task → make externally observable evidence that it is finished → check your own work → fix problems → don't stop prematurely → satisfy the evaluator comprehensively.

That is fantastic for SWE benchmarks and autonomous agents. It also naturally creates pathologies:

under-answering is expensive; over-answering is cheap.

I have this branch of llama.cpp that among other things (like patching the template to not break the kv cache, and saving conversations to disk so you can resume quickly days after) also accept the reasoning effort flag here https://github.com/alainnothere/llama.cpp/tree/disk-cache-ev...

I did testing and the reasoning effort can be set per message, I was not aware of the option of none mentioned by @xscott, I tested but didn't see any change, I think there are just 3 values, xhigh, medium and low as per https://huggingface.co/Qwen/Qwen3.8-27B-FP8 , I did testing and the thing can do it's "I'll speak 10 million words to myself to ensure I'm not missing something" and then switch to a faster model, then switch... I did a test and the thing keep coherence and follow it's train of though-kens, you can see the result here... https://github.com/alainnothere/llama.cpp/blob/disk-cache-ev...

I do agree that Qwen 3.8 27B is excellent but slow and very token inefficient. My benchmark places it near opus 4.6 and codex 5.3 performance. 3.6 27B couldn't even complete the benchmark. Please see below for details:

https://gist.github.com/nharziro/aed0c364ce2f295a493494c6f1b...

I went back to Glimmer 30b for my 20GB of VRAM. Just a better experience fit-wise and speed-wise and tone-/voice-wise.

The big problem with overthinking on a dense model is obviously the speed hit you take. Going from Qwen 35BA3B to 27B for me is about 7-8x slower (should be ~9x?). This makes me a lot less patient for useless thinking tokens.

I’d want to compare this to the new Muse 30B model which is super terse and has a whole different way of thinking (no “Wait,”) and in my experiments was way more token efficient to the point that the absolute tok / s didn’t really matter.

This is true, but I think it understates the problem. I did a task I've done with a bunch of small models lately (https://github.com/swelljoe/flar/pull/17), and it did an excellent job, the best of any self-hostable model. But, it took eleven (11!) hours on my dual GPU setup. It really chewed on it, and spent a lot of time checking and re-checking. It is by far the slowest model I've used for the task. GPT 5.5 did a similar task in about 20 minutes. Most big models took about an hour or so, and most small models needed a couple of hours (but did a worse job).

To be fair, Opus 5 overthinks things on a regular basis. I interact with the LLM almost entirely through the prompt interface vs. some agentic harness, so I have a lot of granular exposure to its reasoning. For almost every code analysis, it flags all the important issues and at least one non-issue. It suggests some impractical and unnecessary fix for the non-issue that would categorically be a regression.

I've learned that medium effort can improve the outcome relative to higher settings. But I suspect the phenomenon is an artifact of a misguided effort to fix inherent LLM limitations. At least some of its reasoning will miss the target, and more bad reasoning is not the remedy.

It won't satisfy the people who just want to drop a model into their existing toolset and run, but I think there are a lot of ways to deal with this overthinking problem.

For instance, it's a step backward, but I put {"reasoning_effort":"none"} and led it by the nose:

   User: We're going to make <silly demo>.  Please create a plan, but do not write code yet.

   Agent: <short and reasonable plan>

   User: Now please follow that plan and write the code.  No other chat.

   Agent: <reasonable code in reasonable time>

Maybe this can be fixed with Jinja templates or something, or maybe it's a hack to your harness, but it shows you can get the model to reason reasonably.

At medium thinking it is much better

--thinking-budget and --thinking-message is all you need in llamacpp to keep it progressing.

the message can be some combination of tool calling, summarizing, etc. It's overthinking often is a bunch of recursion, so simply stopping t and redirecting is all you need to do.

If someones building a harness for llamacpp, you can set this per message, so it's possible to dynamically control it by watching for the expansion of the thinking traces, and redirecting it.

I use the message to tell it to use subagents, add additional logging and to use opencode's dynamic context pruning.

As such, we'll just whisper here _skill issue_.

You have 4 thinking levels.

You can disable it. It's well known issue in Qwen, previous releases I would disable it by default.

Also xhigh seem a new thing.

For agents, token efficiency is an operating cost. I’d rather have a terse model that escalates hard cases than one that overthinks every tool call.

A no-thinking pelican! I hope to see more, it's surprisingly good for just 2 minutes.

I wonder if this can be fixed with LORAs.

I hope Apple does end up moving to HBM. Unified memory has been a huge godsend, but the low memory bandwidth is just such a killer. Even/especially on M5, where the available compute is starting to starve incredibly badly on ML workloads.

According to the paper "Stealing reasoning traces from proprietary llms" [0] all frontier models overthink.

Thinking is good.

You just don't see it in proprietary harnesses because it's literally cryptographically hidden from you.

[0] https://arxiv.org/pdf/2608.09867

I went back to Glimmer 30b for my 20GB of VRAM. Just a better experience fit-wise and speed-wise and tone-/voice-wise.

To me, the amazing thing is that we now have local models that rival the reasoning of high end models from about a year ago.

I hope this trend continues.

Unlike cloud infra in general which offers things like automatic backups, regional redundancy, and effectively unlimited scalability, it seems like the value proposition of cloud LLM gets ever shakier.

* Many businesses don't need frontier level intelligence anyway.

* It's completely stateless. If your local LLM machine catches fire? Nothing was lost. Buy another.

Comparing with Muse Glimmer is a good idea. I ran the same exact HTML tool generating prompt against both Glimmer 30B and Qwen 3.8 27B. Results:

Qwen: https://gist.github.com/simonw/121ad098860028b2fab603fa12da1... - 17,576 reasoning tokens, produced this HTML result: https://static.simonwillison.net/static/2026/qwen-over-think...

Glimmer: https://gist.github.com/simonw/51e8ddb2ee597a5005fa63bd4927d... 1,021 reasoning tokens, this HTML: https://static.simonwillison.net/static/2026/glimmer-bbox.ht... - ugly but functional.

In both cases paste in the URL https://static.simonwillison.net/static/2026/two-pelicans-on... to see them work.

Both applications work correctly and fulfill the requirements. The Qwen one (which used the default xhigh reasoning setting) is massively over-engineered. The Glimmer one used whatever their default in LM Studio is and I would argue is a tiny bit under-engineered.

Weirdly the Glimmer one doesn't work with images on other domains like https://static.inaturalist.org/photos/714731804/large.jpg - it fails with a CORS error, but you don't need CORS to load images and detect their width and height, and the Qwen one handles that URL just fine.

That's because Glimmer added this unnecessary line:

  img.crossOrigin = 'anonymous';

I love reading Glimmer's "thoughts". Why use many word when few do trick?

Glimmer is stupider than 3.6 27B. You can't compare its speed to 3.8 and be done.

All current era models overthink as it's a product of their RL incentives (or distillation of models with them...)

From my reading of the Fable 5 and Opus 5 System cards, my reconstruction is something like:

Finish the task → make externally observable evidence that it is finished → check your own work → fix problems → don't stop prematurely → satisfy the evaluator comprehensively.

That is fantastic for SWE benchmarks and autonomous agents. It also naturally creates pathologies:

under-answering is expensive; over-answering is cheap.

https://gist.github.com/nharziro/aed0c364ce2f295a493494c6f1b...

xhigh tells it to overthink and re check everything. Low tells it to only do the minimum thinking necessary. I would suggest to give qwen medium which doesn't inject any thinking directives into it and also to give as much context as you can, ideally around 500k tokens or even 1M if you can. Big complex tasks like these make the model hit the compaction trigger a lot and they end up re thinking the same thing several times in my experience.

Was that with the default xhigh reasoning setting? I suggest trying again with reasoning set to low or turned off entirely.

What’s that about the template breaking the kv cache?

At medium thinking it is much better

For agents, token efficiency is an operating cost. I’d rather have a terse model that escalates hard cases than one that overthinks every tool call.

It won't satisfy the people who just want to drop a model into their existing toolset and run, but I think there are a lot of ways to deal with this overthinking problem.

For instance, it's a step backward, but I put {"reasoning_effort":"none"} and led it by the nose:

   User: We're going to make <silly demo>.  Please create a plan, but do not write code yet.

   Agent: <short and reasonable plan>

   User: Now please follow that plan and write the code.  No other chat.

   Agent: <reasonable code in reasonable time>

Maybe this can be fixed with Jinja templates or something, or maybe it's a hack to your harness, but it shows you can get the model to reason reasonably.

A no-thinking pelican! I hope to see more, it's surprisingly good for just 2 minutes.

Yes, if you set reasoning to none you can force the granularity of the thinking.

It will actually adhere to your request for e.g. 3 sentences max.

Thinking mode will override any instructions in the prompt (at least for other models in my experience).

Of course this will probably hurt performance, but works great for easy tasks that you know are trivial. Tons of pipeline, image recognition etc use cases where this works well.

I'd be curious to see Qwen 3.8 27B low thinking benchmarks though.

You have 4 thinking levels.

You can disable it. It's well known issue in Qwen, previous releases I would disable it by default.

Also xhigh seem a new thing.

--thinking-budget and --thinking-message is all you need in llamacpp to keep it progressing.

the message can be some combination of tool calling, summarizing, etc. It's overthinking often is a bunch of recursion, so simply stopping t and redirecting is all you need to do.

If someones building a harness for llamacpp, you can set this per message, so it's possible to dynamically control it by watching for the expansion of the thinking traces, and redirecting it.

I use the message to tell it to use subagents, add additional logging and to use opencode's dynamic context pruning.

As such, we'll just whisper here _skill issue_.

I wonder if this can be fixed with LORAs.

Yes. Though the chat template doesn’t tell LM Studio to offer the little dropdown. You can bodge the template in the load parameters.

Unsloth Studio / Desktop has it working really well with their version of the weights.

Unfortunately in xhigh thinking it goes down rabbit holes in such an extreme depth-first way, that whenever you choose to cut it off, there is a very good chance it will not have got round to musing on even half of the prompt! It doesn’t really obviously loop in xhigh, so I am not sure if an “overthinking guard” proxy would have much to go on, but it does obsessively ruminate on edge cases. I have seen it overcomplicate simple code as a result even in my limited testing.

Probably the better solution if you want it to be quicker but still fairly thorough appears to be to configure reasoning effort instead of thinking budget. It seems to do very well still even on the Low setting; on the Medium setting it can get stuck in loops like 3.6 does.

I think xhigh reasoning effort was an absurd choice for a default, and so was not sorting out the chat template so LM Studio could offer the reasoning effort dropdown.

Yeah, but be fair. Working with small models is a different ball game. Not all the batteries come included :)

This is definitely such a cool feature that I wish cloud providers would expose.

I had to fix this on 35B A3B -- I have a proxy that just shuts it down if it gets to 2K thinking tokens and injects something like "We have thought enough, let's begin working." and it almost always finishes the turn then. It rarely needs more than 2K thinking tokens and if it does there is always next turn. I would need to see what 27B is actually doing, but these smaller Qwen models seem prone to this.

AFAIK that is initially only for the iPhone?

* Many businesses don't need frontier level intelligence anyway.

* It's completely stateless. If your local LLM machine catches fire? Nothing was lost. Buy another.

Comparing with Muse Glimmer is a good idea. I ran the same exact HTML tool generating prompt against both Glimmer 30B and Qwen 3.8 27B. Results:

Qwen: https://gist.github.com/simonw/121ad098860028b2fab603fa12da1... - 17,576 reasoning tokens, produced this HTML result: https://static.simonwillison.net/static/2026/qwen-over-think...

Glimmer: https://gist.github.com/simonw/51e8ddb2ee597a5005fa63bd4927d... 1,021 reasoning tokens, this HTML: https://static.simonwillison.net/static/2026/glimmer-bbox.ht... - ugly but functional.

In both cases paste in the URL https://static.simonwillison.net/static/2026/two-pelicans-on... to see them work.

That's because Glimmer added this unnecessary line:

  img.crossOrigin = 'anonymous';

I love reading Glimmer's "thoughts". Why use many word when few do trick?

Glimmer is stupider than 3.6 27B. You can't compare its speed to 3.8 and be done.

I’ve noticed dsv4 do that as well, but inconsistently. I thought it was broken at first, but no, it’s just kind of shorthand that it does while thinking.

It’s also a little bit snarky, almost. The stuff it thought during the car wash puzzle made me laugh.

What’s that about the template breaking the kv cache?

this is my understanding, the default template keeps the thinking part but only for the last message, so the harness has to play along with the template and strip and add to keep the conversation matching what's there on the llama.cpp cache, but if the harness sends the thinking in every turn, then you break what llama.cpp expects, the conversation doesn't match anymore what you have on cache and it reprocesses again the whole conversation

Was that with the default xhigh reasoning setting? I suggest trying again with reasoning set to low or turned off entirely.

You now have me testing it with reasoning turned off, which I have never bothered much with on any other local models because it's rarely worth it.

The result appears to be almost as good as Qwen 3.6 35B A3B on medium thinking mode.

It second-guesses a little, it gives broader/more speculative answers, of course, and it missed the nuance of one of my prompts, but this gives me a lot more confidence that the Low reasoning effort is going to be as good as they say, and perhaps in some cases non-thinking looks like it would be enough.

Really useful, thanks.

Yes, default everything, no tuning, 8_K_XL Unsloth quantization on dual Radeon V620 GPUs (which aren't blazing, but faster than the Strix Halo).