ThinkingCap: Teaching a Reasoning Model to Stop Overthinking

Somewhere along the way, we started treating a model's word count as a proxy for its intelligence. Reasoning models generate long chains of thought before answering, and the longer and more elaborate the reasoning looks, the smarter we assume the model is. But a lot of that reasoning is padding. Models revisit settled assumptions, restate the same argument, wander into irrelevant tangents, and occasionally loop on the same steps without converging. That padding costs latency, money, and throughput, and users never even read it.

ThinkingCap, from the Prague-based startup BottleCap AI, is a direct response to that. It is a fine-tune of the open-weight Qwen3.6-27B model, and its entire goal is to make the base model overthink less without making it any less capable. BottleCap reports that across twelve out-of-domain benchmarks it cuts reasoning tokens by about 46 percent on average, roughly half, while keeping accuracy effectively unchanged. In the best cases the savings exceed 90 percent. It is released on Hugging Face under Apache 2.0, so you can swap it in for a local Qwen model directly.

This article covers why reasoning models overthink, how BottleCap trained ThinkingCap to stop, what the benchmarks show, and the accidental discovery that made its answers feel more human.

How reasoning models learned to think

To see why cutting reasoning is interesting, it helps to remember how models got a reasoning phase in the first place. The path from a plain text predictor to a model with an explicit thinking step was quick.

From next-token prediction to ChatGPT

Modern language models started from one simple idea: predict the most probable next token given a prompt. OpenAI's GPT-3, around 2020, was a very large version of exactly that. It was surprisingly capable, but it had no explicit process for working through a hard problem. It effectively guessed its way straight to an answer. When ChatGPT arrived in late 2022 on the GPT-3.5 architecture, it put that capability in front of the general public for the first time and set expectations for everything that followed.

The shift to thinking mode

Those early models still stumbled on multi-step logic and harder math. The fix was to teach a model not just to answer, but to reason first.

OpenAI's o1, released in 2024, was the first major model to add a distinct thinking mode. Instead of producing an answer immediately, it first generated a private chain of thought, reasoning through the problem step by step, and only then wrote the final answer. Separating thinking from answering sharply improved performance on hard reasoning tasks. The idea spread fast. DeepSeek-R1 brought the same approach to open-weight models, and before long almost every frontier model shipped with a dedicated reasoning phase. Long chains of thought became the new standard for state-of-the-art results.

The overthinking problem

Reasoning mode solved accuracy on hard tasks, but it quietly created a new problem. Models that could think longer did not know when to stop, and the extra tokens were not free.

Knowing when to stop

The redundancy is well documented. A 2026 paper from ByteDance and Beihang University, Does Your Reasoning Model Implicitly Know When to Stop Thinking?, shows that long chains of thought carry a lot of tokens that do not contribute to the final answer, and that longer chains are often uncorrelated with correctness. Its more surprising finding is that reasoning models implicitly do know when they have thought enough. That signal is just buried by the way models are sampled at inference time, so it rarely surfaces. In other words, the ability to be concise is already latent in these models. It mostly needs to be drawn out.

Left unaddressed, the overthinking shows up as wasted tokens spent re-deriving things the model already worked out, higher latency on every extra token, higher cost when you pay per token, and in the worst case loops where the model rephrases the same few steps without converging.

When a model overthinks "hello"

The clearest way to feel this is to watch a capable reasoning model handle a trivial prompt. Step 3.5 Flash, an open-weight reasoning model from StepFun, became a well-shared example of the failure mode when handed a single word: "hello."

A person would just say hi back. The model instead worked through a long internal monologue. It correctly noted the user had greeted it and it should greet back, which could have been the end. Then it debated whether to introduce itself, weighed its system prompt's instruction about using its exact name, parsed whether "always use this name when introducing yourself" meant it had to introduce itself at all, considered whether to mention the date, and eventually concluded with a completely standard greeting. The final answer was fine. Getting there burned a pile of tokens on a social convention it resolved in the most ordinary way possible. That is overthinking in miniature, and it is exactly what ThinkingCap set out to cure.

ThinkingCap's approach

BottleCap's move was not to make the model bigger or smarter. It was to optimize how much computation the model spends reaching an answer, and to change nothing else.

Reward efficiency, not just correctness

The goal was deliberately conservative. BottleCap wanted to preserve the base model's knowledge, reasoning ability, answer quality, conversational style, instruction following, and safety behavior, and change only the length of the reasoning it takes to get there.

