Prompting DeepSeek's Reasoning Models

TL;DR: DeepSeek-R1 is gone. The live reasoning-capable models are deepseek-v4-flash and deepseek-v4-pro, both with thinking mode on by default. DeepSeek publishes no dedicated prompting guide, but its docs do specify real, checkable parameter behavior: sampling controls go silent during thinking, and reasoning_effort accepts low, high, and max.

Most existing advice on deepseek reasoning prompts was written for DeepSeek-R1 and the deepseek-reasoner endpoint. Both are retired. This page is built entirely from what's currently live at api-docs.deepseek.com and DeepSeek's own model card, re-checked on 2 and 3 September 2026, with every model name and parameter default read directly off those pages rather than carried forward from an older post.

Which DeepSeek models actually reason now?

Two, and neither is the one most guides still name. DeepSeek's own docs confirm that deepseek-chat and deepseek-reasoner, the split "chat model / reasoning model" pair that R1-era advice was built around, were fully retired after July 24, 2026, 15:59 UTC. Requests to those IDs now route to deepseek-v4-flash in non-thinking or thinking mode.

The current lineup, per DeepSeek's Models & Pricing page, is deepseek-v4-flash, deepseek-v4-pro, and a vision-capable deepseek-v4-flash-vision-exp. There's no separate reasoning-only model any more: both deepseek-v4-flash and deepseek-v4-pro support thinking mode as a setting on the same model ID, and thinking is on by default at high effort on both. That's a real structural change from the R1 era worth internalizing before you read anything else about "DeepSeek's reasoning model," because the question itself no longer has a single answer.

For scale: DeepSeek-V4-Pro ships as a 1.6T-parameter (49B activated) mixture-of-experts model and DeepSeek-V4-Flash as 284B (13B activated), both supporting a 1M-token context window as the default across DeepSeek's own services, per DeepSeek's V4 Preview release notes. In its highest reasoning-effort setting, which DeepSeek's own model card calls Think Max, DeepSeek-V4-Pro resolves 80.6% of tasks on SWE-bench Verified. That number comes from the model card on Hugging Face, not from api-docs.deepseek.com, so if you go looking for it, that's the page to check rather than a secondary roundup.

How do you actually turn reasoning on or off?

Two parameters, and DeepSeek documents three different wire formats depending on which SDK you're calling through. The OpenAI-compatible format uses thinking: {"type": "enabled/disabled"} to toggle the mode and reasoning_effort to set depth. The Anthropic-compatible format instead uses reasoning: {"effort": "none/low/high/max"}, where none is what disables thinking. The Responses API format uses output_config: {"effort": "low/high/max"}.

Thinking mode is on by default, at high effort, on both current models. DeepSeek's own effort-mapping table is worth reading carefully, because it accepts more input values than it documents as valid: low maps to low, medium maps to high, high maps to high, xhigh maps to high, and max maps to max. So a value like medium, which reads naturally if you're used to another vendor's five-tier vocabulary, doesn't error on DeepSeek. It just silently collapses to high, which is a different outcome than the value name implies.

Here's the shape of a thinking-mode call using the OpenAI SDK, matching DeepSeek's own sample code:

from openai import OpenAI

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

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "9.11 and 9.8, which is greater?"}],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}},
)

reasoning_content = response.choices[0].message.reasoning_content
content = response.choices[0].message.content

One multi-turn detail is easy to miss and changes what you should pass back on the next call. Whether the chain-of-thought (reasoning_content) from a previous turn gets carried into the model's context on the next turn depends on whether that next request includes a tools parameter. With tools present, prior reasoning_content should be passed back and is concatenated into context; without tools, it's ignored even if you send it. Building a multi-turn agent loop and a plain multi-turn chat on DeepSeek are two different context-management problems for this reason alone.

Does temperature do anything in DeepSeek's thinking mode?

