# How to Configure Different LLM Providers Other Than the Default in Kimi CLI config.toml > Easily configure alternative LLM providers in Kimi CLI by editing config.toml. Learn how to set up and use different AI models beyond the default for your commands. - Repository: [Moonshot AI/kimi-cli](https://github.com/MoonshotAI/kimi-cli) - Tags: how-to-guide - Published: 2026-07-22 --- **You configure alternative LLM providers by defining `[providers.]` tables in your `~/.kimi/config.toml` file, specifying the `type` and `api_key`, then either setting `default_provider` globally or passing the `--provider` flag for individual commands.** The Kimi CLI (`MoonshotAI/kimi-cli`) uses a TOML-based configuration system to manage connections to various LLM backends. To configure different LLM providers other than the default in config.toml, you edit the provider-specific tables that the `Config` Pydantic model parses from [`src/kimi_cli/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/config.py). These definitions are validated by [`src/kimi_cli/web/api/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/web/api/config.py) and instantiated into runtime objects by [`src/kimi_cli/llm.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/llm.py). ## Provider Configuration Schema Each provider is defined as a sub-table under the top-level `providers` key. The CLI uses these entries to build provider instances through the `kosong` chat-provider abstraction layer. Required fields for every provider entry: - **`type`** – The provider implementation name (e.g., `openai`, `anthropic`, `kimi`). - **`api_key`** – The authentication secret for the service. Optional fields include: - **`model`** – Default model name to use when this provider is selected. - **`base_url`** – Custom endpoint URL for self-hosted or proxy deployments. - **`custom_headers`** – Additional HTTP headers required by certain services. - **`oauth`** – OAuth configuration block for managed authentication flows. ## Configuring Cloud Provider Examples ### OpenAI Add the following table to `~/.kimi/config.toml`: ```toml [providers.openai] type = "openai" api_key = "sk-your-openai-key-here" model = "gpt-4o" ``` ### Anthropic ```toml [providers.anthropic] type = "anthropic" api_key = "sk-ant-your-anthropic-key" model = "claude-3-5-sonnet-20240620" ``` ### Moonshot AI (Kimi) ```toml [providers.kimi] type = "kimi" api_key = "YOUR_KIMI_API_KEY" model = "kimi-latest" ``` For OAuth-managed keys (where tokens are refreshed via the KIMI platform), use the `oauth` block instead of a static `api_key`: ```toml [providers.kimi_managed] type = "kimi" oauth = { client_id = "abc123", redirect_uri = "http://localhost:8000/callback", scopes = ["chat"] } ``` ## Self-Hosted and Custom Endpoints To point the CLI at a self-hosted OpenAI-compatible server, specify the `base_url` field: ```toml [providers.local_llm] type = "openai" api_key = "dummy-key-for-local" base_url = "http://localhost:8000/v1" model = "llama3.1-70b" ``` When [`src/kimi_cli/llm.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/llm.py) constructs the `LLMRuntime`, it passes this `base_url` to the underlying provider factory, overriding the default service endpoint. ## Switching Between Providers ### Global Default Set the `default_provider` key at the root of [`config.toml`](https://github.com/MoonshotAI/kimi-cli/blob/main/config.toml) to specify which provider loads automatically: ```toml default_provider = "anthropic" ``` This value is read by the `Config` class in [`src/kimi_cli/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/config.py) and used as the fallback when no other selection is made. ### Per-Command Override As implemented in [`src/kimi_cli/cli/__init__.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/cli/__init__.py), you can override the default for a single execution using the `--provider` flag: ```bash kimi --provider openai chat "Explain quantum mechanics" kimi --provider local_llm chat "Summarize this document" ``` This flag takes precedence over the `default_provider` setting in the TOML file. ## Summary - **Provider definitions** reside in `[providers.]` tables inside `~/.kimi/config.toml`. - **Required fields** are `type` and `api_key`; optional fields include `model`, `base_url`, `custom_headers`, and `oauth`. - **Global defaults** are controlled by the top-level `default_provider` key. - **Runtime switching** is supported via the `--provider` CLI argument managed in [`src/kimi_cli/cli/__init__.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/cli/__init__.py). - **Implementation chain**: [`src/kimi_cli/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/config.py) loads the file, [`src/kimi_cli/web/api/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/web/api/config.py) validates the schema, and [`src/kimi_cli/llm.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/llm.py) instantiates the runtime. ## Frequently Asked Questions ### Where does Kimi CLI look for the config.toml file? By default, the CLI reads `~/.kimi/config.toml`. You can specify an alternative path using the `--config` command-line argument, which the parser handles in [`src/kimi_cli/cli/__init__.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/cli/__init__.py). ### Can I store API keys for multiple providers at once? Yes. Define separate `[providers.]` sections for each service. The CLI only uses the provider matching the active selection (either `default_provider` or the value passed to `--provider`), leaving other configurations dormant but available for instant switching. ### How do I configure a provider that requires custom HTTP headers? Add a `custom_headers` table under your provider entry containing key-value pairs for the required headers. The `ProviderConfig` model in [`src/kimi_cli/web/api/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/web/api/config.py) parses these and injects them into the HTTP client session used by the `kosong` provider abstraction. ### Is it possible to use OAuth instead of a static API key? Yes. Replace the `api_key` field with an `oauth` block containing `client_id`, `redirect_uri`, and `scopes`. The CLI triggers the OAuth flow on first use and caches refreshed tokens in the session store, as handled by the authentication logic in [`src/kimi_cli/web/api/config.py`](https://github.com/MoonshotAI/kimi-cli/blob/main/src/kimi_cli/web/api/config.py).