Call the Kimi K3 and Kimi K2.7 Code models through the OpenAI-compatible API or DashScope SDK on QwenCloud.
Quick start
Supported regions: kimi-k3.1-pro, kimi-k3, and kimi-k2.7-code are available in Singapore, China North 2 (Beijing), Germany (Frankfurt), China (Hong Kong), Japan (Tokyo), and US (Virginia). kimi-k2.5 is available in China North 2 (Beijing), Germany (Frankfurt), Japan (Tokyo), and US (Virginia). kimi-k2.6 is available only in China North 2 (Beijing). Use an API key and endpoint from the region you call; see Regions and endpoints.
kimi-k3 is Kimi's flagship model. It reasons and uses preserved thinking by default. Supports text and image input (video input is not supported), conversation and agent tasks, and dynamic tool loading.
kimi-k2.7-code is the most capable Kimi model for coding. It follows long-context instructions more reliably and achieves higher success rates on programming tasks. Supports text, image, and video input, thinking mode, conversation, and agent tasks.
kimi-k3.1-pro supports the OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and native DashScope APIs.
kimi-k2.7-code is a thinking-only model: thinking mode is always enabled (enable_thinking defaults to true and cannot be disabled), and preserve_thinking defaults to true. kimi-k3.1-pro and kimi-k3 enable thinking by default (enable_thinking=true). You can set it to false to disable thinking, but keeping it enabled is recommended. For kimi-k3.1-pro, disabling thinking significantly degrades output quality, so keeping it enabled is strongly recommended. Both models retain historical reasoning_content supplied by the client by default.
kimi-k3.1-pro and kimi-k3 do not support the thinking_budget parameter. You cannot use this parameter to limit the thinking length.kimi-k2.7-code. To call kimi-k3, replace the model name with kimi-k3.
Before you begin, get an API key and set it as an environment variable. If you call the model through an SDK, install the OpenAI or DashScope SDK.
- OpenAI compatible
- DashScope
- Anthropic compatible
The regional
base_url values used below also apply to OpenAI Responses calls; append /responses to the base_url for HTTP requests, as in POST {base_url}/responses.The
enable_thinking parameter is not part of the standard OpenAI API. In the OpenAI Python SDK, pass it through extra_body. In the Node.js SDK, pass it as a top-level parameter.- Python
- Node.js
- curl
Multimodal calls
The kimi-k3.1-pro, kimi-k3, kimi-k2.7-code, kimi-k2.6, and kimi-k2.5 models support multimodal input and text output. kimi-k3.1-pro and kimi-k3 support only text and image input, not video input; kimi-k2.7-code, kimi-k2.6, and kimi-k2.5 can simultaneously process text, images, or video. Use the enable_thinking parameter to enable thinking mode. The following examples show how to use this capability. The examples use kimi-k2.6, which is available only in China North 2 (Beijing), so they call the cn-beijing endpoint; to call another model in another region, replace the region in the URL.
Enable or disable thinking mode
kimi-k2.6 and kimi-k2.5 are hybrid thinking models. These models can reply after thinking or reply directly. You can use the enable_thinking parameter to control whether to enable the thinking mode:
true: Enable thinking modefalse(default): Disables the thinking mode
kimi-k2.7-code is a thinking-only model: thinking mode is always enabled (enable_thinking defaults to true and cannot be disabled), and preserve_thinking defaults to true.
kimi-k3.1-pro and kimi-k3 enable thinking by default (enable_thinking=true). You can set it to false to disable thinking, but keeping it enabled is recommended. For kimi-k3.1-pro, disabling thinking significantly degrades output quality, so keeping it enabled is strongly recommended. Both models retain historical reasoning_content supplied by the client by default. We recommend returning the complete reasoning_content of historical assistant messages in multi-turn requests.
kimi-k2.6 supports passing the thinking process in multi-turn conversations by using the preserve_thinking parameter. For more information, see Pass the thinking process.
The following examples show how to use an image URL and enable thinking mode. The main example demonstrates single-image input, while the commented-out code is an example of multi-image input.
- OpenAI compatible
- DashScope
Video understanding
kimi-k3.1-pro and kimi-k3 do not support video input (they support text and image input only), so the video understanding examples in this section do not apply to either model.
- Video file
- Image list
The kimi-k2.7-code, kimi-k2.6, and kimi-k2.5 models analyze videos by extracting a sequence of frames. You can control the frame extraction strategy with the following parameters:
-
fps: Controls the frame extraction frequency. The interval between extracted frames is 1/fps seconds. The value must be in the range of [0.1, 10]. The default value is 2.0.
- For high-motion scenes: Set a higher fps value to capture more detail.
- For static or long videos: Set a lower fps value to improve processing efficiency.
- max_frames: Specifies the maximum number of frames to extract from a video. The default and maximum value is 2000. If the number of frames calculated from the fps value exceeds this limit, the system automatically extracts frames uniformly to stay within the max_frames limit. This parameter is available only when you use the DashScope SDK.
- OpenAI compatible
- DashScope
When passing a video file to the model using the OpenAI SDK or an HTTP request, set the
"type" parameter in the user message to "video_url".Pass a local file
The following examples show how to pass a local file. The OpenAI-compatible API supports only Base64 encoding, while DashScope supports both Base64 encoding and file paths.
- OpenAI compatible
- DashScope
To pass a local file using Base64 encoding, construct a Data URL. For instructions, see Construct a Data URL.
File limitations
- Image limitations
- Video limitations
-
Image resolution:
- Minimum size: Width and height must each exceed
10pixels. - Aspect ratio: The ratio of the longest side to the shortest side must not exceed
200:1. - Maximum resolution: The recommended maximum is
8K(7680x4320). Higher resolutions may cause API call timeouts due to large file sizes or slow network transfers.
- Minimum size: Width and height must each exceed
-
Supported image formats
-
The following formats are supported for resolutions below 4K
(3840x2160):Image format File extension MIME type BMP .bmp image/bmp JPEG .jpe, .jpeg, .jpg image/jpeg PNG .png image/png TIFF .tif, .tiff image/tiff WEBP .webp image/webp HEIC .heic image/heic -
For resolutions between
4K(3840x2160)and8K(7680x4320), only JPEG, JPG, and PNG are supported.
-
The following formats are supported for resolutions below 4K
-
Image size:
- When providing an image via a public URL or local path, its size must not exceed
10 MB. - When using Base64 encoding, the encoded string must not exceed
10 MB.
To compress a file, see How to compress an image or video to meet the size limit. - When providing an image via a public URL or local path, its size must not exceed
- Number of supported images: When providing multiple images, the total number of tokens for all images and text must not exceed the model's maximum input limit.
Dynamically loaded tools
When an application needs to mount a large number of tools, putting every tool declaration into the request's top-level tools field at once leads to tool definition bloat: every request must carry the description and parameter schema of all tools, driving up token consumption, and the more candidate tools there are, the more likely the model is to pick the wrong tool and construct incorrect call arguments.
Dynamically loaded tools let you inject tools on demand during a conversation: mount only a few core tools first, and when the conversation reaches a point where a specific tool is needed, dynamically insert it into messages, reducing token consumption and improving tool-selection accuracy.
kimi-k3.1-pro and kimi-k3 support dynamically loaded tools; requesting them on other models (such as kimi-k2.6) returns a tokenization failed error.The format and examples in this section for injecting tools into messages through the tools field of a system message (system.tools) apply to the OpenAI Chat Completions API.Inject tool declarations in messages
Insert a message with role set to system into messages, and declare the tools to load through that message's tools field. The format is identical to the request's top-level tools field, and you must provide the complete tool information (name, description, parameters).
- A
systemmessage carryingtoolshas the same status as an ordinary message: the tools become visible to the model starting from the position where that message appears in themessageslist. - Dynamically loaded tools coexist with the global tools declared in the request's top-level
toolsfield; the model can see both kinds of tools at the same time. - A dynamically injected tool declaration must be a complete tool definition; you cannot pass only a tool name or reference a globally declared tool.
- A
systemmessage carryingtoolsmust not also carry acontentfield, or the request fails with a 400 error. When using the OpenAI SDK, you can pass thetoolsfield through directly inmessages.
- Python
- curl
On-demand loading combined with a search tool
There is no dedicated tool-search API. When there are many tools, you can combine a custom search tool with dynamically loaded tools to load tools on demand:
- At the start of the session, declare in the top-level
toolsonly asearch_toolstool implemented by your application backend (it returns matching tool names and summaries by keyword), plus a few core tools that may be used every turn. - Declare the searchable keywords (such as a tool catalog or domain tags) in the system prompt to guide the model to call
search_toolsfirst when it needs a tool. Settingtool_choice: "required"on the first request guarantees at least one tool call, but does not guarantee thatsearch_toolsis called first. If searching first is mandatory, explicitly settool_choice: {"type": "function", "function": {"name": "search_tools"}}, then restoretool_choiceto"auto"after the search. Changingtool_choicedoes not break the prefix cache. - Based on the results returned by
search_tools, the application dynamically inserts the complete declarations of the corresponding tools intomessagesthrough asystemmessage carryingtools. - The model can then call these newly loaded tools directly in subsequent generation.
Notes
- Dynamic tool declarations take effect per request and are not remembered by the server. Whether to keep carrying them in the next request is up to the integrator: keep carrying them and the tools remain available (which also helps hit the prefix cache); stop carrying them and the declaration expires — if the tool is not declared elsewhere, the model cannot call it, and the prefix cache after the change point may miss.
- Appending a dynamic tool declaration at the end of
messagesdoes not affect the cache of the existing prefix; deleting or modifying earlier tool declarations may affect cache hits after the change point. Declaring global tools in the request's top-leveltoolsfield also does not affect cache hits. - A
systemmessage carryingtoolsalso consumes context length, so inject only the tools truly needed by the current conversation. - Dynamic tool declarations use exactly the same format as global
toolsdeclarations, so integrators do not need to maintain two schemas.
Supported features
| Feature | kimi-k3.1-pro | kimi-k3 | kimi-k2.7-code | kimi-k2.6 | kimi-k2.5 |
|---|---|---|---|---|---|
| Multi-turn conversation | ✓ | ✓ | ✓ | ✓ | ✓ |
| Deep thinking | ✓ (on by default) | ✓ (on by default) | ✓ (always on) | ✓ | ✓ |
| Function calling | ✓ | ✓ | ✓ | ✓ | ✓ |
| Structured output | ✓ (JSON Mode) | ✓ | — | — | — |
| Web search | ✓ | ✓ (Responses API) | — | — | — |
| Prefix completion | — | ✓ | — | — | — |
| Context cache | ✓ (implicit cache) | ✓ | ✓ | ✓ | ✓ |
Parameter defaults
| Parameter | kimi-k3.1-pro | kimi-k3 | kimi-k2.7-code | kimi-k2.6 | kimi-k2.5 |
|---|---|---|---|---|---|
| enable_thinking | true (can be disabled; keeping it enabled is strongly recommended) | true (can be disabled; keeping it enabled is recommended) | true (thinking mode only) | false | false |
| temperature | 1.0 | 1.0 | 1.0 | Thinking mode: 1.0; non-thinking mode: 0.6 | Thinking mode: 1.0; non-thinking mode: 0.6 |
| top_p | 0.95 | 0.95 | 0.95 | 0.95 | 0.95 |
| presence_penalty | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| fps | - | - | 2 | 2 | 2 |
| max_frames | - | - | 2000 | 2000 | 2000 |
max as the default:
max(default): deep reasoninghigh: enhanced reasoningmedium: moderate reasoninglow: light reasoning
- OpenAI Chat Completions: Use the top-level
reasoning_effortfield. With the OpenAI Python SDK, passreasoning_effort="max"directly. - DashScope: Use the
reasoning_effortSDK parameter orparameters.reasoning_effortin HTTP requests. - OpenAI Responses: Use
reasoning.effort. - Anthropic Messages: Use
output_config.effort.
temperature=1.0, top_p=0.95, and presence_penalty=0.0. Passing a non-default value for any of these parameters returns an error.
Models and billing
The Kimi series are large language models from Moonshot AI.
- kimi-k3.1-pro: Supports text and image input, text output, and dynamic tool loading. Video input, Batch, and fine-tuning are not supported.
- kimi-k3: Kimi's flagship model. It reasons and uses preserved thinking by default. Supports text and image input (video input is not supported), conversation and agent tasks, and dynamic tool loading.
- kimi-k2.7-code: A Kimi model for coding. It follows long-context instructions more reliably and achieves higher success rates on programming tasks. Supports text, image, and video input, thinking mode, conversation, and agent tasks.
- kimi-k2.6: Offers improved performance in long-horizon coding, instruction following, and self-correction. Supports text, image, and video input, thinking and non-thinking modes, conversation, and agent tasks. Available only in China North 2 (Beijing).
- kimi-k2.5: Achieves state-of-the-art (SOTA) performance on open-source benchmarks for agent tasks, code generation, visual understanding, and other general intelligence tasks. Supports image, video, and text input, thinking and non-thinking modes, conversation, and agent tasks. Available in China North 2 (Beijing), Germany (Frankfurt), Japan (Tokyo), and US (Virginia).
In thinking mode, the chain of thought counts as output tokens.