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, andreasoning_contentmay be returned. Configure its reasoning effort with the top-levelreasoning_effortrequest 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 variantkimi-k2.7-code-highspeedis 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.
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:
- curl
- python
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:
- curl
- python
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):
- curl
- python
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 askimi-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,
ChoiceDeltaandChatCompletionMessagetypes do not provide areasoning_contentfield directly, so you cannot access it via.reasoning_content. You must usehasattr(obj, "reasoning_content")to check if the field exists, and if so, usegetattr(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_contentfield at the same level as thecontentfield. - In streaming output (
stream=True), thereasoning_contentfield will always appear before thecontentfield. In your business logic, you can detect if thecontentfield has been output to determine if the reasoning (inference process) is finished. - Tokens in
reasoning_contentare also controlled by themax_tokensparameter: the sum of tokens inreasoning_contentandcontentmust be less than or equal tomax_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_contentfield) 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 bythinking.keep(kimi-k2.6defaults tonulland does not keep it, whilekimi-k2.7-codealways keeps it). - Set
max_tokens >= 16000to ensure the fullreasoning_contentandcontentcan be returned without truncation. - Do not set
temperature. Forkimi-k2.7-codeandkimi-k2.6,temperatureis not modifiable โ use the default and do not pass it explicitly (see Model Parameter Reference). - Enable streaming (
stream=True). Because thinking models return bothreasoning_contentand regularcontent, 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 likedate (to get the date) and web_search (to search todayโs news), and will present deep reasoning throughout this process:
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 thereasoning_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.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:
- curl
- python
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.