How to Configure Kimi Code CLI with an OpenAI-Compatible Provider

If you like coding from the terminal, the frustrating part of trying a new AI coding CLI is usually not the CLI itself. It is the provider setup: where the config file lives, which base URL to use, which model name should go where, and how to verify that the key actually works.

This guide walks through configuring Kimi Code CLI to use Ace Data Cloud as an OpenAI-compatible provider. The goal is practical: install the CLI, add one provider block, verify the setup, and know what to check when it fails.

What you can do

Kimi Code is a terminal coding assistant. The Ace Data Cloud setup guide shows how to point it at an OpenAI-compatible endpoint by editing ~/.kimi/config.toml.

The important fields are:

The subtle part is MODEL_ID: the guide says to use the model name used by the API model parameter, not a service UUID or API UUID. It also recommends using the id value from the /v1/models response for precise validation.

How it works

Kimi Code reads its provider configuration from ~/.kimi/config.toml. By setting the provider type to openai, you tell Kimi Code to speak the OpenAI Chat Completions protocol to the configured base_url.

In this setup, Kimi Code sends model requests to:

https://api.acedata.cloud/v1 

Ace Data Cloud handles the provider side, while Kimi Code keeps the local developer experience: run commands in a project, ask for changes, and iterate from the terminal.

You will need an API Key first. The documented path is to open the Ace Data Cloud application list, enter an available application, and copy the API Key.

Install Kimi Code

The guide gives three install options. On macOS or Linux, use the shell installer:

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash 

On Windows PowerShell, use:

irm https://code.kimi.com/kimi-code/install.ps1 | iex 

If you prefer npm, install the package globally:

npm install -g @moonshot-ai/kimi-code 

After installing, the rest of the work is configuration rather than code.

Configure the provider

Open ~/.kimi/config.toml and add the Ace Data Cloud provider configuration:

default_model = "acedatacloud/MODEL_ID" [providers.acedatacloud] type = "openai" base_url = "https://api.acedata.cloud/v1" api_key = "your API Key" [models."acedatacloud/MODEL_ID"] provider = "acedatacloud" model = "MODEL_ID" 

Replace every MODEL_ID with the same model name. The source guide gives examples such as claude-opus-5 and gpt-6-sol, but the safest approach is to check the model catalog or validate against the /v1/models response and use the returned id.

A good final config should be internally consistent:

• default_model should point to acedatacloud/<your model id>
• the model table name should match that same acedatacloud/<your model id> string
• the model field inside the table should be the raw model id
• the provider should remain acedatacloud
• type should remain openai

For example, if you choose gpt-6-sol, the structure would follow this shape:

default_model = "acedatacloud/gpt-6-sol" [providers.acedatacloud] type = "openai" base_url = "https://api.acedata.cloud/v1" api_key = "your API Key" [models."acedatacloud/gpt-6-sol"] provider = "acedatacloud" model = "gpt-6-sol" 

Do not mix model identifiers. A surprisingly common mistake is changing default_model but leaving the model table or model field on an older value.

Lock down the config file

Because ~/.kimi/config.toml contains the API Key, protect it on macOS or Linux:

chmod 600 ~/.kimi/config.toml 

This does not replace secret management for teams, but it is a sensible local baseline. Avoid committing this file into a repository, and be careful when sharing terminal recordings or config snippets.

Verify the setup

The guide suggests three verification commands:

kimi doctor kimi provider list kimi -p "Reply only OK" 

I would run them in that order. kimi doctor is the first sanity check. kimi provider list confirms that the provider is visible to Kimi Code. The final command is a minimal model call that should return only OK if the path is working.

If you get a 401, check the API Key. If Kimi Code reports that the model was not found, inspect the three model locations again: default_model, the [models."..."] table name, and the model field. They need to line up with the same API model id.

Start from a project directory

Once verification passes, enter a project and run:

kimi 

That is the point where the setup becomes useful. You can ask the CLI to inspect files, propose changes, or help with debugging without leaving the terminal. The provider configuration stays in Kimi Code, while your project workflow stays local.

Wrap-up

This is a small integration, but it removes a lot of provider friction: one OpenAI-compatible base_url, one type = "openai" provider block, one model mapping, and three verification commands. If you are evaluating terminal coding agents, this is the kind of setup worth keeping reproducible.

For the original reference, see the Ace Data Cloud Kimi Code CLI setup guide: https://platform.acedata.cloud/documents/kimi-code-integration