Kimi K2.6: API Thinking Mode and Vision Tool Configuration

One-sentence takeaway

The K2.6 API enables thinking by default, fixes a set of sampling parameters, and requires reasoning_content to be retained across multiple tool turns; to use the official $web_search, the current documentation recommends disabling thinking first.

Use cases

• Suitable tasks: Text/image/video understanding, code Agents, function tool calling, and conversations with a 256K long context.

• Unsuitable tasks: Directly calling the official $web_search in thinking mode; the documentation explicitly says this combination is temporarily incompatible.

• Applicable model version: kimi-k2.6.

• Applicable client, Agent, or API: Kimi OpenAI-compatible API, Python OpenAI SDK, Kimi Code.

• Recommended reasoning mode and parameters: Use thinking: {"type":"enabled"} by default; the default is max_tokens=32768. Do not manually pass temperature/top-p/n/penalty values that differ from the fixed values.

Ready-to-use content

Minimal request with thinking disabled (official documentation example)

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{
    "model": "kimi-k2.6",
    "messages": [{"role": "user", "content": "hello"}],
    "thinking": {"type": "disabled"}
  }'

Python configuration skeleton

import os
from openai import OpenAI

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

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[
        {"role": "user", "content": "First analyze the constraints, then complete the task and provide verifiable results."}
    ],
    extra_body={"thinking": {"type": "enabled"}},
    max_tokens=32768,
)
print(response.choices[0].message.content)

For tool loops, retain reasoning_content from the assistant message; tool_choice can only be auto or none. For image/video input, follow the official examples using base64; the documentation recommends keeping images under 4K and videos under FHD, and URL-based images are not currently supported.

Test/workflow steps

1. Start with a no-tool thinking request to confirm that the SDK, base URL, model name, and API key work correctly.

2. Add function tools, fix tool_choice="auto", and feed the complete assistant message from every turn (including reasoning_content and tool calls) back into the context.

3. If $web_search is required, switch to thinking: {"type":"disabled"} and record the quality/cost difference for this mode separately.

4. Estimate tokens before image/video tasks; when the request-body limit could be exceeded or repeated references are needed, use file uploads instead of base64.

5. Test context trimming, tool results, and failure recovery near the 256K long-context limit; do not mistake the default 32K output cap for the context window.

Original evidence and data

• The documentation lists a model context of 256K; inputs support text/image/video, along with thinking and non-thinking, conversational, and Agent tasks.

• max_tokens defaults to 32768; thinking is enabled by default; with thinking, temperature is fixed at 1.0, and without thinking it is fixed at 0.6; top-p is fixed at 0.95; n is fixed at 1; presence/frequency penalties are fixed at 0.0, and passing other values causes an error.

• Tool-calling constraints: tool_choice can only be auto/none; multi-step calls must retain reasoning_content; the official $web_search is currently incompatible with K2.6/K2.5 thinking.

• Vision recommendations: images should not exceed 4096×2160, and videos should not exceed 1920×1080; URL-format images are unsupported, and while there is no hard limit on the number of images, the request body must not exceed 100M.

Applicability boundaries

• The “vision model” capability in the documentation depends on the input format and client; third-party providers may not expose image input, so Kimi API capabilities cannot be directly generalized to every aggregator platform.

• Fixed sampling parameters mean that temperature/top-p cannot be used for ordinary randomness adjustment; comparisons must record the thinking switch and provider.

• Sending reasoning_content back to the API is a requirement for continuity of state; it does not mean the full internal reasoning should be shown to users.

• The documentation's code examples cover vision and tool usage, but do not provide complete cost samples for every input type; measure tokens and latency yourself before launch.

Source excerpt or observation (short quote for compliance only)

The official guidance says you “must keep the reasoning_content” during thinking tool calls and that $web_search is “temporarily incompatible”; these are the two configuration boundaries most likely to cause trouble when integrating K2.6.