Skip to main content
Thinking models use reasoning tokens to “think” before producing a final answer — breaking down the problem, planning steps, and evaluating alternatives. The reasoning process is returned in the response’s reasoning_content field. Thinking before answering improves performance on complex reasoning, code generation, and multi-step tool calling, at the cost of higher latency and token usage.

Choose the right thinking model

This page uses the following thinking models:
  • kimi-k3.1-pro: the flagship thinking model; reasoning and Preserved Thinking are always on, and reasoning_content may be returned. Configure its reasoning effort with the top-level reasoning_effort request field, which supports "low" / "high" / "max" (default "max").
  • kimi-k3: supports a 1M-token context window and follows the same thinking behavior as K3.1 Pro.
If you are doing benchmark testing with kimi api, please refer to this benchmark best practice.

Basic calls

Call kimi-k3.1-pro

kimi-k3.1-pro always reasons with Preserved Thinking always on; you do not need to (and should not) pass the thinking parameter — just set model, and optionally adjust reasoning effort with the top-level reasoning_effort field:
For multi-turn conversations and tool calls, pass the complete assistant message returned by the API back to messages as-is (including reasoning_content); see Preserved Thinking. For more K3.1 Pro usage, see the Kimi K3.1 Pro Quickstart.

Control thinking behavior

K3.1 Pro: adjust reasoning effort with reasoning_effort

kimi-k3.1-pro always reasons and does not support the thinking parameter. Adjust reasoning effort with the top-level reasoning_effort field ("low" / "high" / "max", default "max"); see Reasoning Effort for usage and examples.

Read reasoning_content from the response

When using a thinking model with thinking enabled, the API response carries the model’s reasoning in the reasoning_content field. When reading this field:
  • In the OpenAI SDK, ChoiceDelta and ChatCompletionMessage types do not provide a reasoning_content field directly, so you cannot access it via .reasoning_content. You must use hasattr(obj, "reasoning_content") to check if the field exists, and if so, use getattr(obj, "reasoning_content") to retrieve its value.
  • If you use other frameworks or directly interface with the HTTP API, you can directly obtain the reasoning_content field at the same level as the content field.
  • In streaming output (stream=True), the reasoning_content field will always appear before the content field. In your business logic, you can detect if the content field has been output to determine if the reasoning (inference process) is finished.
  • Tokens in reasoning_content are also controlled by the max_tokens parameter: the sum of tokens in reasoning_content and content must be less than or equal to max_tokens.

Configure multi-step tool calls

Thinking models can perform deep reasoning across multiple tool calls to tackle complex tasks. To get reliable results, always follow these configuration rules when using thinking models:
  • In both single-task tool-call loops and multi-turn conversations, pass the complete assistant message back as-is, including reasoning_content. kimi-k3.1-pro and kimi-k3 always enable Preserved Thinking.
  • Set max_tokens >= 16000 to ensure the full reasoning_content and content can be returned without truncation.
  • Do not set temperature. kimi-k3.1-pro and kimi-k3 fix temperature at 1.0; do not pass it explicitly (see Model Parameter Reference).
  • Enable streaming (stream=True). Because thinking models return both reasoning_content and regular content, the response is larger than usual. Streaming delivers a better user experience and helps avoid network-timeout issues.

Complete example: generate a daily news report

The example below demonstrates a “Daily News Report Generation” scenario. The model will sequentially call official tools like date (to get the date) and web_search (to search today’s news), and will present deep reasoning throughout this process:
This process demonstrates how thinking models use deep reasoning to plan and execute complex multi-step tasks when thinking is enabled. Detailed reasoning steps (reasoning_content) are preserved in the context to ensure accurate tool use at every stage.

Preserve thinking across turns (Preserved Thinking)

Preserved Thinking means passing the reasoning_content of previous turns through to the model in a multi-turn conversation so that the model can continue its prior reasoning context. kimi-k3.1-pro and kimi-k3 always enable Preserved Thinking. In multi-turn conversations and tool calls, append the complete assistant message returned by the API to messages as-is, including reasoning_content; do not keep only the final answer text.
reasoning_content consumes tokens. Historical reasoning content continues to occupy context space and is billed, so keep the context size under control.

Frequently Asked Questions

Q1: Why should I keep reasoning_content?

A: Keeping reasoning_content ensures continuity in multi-step reasoning, especially during tool calls. For K3.1 Pro and K3, multi-turn conversations and tool calls must pass the complete assistant message returned by the API back in messages as-is.

Q2: Does reasoning_content consume extra tokens?

A: Yes, reasoning_content counts towards your input/output token quota. For detailed pricing, see Pricing.