About API Compatibility
The Kimi API is compatible with OpenAIโs interface specifications. You can use the Python or NodeJS SDKs provided by OpenAI to call and use the Kimi large language model. This means that if your application or service is developed based on OpenAIโs models, you can seamlessly migrate to using the Kimi large language model by simply replacing thebase_url and api_key with the configuration for the Kimi large language model. Here is an example of how to do this:
- python
- node.js
/v1/chat/completions/v1/files/v1/files/{file_id}/v1/files/{file_id}/content
Temperature and N Value
When using OpenAIโs interface, you can set bothtemperature=0 and n>1, which means that in cases where the temperature value is 0, multiple different answers (i.e., choices) can be returned simultaneously.
However, in the Kimi API, when you set the temperature value to 0 or close to 0 (e.g., 0.001), we can only provide one answer (i.e., len(choices)=1). If you set temperature to 0 while using an n value greater than 1, we will return an โinvalid requestโ error, specifically invalid_request_error.
Additionally, please note that the range of values for the temperature parameter in the Kimi API is [0, 1], while the range for the temperature parameter in OpenAI is [0, 2].
Migration Recommendation:
For kimi-k2.6 and kimi-k2.5 models, the temperature parameter has special requirements:
- Thinking mode uses a fixed
temperature=1.0 - Non-thinking mode uses
temperature=0.6
Usage Value in Stream Mode
When using OpenAIโschat.completions interface, in cases of streaming output (i.e., stream=True), the output result does not include usage information by default (including prompt_tokens/completion_tokens/total_tokens). OpenAI provides an additional parameter stream_options={"include_usage": True} to include usage information in the last data block of the response.
In the Kimi API, in addition to the stream_options={"include_usage": True} parameter, we also place usage information (including prompt_tokens/completion_tokens/total_tokens) in the end data block of each choice.
Migration Recommendation: In most cases, developers do not need to take any additional compatibility measures. If your business scenario requires tracking the usage information for each choice individually, you can access the choice.usage field. Note that among different choices, only the values of usage.completion_tokens and usage.total_tokens are different, while the values of usage.prompt_tokens are the same for all choices.
Deprecated function_call
In 2023, OpenAI introduced thefunctions parameter to enable function call functionality. After functional iteration, OpenAI later launched the tool call feature and marked the functions parameter as deprecated, which means that the functions parameter may be removed at any time in future API iterations.
The Kimi API fully supports the tool call feature. However, since functions has been deprecated, the Kimi API does not support using the functions parameter to execute function calls.
Migration Recommendation: If your application or service relies on tool calls, no additional compatibility measures are needed. If your application or service depends on the deprecated function call, we recommend migrating to tool calls. Tool calls expand the capabilities of function calls and support parallel function calls. For specific examples of tool calls, please refer to our tool call guide:
Using Kimi API for Tool Calls (tool_calls)
Here is an example of migrating from functions to tools:
We will present the code that needs to be modified in the form of comments, along with explanations, to help developers better understand how to perform the migration.
The examples on this page use the latest model
kimi-k3 by default. K3 configures reasoning effort with the top-level reasoning_effort request field (supports "low" / "high" / "max", default "max"). To use another model such as kimi-k2.6 or kimi-k2.5, just replace the model field โ parameter configurations differ across models. See the Model Parameter Reference.- python
- node.js
About tool_choice
kimi-k3 supports "none", "auto", "required", and null for tool_choice. If an application relies on OpenAIโs tool_choice: "required" to ensure the model calls at least one tool, you can keep that setting when migrating to kimi-k3:
- python
- node.js
kimi-k2.7-code and kimi-k2.6 do not support "required"; use "auto" or "none" when migrating to those models.