The core of the method is the training objective. Conventional fine-tuning rewards a model for reaching the right answer, and says nothing about how long it took, so verbosity carries no penalty and there is no reason to be concise. BottleCap trained against an objective that rewards efficient reasoning, not just correctness. Conceptually, the difference looks like this:

# Conventional objective: only the answer matters
reward = is_correct(answer)

# ThinkingCap-style objective (simplified): correct, but penalize a long trace
reward = is_correct(answer) - efficiency_penalty * thinking_token_count

Treat that as an illustration rather than the literal loss. The real training was a reinforcement-learning objective that rewarded getting the right answer with less reasoning, applied so as to stay minimally invasive to everything else about the model.

What the training did

Starting from Qwen3.6-27B, BottleCap trained on a curated set of problems spanning multiple domains and difficulty levels, so the behavior would generalize rather than overfit one kind of task. The result behaves like the original checkpoint, with the same style, knowledge, and capabilities, but with substantially shorter reasoning traces. In effect, the model learns to notice when it has enough information to answer confidently and to stop there instead of narrating further. It is worth noting Qwen3.6-27B is a dense, non-mixture-of-experts model that fits on consumer GPUs, which is a big part of why an efficiency fine-tune of it is useful for people running local models.

The results

BottleCap evaluated the model carefully, which matters because reasoning output varies a lot run to run. It used full benchmark datasets, five random seeds per condition, and statistical significance testing, across both in-domain holdouts and out-of-domain tasks covering math, knowledge QA, long context, coding, agentic work, multi-turn chat, and safety.

The headline across twelve out-of-domain benchmarks is a 45.8 percent average reduction in reasoning tokens with about a 0.7 percentage-point average change in accuracy. Roughly half the reasoning, effectively unchanged performance. A few representative results:

Notably, on some benchmarks accuracy went up rather than down, most visibly GSM8K and LiveCodeBench, and the rate of responses stuck in reasoning loops fell on several tasks. Cutting the padding did not just leave quality intact. In places it helped.

A single run, side by side

Averages are convincing but abstract, so a concrete example helps. Take a problem with one correct answer: the smallest positive integer n such that n! has exactly 100 trailing zeros. Using Legendre's formula, the answer is 405. Both the base Qwen model and ThinkingCap solve it correctly, but they take very different routes to get there.

The base model follows the right method and then keeps going, exploring extra estimates, re-verifying its own arithmetic, and checking edge cases well past the point of certainty.

In one shared run, that came to about 8,600 total tokens, roughly 7,650 of them spent thinking, over 140 seconds. ThinkingCap walks the same logical path but trims the redundant checks, finishing the same problem in around 1,900 tokens and 30 seconds.

That is a large gap on a single heavy-reasoning problem, and a hard math question flatters the effect more than a typical prompt would. It lines up with BottleCap's broader framing of the model as roughly twice as token-efficient on average and up to about ten times in the best cases. The practical takeaway is the same at either scale: same answer, far less reasoning, so lower latency and lower cost.

A very welcome accident

The most interesting part of the release was not planned. BottleCap's original intent was to shorten only the private reasoning trace and leave the final answer's length and style untouched, so a user would never notice the difference without inspecting the thinking.

A bug applied the shortening to the answer text as well. BottleCap fixed it and trained versions that preserved the original answer length, but in internal testing the team found they all preferred the shorter version. The style was still there, the answers were just faster to read and generate, and they felt more human. Their theory is that people have a built-in penalty for long-winded writing, since we tire of producing and reading it, and the bug accidentally gave the model the same instinct. They decided to publish the concise model and hold the other checkpoints for later.

Final thoughts

The trajectory of AI has mostly been about adding capability. ThinkingCap points at a different lever: efficiency. It is a reminder that a longer reasoning trace is not the same as a better one, and that for a lot of deployments the model that reaches the answer in 2,000 tokens beats the one that takes 5,000 to say the same thing.

By rewarding efficient reasoning instead of raw correctness, BottleCap produced a model that is faster, cheaper to run, and about as accurate as its base, with answers that are easier to read. It is a useful blueprint, and since it is on Hugging Face under Apache 2.0, you can download it and test the trade-off on your own workloads. As with any single-lab result, the reported numbers are worth an independent replication before you bet a budget on them, but the direction is hard to argue with: the smartest model is often the one that thinks just enough.

Got an article suggestion? Let us know

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.