ThinkingCap: Qwen3.6-27B with half the thinking tokens
Reasoning models have a dirty secret: most of the thinking tokens you pay for are filler. The model second-guesses itself, restates the problem, explores branches it already rejected. I've written before about what reasoning models actually do, and the short version is that the chain of thought is real work. Nobody said it was efficient work. ThinkingCap-Qwen3.6-27B from BottleCap AI is the first open-weight release I've seen that attacks this directly: same Qwen3.6-27B, finetuned to think in roughly half the tokens, over 90% fewer in the best cases. Apache 2.0, multimodal like the base, up on Hugging Face as bottlecapai/ThinkingCap-Qwen3.6-27B.
What they actually did
This is a finetune of Qwen3.6-27B, not a distillation into a smaller model. BottleCap trained on a curated problem set across domains and difficulty levels, explicitly designed to be minimally invasive: the goal was to preserve Qwen's answer quality and style while cutting the reasoning preamble. The eval methodology is more serious than most model cards: multiple seeds per benchmark at Qwen's recommended temperature 1.0, statistical significance testing, and separate in-domain and out-of-domain splits so you can see whether the efficiency generalizes past the training data.
The out-of-domain numbers
| Benchmark | Base acc | Ours acc | Token reduction |
|---|---|---|---|
| GPQA-Diamond | 85.5 | 83.8 | 67.8% |
| MMLU-Pro | 85.9 | 85.4 | 53.7% |
| LiveCodeBench | 80.7 | 84.3 | 41.1% |
| HMMT (Nov 2025) | 88.0 | 84.7 | 38.0% |
| LongBench v2 | 62.6 | 60.2 | 39.1% |
Macro average across the full suite: 81.5 for base Qwen, 80.7 for ThinkingCap. Less than a point of accuracy for a 40-70% cut in thinking tokens, and LiveCodeBench actually goes up (the model codes better when it stops talking itself in circles first).
Why this matters more locally than in the cloud
On an API, thinking tokens are a line item. On your own hardware, they're wall-clock time. A 27B model on a single consumer GPU generates maybe 20-40 tokens a second, so GPQA-style questions dropping from 10,777 thinking tokens to 3,351 is the difference between waiting five minutes and waiting ninety seconds for the same answer. The KV cache math compounds this: shorter generations mean less cache growth, which means more room for context or batch. Every efficiency gain you make locally multiplies, and that's the whole thesis of running the best local models for coding.
Cutting thinking tokens is the rare optimization that pays twice: once in latency, once in the memory you didn't spend holding the tokens you didn't generate.
Where the honest costs are
The savings aren't free everywhere. The hardest reasoning benchmarks pay a real tax: HMMT drops 3.3 points, GPQA-Diamond 1.7, and the agentic Claw-Eval slides from 87.0 to 84.4. The pattern holds up: the closer a task sits to the frontier of what the model can do at all, the more those extra thinking tokens were actually load-bearing. LongBench v2 also dips a couple of points, so I'd be careful pointing this at long-context retrieval work. My read: use ThinkingCap as the default for interactive and mid-difficulty work, keep base Qwen3.6 around for the genuinely hard problems, and route between them (the same cascade logic as local-first routing), except both tiers live on your own GPU.
Verdict
This is the direction I want open-weight releases to go: the same capability, delivered cheaper, not another size class or another benchmark chart. If the finetuning recipe holds up on other bases, token-efficient variants could become a standard release artifact, the way quantizations are today. Check what a 27B costs to run on your hardware on the local cost page, then mentally halve the generation time.