Kimi K3.1 Pro reasoning levels and parameter configuration: reasoning_effort low, high, and max

One-sentence takeaway

Kimi K3.1 Pro always reasons. Set its reasoning level through the top-level reasoning_effort field in a Chat Completions request; the available values are low, high, and max, with max as the default.

Use cases

• Suitable tasks: Choosing a reasoning level for Kimi K3.1 Pro API requests, or migrating from the K2.x thinking configuration to the K3 request format.

• Unsuitable tasks: Comparing the accuracy, latency, or cost of different levels; the official page only says that the levels balance reasoning depth, latency, and token usage, and provides no local test data.

• Applicable model version: The official page explicitly covers kimi-k3.1-pro; it describes this field as K3's top-level reasoning field but does not list a compatibility matrix for other model versions.

• Applicable clients, agents, or APIs: The Kimi API Chat Completions interface and compatible clients that can pass through the top-level reasoning_effort field.

• Recommended reasoning level and parameters: There is no universal level recommendation. According to the official configuration, low, high, and max are all available; when the field is omitted, the default value is max.

Ready-to-use content

Original configuration (official example)

Place reasoning_effort at the top level of the Chat Completions request:

{
  "model": "kimi-k3.1-pro",
  "messages": [{"role": "user", "content": "Derive the general formula for this sequence: 1, 4, 9, 25, 64, ..."}],
  "reasoning_effort": "high"
}

Official Python example:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

completion = client.chat.completions.create(
    model="kimi-k3.1-pro",
    messages=[
        {"role": "user", "content": "Derive the general formula for this sequence: 1, 4, 9, 25, 64, ..."},
    ],
    reasoning_effort="high",
)

message = completion.choices[0].message
if hasattr(message, "reasoning_content"):
    print(getattr(message, "reasoning_content"))
print(message.content)

Parameter reference:

Inferred, not tested

• low, high, and max can be understood as low-to-high reasoning investment options. This usage guidance is organized from the official description that the levels “balance reasoning depth, latency, and token usage”; it is not an empirically tested ranking in this article.

• If a client cannot pass through the top-level reasoning_effort field, do not infer that it will automatically map to the legacy thinking parameter. Check the client's request body or raw API logs first.

Testing or workflow steps

1. Confirm that the request uses the model ID kimi-k3.1-pro and the Kimi API Chat Completions interface.

2. Add reasoning_effort at the top level of the request, using only low, high, or max as its value.

3. If the field is not set, use the default value max as specified by the official documentation; do not embed it in messages or rewrite it as the K2.x thinking configuration.

4. When migrating from K2.x, remove the legacy thinking configuration and add the top-level reasoning_effort field as shown above.

5. When using multi-turn conversations or tool calls, pass the complete assistant message returned by the API back into messages unchanged, including reasoning_content and tool_calls.

6. Record the requested reasoning level, response latency, and token usage separately, then choose a level based on your own task; this article provides no measured results for these metrics.

Original evidence and data

• The official page states that Kimi K3.1 Pro always reasons and configures reasoning through the top-level reasoning_effort field in the request.

• The official page lists low, high, and max as the valid values and explicitly identifies max as the default.

• The official JSON, curl, and Python examples all place reasoning_effort at the top level of the Chat Completions request; this article retains only the complete JSON and Python examples from the page.

• The official migration guidance requires removing the K2.x thinking configuration when migrating from K2.x to K3, then using the top-level reasoning_effort field as needed.

• The official field description requires passing the complete assistant message returned by the API back unchanged during multi-turn conversations and tool calls, including reasoning_content and tool_calls.

• This article only verifies the configuration on the official page. It did not use an API key to make a request and did not measure reasoning depth, latency, token usage, success rate, or client compatibility for the different levels.

Scope and limitations

• The three reasoning_effort values and the default value are described for Kimi K3.1 Pro on this official page. They cannot be generalized as universal parameters for all Kimi models or third-party clients.

• “Always reasons” does not mean that every request requires manually filling in reasoning_effort; when the field is omitted, the official documentation still specifies max as the default.

• The K2.x thinking configuration and K3's top-level reasoning_effort are not verified as the same parameter in this article. When migrating, rewrite the request according to the K3 documentation and check whether the client still injects the legacy field.

• The official page provides no specific token limits, prices, latency figures, or quality scores for low, high, and max; this article does not add inferred values for these metrics.

Reproduction notes

1. Open the original page and confirm that its title is Reasoning Effort. Record the collection date, model ID, field location, available values, and default value.

2. Compare the JSON, curl, and Python code blocks on the page to confirm that reasoning_effort is at the top level of the Chat Completions request.

3. Check the migration guidance and field description to confirm the K2.x thinking configuration migration rule and the assistant message fields that must be preserved for multi-turn conversations and tool calls.

4. This reproduction only verifies the configuration on the official page. It did not submit a real API request, so it contains no local test data.