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 covers the following thinking models:
  • kimi-k3: 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-k2.7-code: code-focused; thinking is always on, and Preserved Thinking is always on. Its high-speed variant kimi-k2.7-code-highspeed is the same model with identical thinking behavior, and everything on this page applies to it as well.
  • kimi-k2.6: the general-purpose thinking model; thinking is on by default, can be disabled, and supports Preserved Thinking.
  • kimi-k2.5: a general-purpose thinking model; thinking is on by default and can be disabled, but does not support Preserved Thinking.
The request parameters differ across these models: If you are doing benchmark testing with kimi api, please refer to this benchmark best practice.

Basic calls

Call kimi-k3

kimi-k3 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 usage, see the Kimi K3 Quickstart.

Call kimi-k2.7-code: no thinking parameter needed

kimi-k2.7-code is a code-focused thinking model, sharing the same thinking mechanism as kimi-k2.6 (reasoning_content, multi-step tool calls, streaming, etc.); the only difference is in the thinking parameter (see the comparison table above). You do not need to (and should not) pass the thinking parameter โ€” just switch the model, and the model always emits reasoning_content. Because Preserved Thinking is always on, in multi-turn conversations you must keep the reasoning_content of every historical assistant message in messages as-is. The example below makes a minimal streaming call and separates the reasoning content from the final answer in the output:

Call kimi-k2.6: reasoning output by default

kimi-k2.6 is the general-purpose thinking model. Thinking is enabled by default, so the basic call below outputs reasoning content without passing the thinking parameter (to disable thinking or enable Preserved Thinking, see the thinking parameter below):

Control thinking behavior

K3: adjust reasoning effort with reasoning_effort

kimi-k3 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.

Control kimi-k2.6 thinking with the thinking parameter

kimi-k2.6 controls thinking behavior via the thinking parameter, which has two sub-fields:
  • thinking.type: "enabled" (default) | "disabled" โ€” controls whether thinking is on. Since it defaults to "enabled", the example above thinks without passing it explicitly; for a disable example see Disable Thinking Capability Example.
  • thinking.keep: null (default, ignores historical turnsโ€™ thinking) | "all" (keeps previous turnsโ€™ reasoning_content, enabling Preserved Thinking โ€” see Preserved Thinking for usage).

Read reasoning_content from the response

For thinking models such as kimi-k2.7-code and kimi-k2.6 (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

kimi-k2.7-code and kimi-k2.6 (with thinking enabled) are designed to perform deep reasoning across multiple tool calls, enabling them to tackle highly complex tasks. To get reliable results, always follow these configuration rules when using thinking models:
  • Within a single task (the multi-step reasoning produced during one tool-call loop), keep all of the reasoning content from the context (the reasoning_content field) and send it back with the request; the model will choose which parts are necessary and forward them for reasoning. Whether historical thinking is preserved across turns is controlled by thinking.keep (kimi-k2.6 defaults to null and does not keep it, while kimi-k2.7-code always keeps it).
  • Set max_tokens >= 16000 to ensure the full reasoning_content and content can be returned without truncation.
  • Do not set temperature. For kimi-k2.7-code and kimi-k2.6, temperature is not modifiable โ€” use the default and 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 such as kimi-k2.7-code and kimi-k2.6 (with thinking enabled) use deep reasoning to plan and execute complex multi-step tasks, with detailed reasoning steps (reasoning_content) 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 chain of thought when reasoning in the current turn. For kimi-k2.6, use the thinking.keep parameter in the request body to control whether historical thinking is preserved:
thinking.keep only affects reasoning_content from historical turns; it does not change whether the model generates/outputs thinking content within the current turn (that is controlled by thinking.type). Recommended to use keep: "all" together with type: "enabled".For kimi-k2.7-code, Preserved Thinking is always on and cannot be turned off: thinking.keep is treated as "all" whether you omit it or pass the only valid value "all" (passing any other invalid value returns an error). When using this model you must therefore (not optionally) keep the reasoning_content of historical assistant messages in messages as-is, exactly as shown in the example below.
When using keep: "all", keep the reasoning_content from every historical assistant message in messages as-is. The simplest way is to append the assistant message returned from the previous API call directly back into messages, as shown below:
reasoning_content counts toward token consumption. When Preserved Thinking is enabled, historical thinking content keeps occupying the context window and is billed accordingly. Use it wisely.

Frequently Asked Questions

Q1: Why should I keep reasoning_content?

A: Keeping reasoning_content ensures continuity in multi-step reasoning, especially during tool calls. Pass the complete assistant message returned by the API back in messages as-is. For K3, this is required in multi-turn conversations and tool-call loops. For K2.x, cross-turn preservation follows each modelโ€™s thinking.keep behavior: kimi-k2.6 does not preserve it by default, while kimi-k2.7-code always does.

Q2: Does reasoning_content consume extra tokens?

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