DeepSeek V4.1 Flash Reasoning Effort: The 1-100 Dial Explained

V4.1 Flash replaces the old low/high/max reasoning switch with a continuous integer from 1 to 100. You set it with the `reasoning_effort` field, and the value directly controls how much reasoning the model does before it answers^[1][3].

The old V4 Pro and V4 Flash exposed three named levels. V4.1 Flash generalizes that into a dial. Named presets still exist for convenience, but underneath they are just integers on the same scale, and the integer is what the model actually reads^[1][5].

Thinking is on by default. If you send no effort field at all, the model reasons at its default level rather than skipping the trace. To reason less, lower the number. There is a separate non-thinking mode used for FIM and chat prefix completion, but lower effort is the normal way to reduce reasoning on a thinking call^[1].

• Field: reasoning_effort
• Range: continuous integer 1 to 100
• Thinking: enabled by default
• Non-thinking mode: required for FIM and chat prefix completion^[1][3]

The two main sources that document presets disagree on the mapping, and the disagreement matters. The vLLM recipe lists low=25, high=50, xhigh=75, max=100. The official API, as reported by VentureBeat, lists low=50, high=75, max=100^[5].

There is no contradiction in the model itself — only in which integer each label points to. The safest engineering practice is to send the integer you actually want and not rely on a label whose meaning may differ between a local vLLM server and the hosted API^[5][6].

This matters most for teams that run the same configuration in both places: a local eval harness on vLLM and a production deployment on the hosted endpoint. If "high" means 50 in one and 75 in the other, latency and cost will silently diverge even though the config file looks identical^[5].

When you set neither the thinking flag nor the effort value, V4.1 Flash runs thinking on at effort 50. That is a middle setting: it reasons, but not at maximum depth^[5].

Effort 50 is a reasonable default for chat and general agent work. It is not the setting DeepSeek used for the headline benchmark table, which was run at max effort 100. The distinction explains why a model that looks dominant on a leaderboard can feel ordinary under default settings^[2][5].

For simple classification, extraction, or formatting tasks, effort 50 can still be more reasoning than needed. Lowering it reduces both latency and output tokens without hurting accuracy on tasks that do not require a chain of thought. That is free money for high-volume, low-difficulty traffic^[5].

DeepSeek's own tests quantify the trade. Going from effort 25 to effort 100 raises DeepSWE v1.1 from 66.0 to 74.2 and Terminal-Bench 2.1 from 82.4 to 90.6, but consumes roughly 2.5x the output tokens^[5].

The gains are real but front-loaded. DeepSeek says effort levels between 60 and 80 recover most of the accuracy at less than half the token budget. The final climb to 100 makes agent trajectories 1.6-1.8x longer for comparatively small marginal returns^[5].

This is the classic reasoning-length curve: the first increments of thinking buy the most accuracy, and the tail buys little for a lot. The economical operating point is almost never the maximum, unless the task is one where being wrong is far more expensive than the extra tokens^[5].

• 25 to 100 raises DeepSWE from 66.0 to 74.2
• 25 to 100 raises Terminal-Bench 2.1 from 82.4 to 90.6
• Output tokens: roughly 2.5x across that range
• 60-80 recovers most accuracy at under half the token spend
• The last step to 100 lengthens trajectories 1.6-1.8x^[5]

Choice of effort is a product decision as much as a technical one. Match the level to the cost of being wrong, not to the model's maximum capability^[5].

A practical method: run your own eval sweep at 25, 50, 75, and 100, plot accuracy against output tokens, and pick the point where the curve flattens. Because the optimal point is workload-specific, a generic recommendation is worth less than your own measurements^[5].

It also helps to separate task classes. Most products contain several: a cheap autocomplete path, a medium analysis path, and a rare hard path. Assigning a single global effort wastes budget on the easy path and underserves the hard one^[5].

• Effort 1-25: classification, extraction, formatting, short chat replies
• Effort 25-50: routine code edits, summarization, standard RAG answers
• Effort 50-80: multi-step agents, debugging, tasks where a wrong answer is expensive
• Effort 80-100: hardest math, competition coding, security analysis, one-shot high-stakes tasks
• Default 50: a safe starting point when you have no benchmark data

Effort is passed as an integer in the request body. The same value works for chat completions and the Responses API, so a single helper can serve both call styles^[1][6].

In thinking mode, sampling parameters such as temperature and top_p are not the primary control — the effort value is. If you enable tools and multi-turn conversation, remember to echo the previous assistant `reasoning_content` back in the next request, or the call can fail with a 400^[3].

Keep the effort value in one constant shared by your chat path and your Responses path. Duplicating the number in two places is the easiest way to end up with an eval that measures a different setting than production runs^[1][6].

from openai import OpenAI

client = OpenAI(
    api_key="<DeepSeek API Key>",
    base_url="https://api.deepseek.com",
)

# Chat Completions
response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{"role": "user", "content": "Refactor this function."}],
    reasoning_effort=75,          # integer 1-100, not "high"
    extra_body={"thinking": {"type": "enabled"}},
)

# Responses API: same model id and the same 1-100 effort value.
# Confirm the exact effort field name against the official
# Responses API guide before shipping.

print(response.choices[0].message.content)

Reasoning tokens bill at output rates, so effort compounds directly into cost. A max-effort agent run can spend several times the tokens of its default-effort twin for the same task^[5].

The interaction with caching is subtle. Effort does not change cached input cost — cached tokens still bill at the cheap cache-hit rate — but it increases the output side, which is the expensive side. That is why the cache-hit price and the effort setting should be tuned together rather than separately^[5].

A good operating policy: set a conservative global default, raise effort only for task classes that justify it, and re-measure whenever the underlying model changes. Because DeepSeek reroutes retired ids to new checkpoints, an effort setting you tuned months ago may now sit on a different model^[5][1].

• Reasoning tokens count as output tokens
• Cache hits stay cheap regardless of effort
• Higher effort raises the expensive output line, not the cheap cache line
• Re-measure effort after any model or checkpoint change^[5]