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
- The finding: in both a local quantised copy and the hosted API,
lowused substantially more reasoning and output tokens on average thanhigh, across four prompts run repeatedly. - The cause: in DeepSeek's released 0731 encoder,
lowinjects nothing,highprepends a long instruction to reason exhaustively, andmaxprepends a stronger version of the same. - A second trap: DeepSeek's API documentation states the hosted default is
high, so local and hosted callers do not start from the same behaviour. - Primary source: the encoder file in DeepSeek's official model repository, alongside the community reproduction.
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.
Key questions
Why does low use more tokens than high?
Does that mean low is smarter than high?
What should a developer actually do about it?
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}
}
Comments are replies to this story on Bluesky — reply with any Bluesky account to join in.