Docs

Kimi Code

Kimi Code keeps its providers in a TOML file, and a third-party endpoint is three keys in it: type, base_url, api_key. Point one at Kunavo and the CLI talks to Claude and GPT ids over the protocol it already speaks.

Kimi Code keeps providers in ~/.kimi-code/config.toml — set providers.<name>.base_url to https://api.kunavo.com/v1 with type = "openai" and the CLI runs Claude and GPT ids on one key.

~/.kimi-code/config.toml

default_model = "kunavo/claude-sonnet-5"

[providers.kunavo]
type = "openai"
base_url = "https://api.kunavo.com/v1"
api_key = "sk-kn-..."

[models."kunavo/claude-sonnet-5"]
provider = "kunavo"
model = "claude-sonnet-5"
max_context_size = 200000

base_url keeps the /v1 suffix. The providers page settles it without inference: the documented default for type = "openai" is https://api.openai.com/v1, and the env-var page's worked example for a third-party endpoint is KIMI_MODEL_BASE_URL="https://api.example.com/v1". Kimi Code appends only the route, so a bare origin here produces a 404 rather than an authentication error. This is the opposite of the Anthropic-protocol clients, which want https://api.kunavo.com with no suffix.

Exporting a shell variable does not give the provider a key. Kimi Code's own config-files page is blunt about it: running export KIMI_API_KEY in the terminal does not give any provider its key. The documented priority is api_key or api_key_env — set exactly one, they are mutually exclusive — then a [providers.kunavo.env] sub-table key if neither is present, and if all are absent startup fails with an error. To keep the key out of the file, write api_key_env = "KUNAVO_API_KEY" instead of api_key; an unset or empty variable then fails the request with an error naming the variable.

Kunavo has not run this client against its own endpoint. The block above is read off Kimi Code's current documentation, not off a session: no streaming or tool-call run of Kimi Code has been recorded here, so treat the first real request as the test, not as a confirmation. The published page is the setup, not the acceptance.

type names the protocol, not the vendor. The documented set is kimi, anthropic, openai, openai_responses, google-genai and vertexai — there is no legacy OpenAI variant in the current table, so a write-up telling you to set one predates it. Choosing openai and then writing a Claude model id is the intended combination: the id is resolved at the base URL, not in the CLI.

Step by step

Create a key at /app/keys and copy it — it is shown once.
Open ~/.kimi-code/config.toml, created on first run. If you have moved the data directory with KIMI_CODE_HOME, the file is at $KIMI_CODE_HOME/config.toml; the file name is always config.toml.
Add the [providers.kunavo] table above. The three keys the docs show for this type, in this order, are type, base_url and api_key.
Declare a model alias under [models."..."] with provider, model and max_context_size — all three are required. The alias is the name you pass to -m and to default_model; the model value is the id sent on the wire. Quote any alias containing a dot.
Leave capabilities out on the first pass. The providers page says capabilities are matched automatically by model-name prefix, and the models table says the array is only ever added to, never subtracted from — so a wrong tag cannot be un-set later by editing the config.
Run kimi, or kimi -m kunavo/claude-sonnet-5 to pick the alias for one session. To try the endpoint without touching the config at all, set KIMI_MODEL_NAME, KIMI_MODEL_API_KEY, KIMI_MODEL_PROVIDER_TYPE=openai and KIMI_MODEL_BASE_URL — the CLI synthesizes a provider in memory and writes nothing back.

Checked against Kimi Code's providers and models page on September 21, 2026. Third-party settings move; if a field name here no longer matches what you see, that page is the authority, not this one.

This is the short version. The full walkthrough — model choice, what a real session costs, and the failure modes — is in Kimi Code vs Claude Code — which client, which model, which account.

Verify before you debug the client

One request settles whether a failure is the endpoint, the key, or the configuration file. If this returns JSON, the same base URL and key work in Kimi Code.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Which model id to put in the field

Every text model is reachable as a model id — the live list is GET /v1/models, and the catalog with prices is on the models page. Rates are USD per 1M tokens, input / output.

Model id	Kunavo in / out	Where it fits in Kimi Code
`claude-sonnet-5`	$2.00 / $10.00	the default alias — the working model for edit-and-run loops
`claude-opus-5`	$2.00 / $10.00	a second alias for planning passes, where a wrong plan is expensive
`claude-haiku-4-5`	$0.40 / $2.00	the cheap alias to bind under [secondary_model] for subagents
`gpt-5-6-sol`	$2.00 / $12.00	a second opinion from a different family, same key and same provider table

Billing is per token from a prepaid balance with no monthly fee — see billing. On repeated context — which is most of what an editor or a chat client sends — prompt caching moves the bill more than the model choice does.

FAQ

How do I point Kimi Code at a custom API endpoint?

Add a provider table to ~/.kimi-code/config.toml with type = "openai", base_url set to your endpoint and api_key set to your key, then declare a model alias under [models."<alias>"] with provider, model and max_context_size. Kimi Code's providers page documents type = "openai" as being for the OpenAI Chat Completions protocol and any third-party service compatible with it, overriding base_url as needed. You can also open the provider manager with /provider in the TUI, but its known-provider path imports from the models.dev catalog, so an endpoint that is not in that catalog is faster to add by hand.

Does the Kimi Code base_url need /v1 at the end?

Yes for an OpenAI-compatible endpoint. Kimi Code appends only the route, so base_url has to be the /v1 root — for example https://api.kunavo.com/v1. The documentation settles this rather than leaving it to inference: the default base_url for type = "openai" is https://api.openai.com/v1, and the environment-variable page's third-party example is https://api.example.com/v1. A missing /v1 shows up as a 404, not a 401.

Why does Kimi Code say my API key is missing when the variable is exported?

Because it does not read shell environment variables for credentials unless you tell it which one to read. The config-files page states that running export KIMI_API_KEY does not give any provider its key. Either write api_key directly in config.toml, or set api_key_env to the name of the variable — those two are mutually exclusive, so set exactly one. A [providers.<name>.env] sub-table is consulted only when neither is present, and if all three are absent startup fails with an error.

Can Kimi Code run Claude models through a third-party provider?

The provider type names a protocol, not a vendor, and the model value is passed through to whatever base_url you configured — so a Claude id set on an openai-type provider resolves at that endpoint rather than in the CLI. Kimi Code also has a separate type = "anthropic" provider for the Anthropic Messages protocol, whose base URL is the bare origin with no /v1 suffix. Kunavo has not run a Kimi Code session against its own endpoint on either protocol, so verify with the curl above and treat your first session as the test.