The Reasoning Dial: Spend It Where There Is Something to Search

It is not a preference between careful and hasty. It is an accuracy and cost trade, made per request, that most people never touch.

Reasoning depth is a dial, and it has a price

Extended reasoning — the model working through a problem before answering — is on by default in most agent tooling, because it substantially improves results on the kind of work these tools are used for. That default is a considered one and it is right for hard problems.

It is also billed. Reasoning tokens are output tokens, and the budget can run to tens of thousands per request depending on the model. So the dial is not a preference between careful and hasty; it is a trade between accuracy and cost, made per request, and most people never touch it.

The argument here is that leaving it at the default for everything is wrong in both directions: you overspend on the majority of work that does not need it, and you get worse at the minority that would benefit from more.

Where deep reasoning earns its cost

Architectural decisions, where the value is in considering alternatives you would not have thought of. Debugging with several interacting causes, where the failure is in the interaction rather than in any one component. Planning a change across many files, where the ordering matters. Anything involving a constraint that has to be satisfied simultaneously with several others.

The common property: the problem has a search component. There are several plausible paths and the right one is not evident from the first step. That is precisely what the extra tokens buy, and on those tasks the return is substantial.

Where it is waste

Renaming a symbol across a codebase. Applying an established pattern to a new case. Formatting. Writing a test that mirrors eleven existing tests. Translating a well-specified change into code. Answering a factual question about a file.

None of these have a search component. The path is evident, and reasoning about it at length produces the same answer more expensively and more slowly. The latency matters too: on an interactive task where you are waiting, a thinking budget you did not need is a pause you did not need.

Match the effort to the task, not to the session

The practical shift, and the one that requires an actual habit rather than a configuration change. Effort is adjustable mid-session, and most sessions contain both kinds of work.

A typical task: think hard about the approach, then implement it mechanically, then think hard again about the edge cases. Setting one level for that whole session means either paying for deep reasoning during the mechanical middle or getting shallow reasoning on the two parts where it mattered. Turning the dial twice costs nothing and matches the spend to the difficulty.

The failure of always-maximum

Some people, having read that more reasoning improves accuracy, set it high permanently. This is expensive and it is not straightforwardly better.

On simple tasks the extra reasoning does not improve the answer, because there was nothing to search. It does add latency, which changes the interaction: a loop where each step takes twenty seconds instead of five is a loop you engage with differently, and worse. And it consumes budget that would have been better spent on the two hard problems later in the day.

The failure of always-minimum

The opposite adaptation, usually arrived at after a cost conversation, and worse. Turning reasoning down globally saves money on the mechanical work and degrades exactly the tasks the tool was adopted for.

What makes this insidious is that the degradation is not obvious. Output is still produced, still plausible, still passes the tests. The failure is in the things not considered, which by definition do not appear in the result. A team that has quietly turned reasoning down is getting worse answers without any signal that it is happening.

Model choice and effort are separate dials

Frequently conflated, and they trade differently. A smaller model with generous reasoning and a larger model with minimal reasoning are different things, and the right combination depends on whether the task is hard because it requires knowledge or hard because it requires search.

For most mechanical work the answer is a smaller model at low effort, which is cheap on both dials. For architectural work it is the larger model with room to think. The combination worth avoiding is the largest model at maximum effort for a task neither dimension helps with, which is what you get by setting both once and never revisiting.

Delegated work should have its own setting

An easy win that most configurations miss. When a task is delegated to a subagent — run the tests and summarise, search the codebase for occurrences, fetch and condense some documentation — that subagent does not need deep reasoning, because its job is retrieval and summarisation.

Setting a cheaper model and lower effort for those roles is often the single largest saving available in a heavy workflow, precisely because delegated work is high volume and low difficulty. It also makes them faster, which shortens the whole loop.

Test it on your own work

The general claims above are worth checking against your specific repository, and the experiment is easy to run: take five representative tasks, run each at two effort levels, and compare the results and the consumption.