No, and DeepSeek says so plainly. Its thinking-mode guide states: "Thinking mode does not support the temperature, top_p, presence_penalty, or frequency_penalty parameters. Please note that, for compatibility with existing software, setting these parameters will not trigger an error but will also have no effect." That's a silent no-op, not a rejected request, which is the failure mode most likely to go unnoticed: your call succeeds, your temperature setting is simply ignored.

It gets messier than one clean rule, because DeepSeek's own site disagrees with itself across three other pages. A separate, older page still recommends specific temperatures by use case (0.0 for coding and math, up to 1.5 for creative writing); it carries a Last-Modified header from mid-April 2026, before the V4 lineup shipped, and its own sidebar is frozen at a pre-V4 navigation tree, one clear sign it's stale rather than current guidance. Separately, DeepSeek's V4 model card on Hugging Face recommends different numbers again, for a different situation: "For local deployment, we recommend setting the sampling parameters to temperature = 1.0, top_p = 1.0." That advice is aimed at people running the open weights themselves, not at API callers, and it says nothing about what happens once thinking mode is engaged. Treat all of this as DeepSeek's own documentation being genuinely inconsistent, not as a puzzle you're supposed to resolve into one rule; the one instruction that's unambiguous is that thinking mode itself ignores the parameter outright.

Does DeepSeek publish real prompting guidance, or is it mostly generic?

Mostly generic, and that's a more useful answer than inventing DeepSeek-specific folklore to fill the gap. Searching api-docs.deepseek.com's own sitemap turns up no dedicated prompt-engineering or prompting-best-practices page at all, a strikingly different picture from OpenAI's or Google's docs, which each carry an explicit reasoning-model prompting guide. DeepSeek's own Prompt Library page exists in the site's navigation, but fetching it directly returns a client-rendered shell with a title and a one-line tagline and no actual prompt entries in the served page, so don't cite its contents from a search summary; there isn't visible content to summarize.

What DeepSeek does publish, instead of general prompting advice, is a set of concrete, checkable parameter behaviors that genuinely change how you'd write a prompt or structure a call:

• Sampling goes silent in thinking mode. Covered above: temperature and its neighbors stop doing anything the moment thinking is enabled, which is the default.
• reasoning_content handling depends on the tools parameter, not on anything in your prompt text. If you're building an agent loop with tool calls, DeepSeek expects the prior turn's chain-of-thought passed back; in an ordinary chat without tools, it's discarded.
• The highest reasoning tier injects DeepSeek's own system prompt. DeepSeek's model card describes three reasoning-effort tiers for both current models, Non-think, Think, and Think Max, and for Think Max specifically the documented response format is Special system prompt + <think> thinking </think> summary. In that mode, DeepSeek adds instructions of its own ahead of yours; a system prompt you've carefully tuned for the other two tiers doesn't necessarily carry the same effect once you switch to Think Max.
• Model-name mapping happens automatically on the Anthropic-compatible endpoint. DeepSeek's own compatibility notes state that model names starting with claude-opus are mapped to deepseek-v4-pro, and names starting with claude-haiku or claude-sonnet are mapped to deepseek-v4-flash. That's a routing detail, not a prompting one, but it changes which model actually answers if you're pointing an existing Claude-based tool at DeepSeek without editing its model name.

Should you tell it to think step by step?

DeepSeek doesn't say, in either direction, anywhere in its current docs. That's a real gap worth naming rather than filling with a guess. The closest thing to cross-vendor consensus comes from elsewhere: OpenAI's reasoning guidance states that instructing a reasoning model to think step by step is unnecessary, since the model already reasons internally before answering, and Google's migration guidance for Gemini 3 gives the same advice to anyone carrying over chain-of-thought scaffolding from an older, non-reasoning model. Anthropic is the documented outlier among major vendors, treating whether a model thinks on a given turn as something you can deliberately prompt for rather than something to avoid instructing at all.

Absent a DeepSeek-specific statement, the safer default is to treat DeepSeek's reasoning models the same way: give a clear goal and constraints, and let the model's own thinking process do the step-by-step work rather than scripting it in your prompt. If you're routing between reasoning and non-reasoning models generally rather than DeepSeek specifically, our post on chain-of-thought prompting covers where that technique still helps and where it's now redundant.

