Ground Truth.
AI, checked against the source.

News · 2026-08-02

DeepSeek's low effort setting writes more than its high setting, because the dial is just a prompt

DeepSeek V4 Flash consumes substantially more tokens on its low reasoning-effort setting than on high, a result one tester reproduced across four prompts run repeatedly against both a local copy and DeepSeek's hosted API. The cause is visible in DeepSeek's own released code: the effort setting is not a compute dial or a separate model, it is a prompt prefix, and low prepends nothing at all.

Key facts

Most people using a modern reasoning model assume the effort or thinking-budget setting works like a throttle: turn it up, the model does more internal computation and costs more; turn it down, it does less and costs less. That mental model is reasonable, it matches how the settings are marketed, and for this model it is wrong.

Open DeepSeek's encoder and the machinery is entirely visible. Selecting high causes the library to prepend a long instruction telling the model to deliberate exhaustively before answering. Selecting max prepends a more forceful version. Selecting low prepends nothing whatsoever — it is the bare default, the model with no instruction about how to think. There is no separate checkpoint, no router, no hidden compute allocation. The dial is a template.

Once you see that, the inversion stops being mysterious and becomes almost obvious. Given no guidance, a model with a large thinking budget has no imposed structure on its deliberation, and it can wander: restating the problem, exploring tangents, circling. Given a forceful instruction to reason exhaustively, it produces organised deliberation with a recognisable shape, and organised deliberation terminates. The instruction that sounds like it should cost more actually acts as a container. Anyone who has watched a colleague ramble through an unstructured problem, then tighten up considerably when asked to write a structured memo, has seen the same effect.

The token-budget side compounds it. DeepSeek recommends allowing up to 384,000 output tokens for high and max, which means an effort label also implies a completion-cap expectation. And the hosted and local defaults diverge: the API documentation says the hosted default is high, while a bare local invocation gets low. Two developers running "the same model with default settings" in the two environments are running measurably different systems.

The important limit on this result is what it does not show. The reproduction measures verbosity and cost, not correctness. DeepSeek's own earlier V4 evaluation reports the high and max settings generally outperforming non-thinking modes on reasoning and coding benchmarks, and nobody has published evidence that low produces better answers. The honest summary is that a setting labelled "low effort" can be the more expensive one to run, which is a billing and latency problem, not a quality finding.

That makes this a product-design story more than a model story. An effort control that is really a prompt prefix, defaults differently across two surfaces, and inverts on token cost is a genuine trap for anyone building an agent against a budget — and agents are exactly where these settings get used, since a long tool-using loop multiplies any per-call token surprise across dozens of steps. The practical instruction is to pin the exact encoder version and an explicit output budget, and to measure token consumption per setting on your own workload rather than trusting the label.

It also fits the week's pattern around this release. Three days after launch, the interesting findings about V4 Flash are not benchmark scores but plumbing: which speculative-decoding head is actually in the checkpoint, what happens when you quantize its cache in the wrong format, and now what the reasoning settings literally do. All three are cases where a label and the underlying implementation drifted apart.

The caveat is scale. This is one tester, four prompts, run repeatedly — enough to establish that the inversion is reproducible in two environments, not enough to characterise how it behaves across task types, prompt lengths or the max setting. What makes it credible is not the sample size but the mechanism: the encoder is public, and anyone can read exactly what each label does.


Primary source, verified: read the paper →

Key questions

Why does low use more tokens than high?

Because low injects no instruction at all, leaving the model to deliberate without any imposed structure, while high prepends a paragraph telling it to reason exhaustively, which paradoxically produces more organised and terminating output.

Does that mean low is smarter than high?

No. The reproduction measured token consumption, not correctness, and DeepSeek's own earlier evaluation of V4 shows the high and max settings generally outperforming non-thinking modes on reasoning and coding tests.

What should a developer actually do about it?

Pin both the exact encoder version and the output token budget rather than relying on the effort label, and be aware that DeepSeek's API documentation says the hosted default is high while a local checkpoint defaults to low.
Cite this

APA

Ground Truth. (2026, August 2). DeepSeek's low effort setting writes more than its high setting, because the dial is just a prompt. Ground Truth. https://groundtruth.day/news/deepseeks-low-effort-setting-writes-more-than-its-high-setting.html

BibTeX

@misc{groundtruth:deepseeks-low-effort-setting-writes-more-than-its-high-setting,
  title  = {DeepSeek's low effort setting writes more than its high setting, because the dial is just a prompt},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {aug},
  url    = {https://groundtruth.day/news/deepseeks-low-effort-setting-writes-more-than-its-high-setting.html}
}

Topics: deepseek · prompting · api-design · inference · reasoning · local-ai

Comments are replies to this story on Bluesky — reply with any Bluesky account to join in.