Thinking-mode parameter selection

One-sentence takeaway

The current API uses deepseek-flash to access DeepSeek-V4.1-Flash; thinking mode is enabled by default with a default effort of high, request tiers map to low, high, or max according to the official mapping, and multi-turn requests with tools must return reasoning_content in full.

Use cases

• Suitable tasks: OpenAI-compatible Chat Completions calls, tasks that need reasoning effort adjusted by complexity, and multi-turn Agent workflows with function tools.

• Unsuitable tasks: Calls that rely on temperature, presence_penalty, or frequency_penalty to change thinking-mode output; clients that cannot save and return reasoning_content in full during tool-based multi-turn interactions.

• Applicable model versions: deepseek-flash. The official homepage says this name currently refers to DeepSeek-V4.1-Flash; the old names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but requests are served by V4.1-Flash.

• Applicable clients, Agents, or APIs: DeepSeek OpenAI-compatible Chat Completions; the documentation also lists the corresponding control fields for Anthropic format and the Responses API.

• Recommended reasoning tiers and parameters: This article recommends low for simple tasks, high for regular Agent workflows, and max for complex long-horizon tasks. Pass thinking.type="enabled" explicitly when stable intent expression is needed; preserve the complete assistant message in tool loops.

Ready-to-use content

OpenAI SDK configuration

The OpenAI SDK syntax shown on the official thinking mode page is as follows. thinking is an additional request-body field and must be placed in extra_body:

from openai import OpenAI

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

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

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

Control fields and tier mapping

The locations of the thinking toggle and effort field vary by protocol:

The actual reasoning tier used by the model is derived by mapping the requested tier:

Testing or workflow steps

1. Configure DEEPSEEK_API_KEY in the runtime environment and use https://api.deepseek.com as the OpenAI SDK's base_url.

2. Send a Chat Completions request with model="deepseek-flash"; following this article's editorial recommendation, choose low for simple tasks, high for regular tasks, and max for complex tasks, and add thinking.type="enabled" when an explicit toggle is needed.

3. Read reasoning_content and content from the assistant message. The former is the reasoning field returned in thinking mode, while the latter is the final answer field.

4. In ordinary multi-turn requests without tools, the previous turn's reasoning_content does not need to be sent back; even if it is sent back, it will not be concatenated into the next turn's context.

5. In requests with tools, add each complete assistant message returned to messages, preserving content, reasoning_content, and tool_calls, then append the tool result as role="tool" with the corresponding tool_call_id.

6. Repeat the request until the assistant no longer returns tool_calls. In subsequent requests with tools, even when the previous turn made no actual tool call, the previously generated reasoning_content must still be returned in full; otherwise, the API returns 400.

7. When validating parameters, do not treat temperature, presence_penalty, or frequency_penalty as thinking-mode controls; top_p takes effect in thinking mode, but values below 0.95 are raised to 0.95. When thinking is disabled, top_p is fixed at 1.0 and the supplied value is ignored.

The following pseudocode skeleton is organized around the official return constraints. run_tool, messages, and tools must be implemented by the integrator; this is not a complete, officially executable script:

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

    assistant = response.choices[0].message
    messages.append(assistant)  # 保留 reasoning_content 与 tool_calls

    if not assistant.tool_calls:
        break

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

Original evidence and data

• The thinking mode page states that DeepSeek models output a chain of thought before the final answer to improve the accuracy of the final answer; thinking mode is enabled by default, with a default effort of high.

• The request-tier table on the same page is minimal→low, low→low, medium→high, high→high, xhigh→high, max→max, and ultra→max.

• The parameter description on the same page states that thinking mode does not support temperature, presence_penalty, or frequency_penalty; even if compatible software accepts these fields, they have no effect. top_p takes effect in thinking mode, with a minimum effective value of 0.95; non-thinking mode fixes it at 1.0.

• The same page states that thinking content is returned as reasoning_content at the same level as content. When tools is used, all subsequent requests should return the previous reasoning_content in full; omitting it triggers 400. Ordinary multi-turn requests without tools do not require it to be returned.

• The official homepage's model table lists the current model name as deepseek-flash and explains that requests using the old names deepseek-v4-flash and deepseek-v4-flash-vision-exp are served by DeepSeek-V4.1-Flash and billed at Flash pricing; that page is linked as supplementary evidence: https://api-docs.deepseek.com/.

Applicable boundaries

• medium and xhigh both map to the actual high tier in the current mapping; they do not produce separate intermediate or higher tiers. To request the highest tier, use max (ultra also maps to max).

• Thinking being enabled by default does not mean that every request must pass thinking explicitly; this article passes enabled explicitly to make the configuration behavior clear. In actual integration, follow the field location required by the SDK and protocol in use.

• The hard constraint for tool-based multi-turn interactions is to return the complete reasoning_content; saving only the final content is insufficient. Ordinary multi-turn interactions without tools have no such requirement.

• The presence of reasoning_content only proves that the protocol returned the field. This article does not treat the reasoning text inside it as an external fact, nor does it claim that it should be shown to end users.

• This article records only the model names, control fields, parameter behavior, and multi-turn rules visible in the current official documentation. It does not infer additional system prompts, client defaults, or tool safety policies from sections missing from the page.

Reproduction notes

1. Visit Thinking Mode and confirm the page title, control parameter table, effort mapping table, input and output parameters, and the ordinary multi-turn and tool-calling sections.

2. Visit Your First API Call and confirm the current model table, the mapping of old names to V4.1-Flash, and the Chat Completions curl example.

3. Use the Python OpenAI SDK to send one stream=false request with the configuration in this article. Record whether message.content, message.reasoning_content, and message.tool_calls match the page's description; do not write the API key to logs.

4. If tools are enabled, save the complete assistant message and replay it unchanged in the next request. Test multi-turn messages with and without tools separately, and verify the reasoning_content return requirement for the former.

5. The collection date is 2026-09-16. Model services and documentation may change; review the two official pages above before using this information again.