Kimi K3.1 Pro multi-turn messages and tool history: preserve full reasoning_content

One-sentence takeaway

For multi-turn conversations and tool calls with Kimi K3.1 Pro, the complete assistant message returned by the API must be put back into messages unchanged, including reasoning_content; the client cannot save only the final answer.

Use cases

• Suitable tasks: K3.1 Pro API workflows that require follow-up questions, function calls, or multi-step Agent loops.

• Unsuitable tasks: One-off requests, or directly migrating the legacy K2.x thinking.type and thinking.keep configuration to K3.1 Pro.

• Applicable model version: kimi-k3.1-pro. The history-preservation requirements in this article follow the official documentation for this model.

• Applicable clients, agents, or APIs: Kimi API Chat Completions, and clients or Agents that can preserve and pass through the assistant's original fields.

• Recommended reasoning level and parameters: This article does not discuss reasoning levels; K3.1 Pro does not use the thinking parameter. Requests may set the top-level reasoning_effort separately for the task; see the configuration article numbered 02 for details.

Ready-to-use content

First request with K3.1 Pro

{
  "model": "kimi-k3.1-pro",
  "messages": [
    {"role": "user", "content": "Analyze this problem and call tools when necessary."}
  ]
}

Message loop for multi-turn conversations and tool calls

messages = [
    {"role": "user", "content": "Analyze this problem and call tools when necessary."}
]

while True:
    completion = client.chat.completions.create(
        model="kimi-k3.1-pro",
        messages=messages,
        tools=tools,  # The client supplies tool definitions based on its actual capabilities
    )
    assistant = completion.choices[0].message

    # Save the complete assistant message unchanged; do not extract only assistant.content
    messages.append(assistant)

    if not assistant.tool_calls:
        break

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

Here, run_tool represents the client's own tool executor. Append each tool result using the corresponding tool_call_id; the client remains responsible for tool execution permissions, parameter validation, and error handling.

Testing or workflow steps

1. Confirm that the request uses model: "kimi-k3.1-pro" and sends messages through Kimi API Chat Completions.

2. After receiving the assistant response, save the complete message object and the order of its fields; at a minimum, do not discard reasoning_content, content, or tool_calls.

3. If the response contains tool_calls, execute each tool that is registered and permitted by the client.

4. Append each tool result to the same history as a role: "tool" message with the corresponding tool_call_id.

5. Submit this complete history to Kimi K3.1 Pro again until the assistant no longer returns tool calls.

6. When the user asks a follow-up question, append a new role: "user" only after the existing history; do not strip reasoning_content from earlier assistant messages.

Original evidence and data

• The official page defines kimi-k3.1-pro as a flagship thinking model that always reasons and always has Preserved Thinking enabled.

• The page explicitly states that multi-turn conversations and tool calls require sending the complete assistant message returned by the API back to messages unchanged, including reasoning_content.

• The FAQ further explains that preserving reasoning_content maintains continuity across multi-step reasoning and tool calls, and that it counts toward token usage.

• The official page's basic K3.1 Pro request shows only model and messages; it does not provide a complete tool schema for K3.1 Pro or a directly executable tool implementation.

• The page's complete “Daily News Report Generation” tool-loop example uses kimi-k2.6; it cannot be treated as a K3.1 Pro-specific test or parameter example.

• This article did not use an API key to make a request and does not claim that the tool loop was successfully tested on K3.1 Pro.

Scope and limitations

• reasoning_content is a reasoning field in API messages. This article requires saving and returning it, but does not require displaying it to end users.

• K3.1 Pro uses the top-level reasoning_effort to adjust its reasoning level; do not copy the K2.6 thinking.type or thinking.keep configuration.

• The official page's descriptions of max_tokens, streaming output, temperature, and thinking.keep for kimi-k2.7-code and kimi-k2.6 apply to those respective models; they cannot be used to infer the behavior of parameters with the same names for K3.1 Pro.

• “Returning the complete assistant message” does not mean that tool results, user privacy data, or keys may be written to logs; history storage must still follow the client's data-protection rules.

• This article does not specify tool names, parameter schemas, timeouts, retries, or concurrency strategies; those parts must be defined according to the actual tool system.

Reproduction notes

1. Open the official Thinking Models page and confirm the page title, model selection table, and the basic K3.1 Pro call section.

2. Check the original text about multi-turn conversations, tool calls, and the FAQ to confirm that the complete assistant message includes reasoning_content.

3. Have the client record the original assistant object returned by each API call, and check that the next request's messages still retains that object and the corresponding tool-result relationship.

4. Validate K3.1 Pro separately from the K2.6 tool loop shown on the page; do not add parameters or test conclusions that the official documentation does not make explicit.