Skip to main content

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 the base_url and api_key with the configuration for the Kimi large language model. Here is an example of how to do this:
We will do our best to ensure compatibility between the Kimi API and OpenAI. However, in some special cases, there may still be some differences and variations between the Kimi API and OpenAI (but this does not affect overall compatibility). We will detail the differences between the Kimi API and OpenAI and propose feasible migration solutions to help developers complete the migration process smoothly. Here is a list of interfaces that are compatible with OpenAI:
  • /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 both temperature=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
Any other value will result in an error. We recommend not explicitly setting the temperature when calling these models, or following the above requirements.

Usage Value in Stream Mode

When using OpenAIโ€™s chat.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 the functions 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.

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:
kimi-k2.7-code and kimi-k2.6 do not support "required"; use "auto" or "none" when migrating to those models.