Using DeepSeek inside Claude Code and other coding agents

This is the one area where DeepSeek's own documentation gets genuinely specific rather than generic, because it's aimed at a narrow, well-defined integration rather than prompting in the abstract. DeepSeek publishes setup instructions for pointing Claude Code, OpenCode, and OpenClaw at its API, and the Claude Code instructions are the most concrete: set ANTHROPIC_BASE_URL to DeepSeek's Anthropic-compatible endpoint, set ANTHROPIC_MODEL to deepseek-v4-pro[1m] (the bracketed suffix denotes the explicit 1M-context configuration used for this integration), and set CLAUDE_CODE_EFFORT_LEVEL to control how hard the model reasons on each turn, max being one documented value.

That last variable is worth calling out on its own: it's an environment variable controlling reasoning depth for an entire coding-agent session, sitting completely outside the prompt itself and outside the reasoning_effort API parameter described earlier. If you're debugging why a DeepSeek-backed coding agent seems to reason more or less than a raw API call with the same reasoning_effort value, this variable is the first place to check, not your prompt wording.

If you're deciding whether Claude's own extended thinking or DeepSeek's thinking mode fits a given agent workflow better, our post on prompting Claude's extended thinking and our broader look at reasoning models versus chat models cover the Anthropic side of that comparison in more depth than fits here; both are being finalized as companion pieces to this one.

What this means for pricing, and why reasoning tokens aren't free thinking

DeepSeek bills chain-of-thought output the same as any other output token, at the same per-model rate, which matters because thinking is on by default. Its current pricing table sets off-peak output at $1.98 per million tokens for deepseek-v4-pro and $0.66 for deepseek-v4-flash, rising to $3.96 and $1.32 respectively at peak. DeepSeek's own pricing page states it plainly: "Off-peak rates are half of the peak rates. Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday (all other hours are off-peak)." A higher reasoning effort setting doesn't change the per-token rate, but it does tend to produce more reasoning tokens before the visible answer starts, and every one of them is billed as output.

Cache-hit input pricing is the more dramatic lever if your prompts share a lot of fixed prefix text: on DeepSeek's current table, a cache-miss input token costs roughly 30 times what a cache-hit input token costs, for both models. That's a caching-strategy question rather than a prompting-style one, but it interacts with reasoning mode indirectly, since a longer system prompt or few-shot block sitting ahead of a reasoning call is exactly the kind of fixed prefix caching is meant to reward, if it's structured to hit the cache consistently. Note that caching applies to input tokens only; the reasoning and output tokens a thinking-mode call generates are billed at the full output rate regardless of what came before them in the prompt.

What actually changes in your prompt for DeepSeek's reasoning models

Strip out the instructions that were compensating for a model that couldn't reason on its own, and don't add new ones DeepSeek never asked for. Concretely: drop "think step by step" and "explain your reasoning" instructions, since the model does this internally regardless and DeepSeek gives no indication those phrases help. Keep your instructions to a clear goal, real constraints, and an explicit output format, and let reasoning_effort (or the equivalent field in whichever SDK format you're using) do the work of deciding how much internal reasoning happens.

Name the actual model. deepseek-v4-pro and deepseek-v4-flash behave differently enough, in size and in default concurrency limits, that a guide written against deepseek-reasoner is describing infrastructure that's gone. Check which model you're pointed at before assuming a piece of R1-era advice still applies to it. And if you're building anything that carries reasoning content across turns, decide up front whether your calls include a tools parameter, because that single field silently decides whether DeepSeek keeps or drops the model's own chain-of-thought between turns, independent of anything in your prompt.

If your workflow moves between DeepSeek and other reasoning models rather than staying on one, our guide to prompting Qwen's reasoning models and our roundup of DeepSeek-specific prompt tools and templates cover the adjacent ground this page didn't, including the enable_thinking toggle Qwen uses instead of DeepSeek's thinking field, and a token-efficient template set built specifically around DeepSeek's pricing structure in our DeepSeek prompt templates piece.