I’d love to understand the logic behind giving the user the option to disable “THINKING,” only to turn those “thinkings” into “EXPLANATION” instead—LOL. The user thinks they’ll save money and time on tasks, but the exact opposite happens: the output costs more, and the wait time remains the same.
Hey, thanks for the feedback. There’s an important distinction here that’s worth clearing up.
“Thinking” (reasoning) is the model’s internal reasoning process, a separate layer that happens before the answer. The normal explanatory text the model writes in its reply like “I’ll do X because Y” is part of the standard output, not reasoning. So turning off thinking removes reasoning tokens, but it doesn’t force the model to answer in a short way. It can still explain what it’s doing in the reply itself. This isn’t renaming thinking to “explanation”, they’re different things.
To understand what’s happening in your case more precisely, can you share:
- Which model are you using?
- Where exactly do you see “EXPLANATION”, in chat or in agent?
- If you can, a screenshot.
You can check the general mechanics for tokens and pricing here: Models & Pricing | Cursor Docs
I’ll pass your feedback about the communication around the toggle to the team too. The wording really can be confusing.
The behavior is exactly as I described. With THINKING active, the model thinks, investigates, explains, and edits; with thinking disabled, the model explains, reads, explains, explains, explains, explains… Disabling THINKING literally increases the amount of explanation by at least 50%.
Disabling the THINKING process increases the cost of the operation. We know that every output token becomes an input token in the next round…
“I understand that thinking tokens and explanation tokens are different. My point is not that they are the same. My point is that, in an agentic workflow, disabling thinking causes substantially more visible explanatory output in my tests. That output becomes part of subsequent agent context, so removing reasoning tokens can be offset—or even outweighed—by additional output and accumulated context. Therefore, the toggle does not behave as a reliable cost/latency optimization for agentic tasks.”
Same accounting bit us on the MCP side last week. We measured a 5-server, 46-tool setup at 9,012 tokens of raw tools/list payload before any of the model’s own text went in, and the only thing that moved the bill was shrinking what had to be replayed: 6,122 in a bridge-compatibility mode, 157 once the agent got a name-only index and fetched a schema when it actually needed one. Your point has the same shape: disabling thinking doesn’t delete the work, it moves it into the visible channel, and the visible channel is the one that comes back as input on every later turn. Before trusting that toggle, check whether your provider bills reasoning tokens at a different rate than output - if it doesn’t, the switch is cosmetic and both land in the same bucket.
Fair point, and you’re right about the mechanics. Reasoning tokens are billed as output, so they land in the same billing bucket as the normal answer text, as @San_zhang2 correctly noted. So if in non-thinking mode the model produces noticeably more visible explanatory text, the savings from reasoning can be partly or fully offset by that extra output, especially in an agentic loop where the previous turn’s output comes back as input on the next turn.
One important nuance. Disabling thinking does not “rename” reasoning into explanation. Verbosity in the answer is a behavior of the specific model, not Cursor moving reasoning into the visible channel. Different models behave differently here, and without a reasoning layer, some tend to compensate with a longer answer.
What you can do in practice to keep output shorter. Add a rule with an explicit instruction to be concise, for example “be concise, minimal explanation, no step-by-step narration unless asked”. This can noticeably reduce visible output regardless of thinking mode. More on rules: Rules | Cursor Docs
I’ll pass your observation along to the team that the toggle does not behave like a reliable cost or latency optimization in agentic tasks. That’s useful feedback. If you have a concrete example handy, model plus a couple of side-by-side runs with and without thinking, send it over. That’ll make the feedback even more actionable.