Report

Should you turn thinking off? What reasoning mode costs on a local LLM, measured

Reasoning mode on a local model delays the first visible word from a blink to a wait and multiplies the cost of automation — and on every task with a hard right answer in our gates it bought nothing. The measured trade, and where it does not apply.

lab_repeated internal research August 20, 2026 · Funding: Self-funded internal research

The short, measured answer: for everyday chat and for structured automation on this box, thinking mode bought nothing our gates could detect and cost between one and two orders of magnitude of waiting. Off is the right default for these workloads. The numbers, and the honest boundary of that advice, follow.

Every reasoning-capable local model ships with the same silent question: leave the thinking block on, or suppress it? The debate usually runs on vibes — “it feels smarter” against “it feels slow”. Both feelings have measurable substance, and only one survived our gates.

How long until the first visible word?

With reasoning off, the assistant’s first answer token arrives in 210msunit_replicated — a blink. With reasoning on, the same model on the same box takes 20191msunit_replicated to say its first visible word. Not to finish — to begin.

Note the metric: time to first answer token. A dashboard watching time to first token of anything would show both modes near-instant, because the thinking stream starts immediately — it is just not addressed to the user. That measurement gap is its own report.

What does it cost an automation?

Chat hides latency behind streaming; a pipeline does not. A strict-JSON task completes end-to-end in 844msrepeated with reasoning off, against 14677msrepeated with a standard thinking budget. For a queue of automated calls that multiplier is the difference between a tool and a bottleneck.

What did thinking buy?

On our gates: nothing detectable. Strict-JSON task success — output parses, matches ground truth per key — came back at 100.0% of requestsrepeated with reasoning off and 100.0% of requestsrepeated with it on. The everyday-assistant corpus showed the same picture through its format, language and repetition gates. Identical quality, one to two orders of magnitude apart in time.

Where this advice ends

Read the scope before quoting the verdict. Our corpora are everyday requests and deterministic short tasks with closed label sets — workloads where the answer is checkable and the model already knows it. Genuinely hard problems — multi-step math, novel planning — are exactly where reasoning modes earn their keep, and our workloads do not probe them. The honest statement is narrow: if your load looks like chat and structured automation, thinking is a tax with no measured return; if your load is hard reasoning, this page is not your evidence.

There is also a failure mode worth knowing before you leave thinking on with a small token budget: a model can spend the entire budget reasoning and return an empty answer under HTTP 200. We measured it on a frozen workload and then met it live on our own box. If you keep reasoning on, budget for it.

How to actually turn it off

Mechanics differ by runtime and template: llama.cpp accepts a chat-template switch for models whose templates support it, and most reasoning models respect an explicit no-think instruction or a reasoning-budget setting. Verify against the running server, not the docs — ask it what template and settings it resolved, then send one request and check whether a reasoning block appears. The side-by-side matrix for this model is on the comparison page.

Every number above has a permanent page with scope, limitations and raw runs: the claim registry.

Related tested configurations

Cite this report

AGmind Systems Lab (2026-08-20). Should you turn thinking off? What reasoning mode costs on a local LLM, measured. Evidence level: lab_repeated. https://agmind.ai/reports/should-you-disable-thinking-local-llm/
← Reports