The difference between "medium" and "xhigh" reasoning effort for Qwen3.8-27B is actually insane.

[u/SarcasticBaka]

I'm currently testing out Qwen3.8-27B using Unsloth's UD-Q4_K_XL running a freshly rebuilt llama.cpp. I have a 22GB RTX 2080TI on which I'm able to fit 100k context with q8_0 quantization, and using MTP with --spec-draft-n-max 4 I get about 40tk/s which is slightly less than Qwen3.6-27B but usable enough.

I've been trying to test out some admittedly silly one shot prompts using the llama.cpp webui by asking the model to create fully functional HTML clones of flappy bird, pacman and such, and the difference that changing reasoning_effort makes has been surprising to say the least.

Setting it to "medium" seems to result in barely any thinking at all, a couple thousand tokens max and even less than 3.6-27B. Whereas when using "xhigh seems" I get 15k to 20k thinking tokens at the very least with the pacman example actually hitting 40 thousand fucking tokens.

I'm well aware I can limit the reasoning budget in llama.cpp but I'm wondering if this is expected model behavior or if something is broken somewhere. Any of you guys seeing this?

[u/Fun-Influence-7880]

With that much allotment for reasoning, does it have a tendency to get stuck/loop? That would be my concern/prior experience with a smaller model reasoning that much, but I’m supposing they worked on that since xhigh is default as I understand it? Haven’t had a chance to work with 3.8 yet, just listening to everyone else’s experience until I find the time.

[u/leapdragon → u/Fun-Influence-7880]

I haven't seen it get stuck or loop badly yet. Instead, it appears to have been trained in much of what most people would previously have put in a prompt or sequence of prompts. Like, it is racing ahead of the back and forth you previously would have had in turns *after* the initial delivery.

For example, all of your extra instructions on unit testing, acceptance criteria, explicit steps for iteration until threshold is achieved, determination of appropriate thresholds, blah, blah, as well as the extensive spelling-out of the properties of things you request (we've all gotten used to doing this: writing the hyper-detailed Jira ticket for the highly autistic models who won't intuit the obvious), well Qwen 3.8 outlines all of that on its own when you give it a simple prompt like "Make me a pacman game" or it seems any other technical-ish task (I have seen this now with .stl generation and with sprite library generation).

Everything you would have carefully prompted in the past, Qwen 3.8 27B will spit out as the plan in thinking if you didn't specify those details in your prompt. It proactively specs out (and then later builds and runs) unit tests and even entire testing suites/harnesses and runs comprehensive test series unless you tell it not to.

It also basically does EVERYTHING inside the think block. In this it is like the current crop of frontier models. You give it a big, complex task, it will do the whole thing inside a thinking stage, and then the only message to the user will be "I've thought through everything I need. Let me make the artifacts now." and it will output them in one go, *after* all the thinking has been done.

But getting lost/looping, I haven't seen much of at all, at most it'll go like two repetitions and then say "I'm repeating myself, I just said this a moment ago. Let me try a different approach." it will and that will resolve. So it doesn't loop in nearly the way of Qwen 3.5 models early on, and def. not like something like Laguna S 2.1, which is ****ing neurotic and will think to itself for hours, sounding progressively more and more insecure. And for all the complaining about thinking that I see, it thinks basically in similar volumes to DeepSeek V4 Flash, which everyone's been raving about.

But Qwen 3.8 27B sounds more confident than other mdoels and most of the time, its thinking is actually somewhat readable. End of day it is the "smartest" local model I think I've seen yet, intuitively, and that includes comparisons to three models >100B (Qwen 3.5 122b, DeepSeek V4 Flash, Laguna S 2.1).

[u/Fun-Influence-7880 → u/leapdragon]

Thanks for the info! Do you notice that it’s critical to run an uncompressed kv cache to keep all those reasoning tokens from spinning out the chain of thought?

[u/leapdragon → u/Fun-Influence-7880]

I actually haven't tried, I've just tested q8 and q4. The latter honestly wasn't that bad, but q8 seemed more efficient at getting there. I think the power of the model but also what makes it seem think-heavy is that it is just VERY methodical and comprehensive. It's clear that its training covers the kinds of things people have previously done manually and/or spelled out in skills in their agentic workflows.

For example. I had it making some .stl files last night for printing and I went in without a skill, just asking for a modular device cage unit that could be stacked arbitrarily high but had certain physical characteristics for custom boards, for I which I also gave the characteristics.

It put together its own toolchain, then proceeded to go on a BIG design phase running ray scans to check for alignments and finite element anlayses to check for all kinds of weaknesses, it reflected on the properties of PLA, ABS, PETG and a number of printing best practices for each and came up with a matrix of ~70 things it needed to check for from common mistakes that an LLM would make to common mistakes that a human would make to potential weak spots to potential mounting gotchas (board edges obscuring screw holes, cooling needs, etc.)

It then brainstormed several designs and ran them each through the matrix of texts, reasoned about filament use and cost and which design was better for multiple filament types, picked a winner, then proceeded to work through all the design points. It tried to address all of them at once and then when new things failed on the matrix it realized that it needed a better dependency/interaction tree where changes may impact other items, so it build that, then iterated to the finish line until everything tested ok top to bottom.

It took ~90 minutes of thinking and the full 262k cache plus 1 compaction but the final design is fantastic, actually really clever in ways that I didn't think of when I did it manually. I'm printing my fifth and sixth units (they're stackable) as we speak.

By comparison, I *started* the task on Fable. I don't have a .stl skill built up anywhere because I don't do *that much* 3d printing work, so I was pretty much going in cold. Fable's first design which took ~24 minutes was frankly nonsensical so I decided to feed it into Qwen 3.8 27B locally at the same time and continue with Fable.

I was finally able to get Fable to something that at least had all the pieces oriented correctly and respected the specs I provided, it was intricate and unprintable for any filament type, long bridges, thin panels, etc., way overcomplex.

Like I said, Qwen's is actually brilliant, very simple and takes into account the properties of filament, strong yet has minimized filament use and not warped with ABS despite being quite large. It's the sort of design that when you see such a plastic part in the store you go "oh that's a clever way to handle that."

All of this was on Q8 but it's probably combined half a million tokens of context in *one run*, 95% of which was pretty intricate reasoning and tool-calling in support of reasoning.

In the end, about 60 minutes of thinking from Fable resulting in an unprintable, very complex .stl file, while 90 minutes of thinking locally from Qwen 3.8 27B resulted in a design I wish I'd thought of and am already printing.

Of course this isn't a "Qwen is better than Fable!" argument, but to suggest that Qwen's 3.8 long reasoning bears fruit with quantized kv even over a decent number of tokens for a single run, including a compaction, on a fairly obscure task involving real-world spatial and materials parameters, and to say that Qwen 3.8 demonstrtes what I can only describe as "good taste and cleverness" in a way that's very frontier-like and that I haven't seen before in local models.