DeepSeek-V4-Pro Thinking Levels and Tool-Calling Workflow

One-sentence takeaway

V4-Pro enables thinking by default and uses high as the default effort level; use low for simple tasks, high for day-to-day Agents, and max for complex tasks, and pass the complete reasoning_content back on every round of a tool call.

Use cases

• Suitable tasks: Multi-turn tool calls, code Agents, complex planning, and API workflows that require continued reasoning based on tool results.

• Unsuitable tasks: Treating max as the default for every request, or concatenating multi-turn messages directly without saving the assistant state.

• Applicable model versions: deepseek-v4-pro; the official page states that the same effort mapping also applies to deepseek-v4-flash, while this article focuses on Pro.

• Applicable clients, Agents, or APIs: OpenAI-compatible Chat Completions, Anthropic format, and the Responses API; the tool chain must replay fields according to the corresponding protocol.

• Recommended reasoning levels and parameters: low for simple tasks, high for day-to-day Agents, and max for complex tasks; thinking mode does not support temperature, top_p, or presence/frequency penalties.

Ready-to-use content

Minimal configuration for OpenAI-compatible Chat Completions (official parameter names):

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": "Inspect the repository, use tools only when needed, and return evidence plus the smallest safe fix.",
    }],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}},
)

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

Loop skeleton for a tool Agent (retain the assistant's complete message to avoid losing thinking/tool fields):

while True:
    response = client.chat.completions.create(
        model="deepseek-v4-pro",
        messages=messages,
        tools=tools,
        reasoning_effort="high",
        extra_body={"thinking": {"type": "enabled"}},
    )

    assistant = response.choices[0].message
    messages.append(assistant)

    if not assistant.tool_calls:
        break

    for call in assistant.tool_calls:
        result = run_tool_safely(call.function.name, call.function.arguments)
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result,
        })

Testing/workflow steps

1. Establish an effort baseline by task bucket: low for simple Q&A, high for day-to-day Agents, and max for complex long-horizon tasks.

2. When tools are enabled, add the complete assistant message returned each time (including reasoning_content and tool_calls) to the history unchanged.

3. Before executing a tool, validate the function name, parameters, and side effects; return tool results as structured text and have the model continue to the next round.

4. End the current loop when there is no tool call; save the final content together with the tool trace, errors, duration, and tokens.

5. For the same task, compare the success rate, overthinking, latency, and cost of low/high/max; do not choose a level based on a single subjective experience.

Original evidence and data

• DeepSeek's official table: the thinking toggle can use OpenAI's thinking.type or Responses' reasoning.effort; none disables it, while low/high/max control effort.

• Thinking is enabled by default and the default effort is high; requested medium, high, and xhigh all map to actual high, while max maps to max.

• After a tool call, reasoning_content must be passed back in full in all subsequent requests; otherwise the API returns 400.

• Thinking mode does not support temperature, top_p, presence_penalty, or frequency_penalty; even if the compatibility layer does not return an error, those settings will not take effect.

Applicability boundaries

• The official example uses a weather function to demonstrate the loop; this does not mean that the weather data is real or that the tool itself is safe. In production, replace it with tools that have appropriate permissions and are auditable.

• reasoning_content is part of the protocol state; whether to show it to end users should be determined by product strategy. Do not treat internal reasoning text as unverified evidence.

• Field locations differ across SDKs/protocols; in the OpenAI SDK, thinking must be placed in extra_body, while the Responses API uses reasoning.effort.

• The effort mapping table reflects the current DeepSeek documentation and should be checked again after model updates.

Source excerpt or observation (compliance short quote only)

The official documentation explicitly states that reasoning_content in a tool request “must be fully passed back to the API”; otherwise, it returns 400.