Do it with tasks that have a definite answer — a bug with a reproduction, a refactor with a test suite — so the comparison is about correctness rather than impression. The usual result is that two of the five genuinely need the higher setting and three do not, which tells you where your own boundary sits far better than any general guidance.

Reasoning is not verification

An important distinction, because people sometimes raise the effort level in place of checking the work. More reasoning makes a wrong answer less likely; it does not make it detectable. A confidently wrong result produced with a large thinking budget looks exactly like a correct one.

So the dial is not a substitute for a test, a check, or a review. Its role is to improve the first attempt on problems where the first attempt is hard, and everything about verifying the output stays where it was — which is the argument in TDD-style agentic loops, unchanged by how long the model thought.

What the visible cost tells you

One useful side effect of paying attention to this dial: the thinking budget consumed on a task is a rough measure of how hard the model found it, and that is information about your codebase.

A task that should have been mechanical and consumed a large amount of reasoning usually means the code is harder to reason about than it should be — an unclear abstraction, an implicit contract, a convention that is not written down. That signal is available for free and almost nobody looks at it.

What I would actually configure

A moderate default rather than the maximum. A deliberate raise for planning, architecture and hard debugging, and a lower setting during mechanical implementation. A cheaper model at low effort for delegated retrieval and summarisation. And a periodic check that the settings still match the work, because effort levels set during one project tend to persist into a different one where they no longer fit.

That is a few minutes of configuration and a habit of turning a dial twice per task. It costs less than either extreme and produces better results than the one that costs more, which is an unusually good trade.

The dial and the loop are different levers

Worth separating, because they get confused. Raising the reasoning effort makes a single attempt better. Building a feedback loop — write a test, run it, react to the failure — makes a sequence of attempts converge. They solve different problems and the second is usually the better investment.

A well-constructed loop with moderate reasoning outperforms maximum reasoning with no verification, on almost everything, at lower cost. The reason is simple: the loop has access to ground truth and the reasoning does not. If you are choosing where to spend effort, build the loop first and treat the dial as a refinement on top of it.

Where the default is genuinely fine

Having argued for adjusting it, most people should adjust it in one direction only: down, for mechanical work, and leave it alone otherwise. The default is set for the tasks these tools are used for, and it is a reasonable choice.

The exception is heavy delegated workflows, where the volume of low-difficulty subagent work makes a per-role setting worth configuring properly. Outside that, the returns come from noticing when you are about to spend twenty minutes of deep reasoning on a rename, and turning it down for those ten minutes.

A note on latency as a quality factor

Underrated in these discussions. On interactive work, response time changes how you use the tool: a fast loop invites iteration and correction, a slow one invites you to accept the first answer because asking again is expensive in attention.

So high reasoning effort on interactive tasks can reduce quality through a channel that has nothing to do with the model — it makes you a worse collaborator, because you stop interrupting and refining. That is a real effect, it is invisible in any benchmark, and it is a reason to keep the interactive setting lower than you might on pure accuracy grounds.

Effort settings drift, so re-check them

A maintenance note that applies to every configuration in this area and particularly to this one. An effort level chosen during a hard project stays selected through the easy one that follows. A cheap setting adopted during a cost review persists into work that needed the depth.

Neither produces an obvious symptom, which is why it drifts. Put it on whatever periodic review you already do — the same pass where you check which tool integrations are still in use is a natural home — and ask whether the current settings match the current work. It takes a minute and it catches a mismatch that would otherwise persist for months.

The summary I would give a team

Leave the default where it is for ordinary work. Turn it up deliberately for architecture, planning and hard debugging, and back down for the mechanical middle of a task. Give delegated retrieval work a cheap model and a low setting, because it is high volume and low difficulty. Build the verification loop before you touch the dial at all, because ground truth outperforms deliberation. And check the settings occasionally, because they outlive the project that justified them.

One closing observation on why this dial goes untouched. It sits in a settings screen, it has a sensible default, and nothing ever prompts you to reconsider it — there is no moment where the tool says "this task did not need that". Almost every other lever in an agent workflow announces itself through friction; this one is silent in both directions, which is exactly why it is worth putting on a checklist rather than trusting yourself to notice.