Exploring ThinkingCap fine-tunes for Qwen 3.8: Is it still necessary with native `reasoning_effort`?
Hi everyone,
With the recent release of Qwen 3.8 27B, I’ve been reflecting on the impact of models like Bottle Cap AI’s ThinkingCap-Qwen3.6-27B. That fine-tune did a fantastic job of reducing unnecessary Chain-of-Thought (CoT) overthinking by ~50% without dropping reasoning quality.
Now that Qwen 3.8 introduces native reasoning_effort control (low, medium, xhigh, none) directly out of the box, I wanted to open a discussion with the community:
- Native Controls vs. Fine-tunes: Does Qwen 3.8’s built-in
lowormediumreasoning setting solve the overthinking issue effectively, or is there still a strong case for community-driven "ThinkingCap" style fine-tunes? - Efficiency & Speed: How does Qwen 3.8’s native CoT token consumption compare to 3.6 fine-tunes in local setups (vLLM / Ollama / Unsloth)?
- Use-case Trade-offs: Are you noticing any drop in complex multi-step coding/math performance when dialing down the reasoning effort on 3.8?
Would love to hear thoughts, benchmark results, or early testing experiences from anyone experimenting with Qwen 3.8 27B!
without dropping reasoning quality.
it did drop, it was just not obvious. I also bought the "50% reduced thinking at no loss" and daily drove it for ~2 weeks on all projects. at one point i started getting annoyed by it and claimed to myself that "maybe I have hit the limits 27B can go". before ditching it, decided to swap back to the original weights. 0 issues afterwards, everything that thinking cap couldn't do, the offical release handled fine. It also didn't seem like it did it slower, I didn't notice a 'degradation' in time spent on a task once going back, if anything the tasks being completed with less turns helped. It is, however, a very interesting idea, what bottle cap did, and I have been curious how it can be adjusted to better reach their claimed savings, as it looks like there is a good idea in there.
That said, I used the model for ML Engineering-adjacent stuff (both modeling and framework dev, not exclusive to LLMs), it can be that it's fine in other cases and faster in most. But every alteration of the weights comes at a cost, sometimes its just harder to detect it.
But to give my 2 cents on the questions:
- I think there is always room for experimentation, and I hope we get many different finetunes, RLs and the like. Research and improvement is driven by experimentation, and even if it sometimes those doesn't quite reach the goal, it is always healthy for the field, so I hope that despite the reasoning efforts people experiment
- There is another thread on here where someone tested it against other models and while it has long CoT the total tokens used tended to be less than its peers. If a long CoT leads to solving a task in 3 tool calls instead of 15, it's still a net benefit, and it feels like that is what's been driving recent OpenAI models, seeing how they often use way less tools than their peers.
- In my testing, 3.8 is an improvement over 3.6 in every domain, and that makes me very suspicious. I almost don't want to believe it is genuinely an 'all-around' improvement, so I am curious to see if anyone finds what it's worse at, if anything. But so far, from the coverage I've seen online and personal testing, it seems like a clean improvement over an already really good model. I am so far very happy with this release.
I mean if you reduce thinking level it'll become dumber which ThinkingCap tries to mitigate.