# How to Configure Multiple LLM Providers Beyond Kimi in Kimi Code

> Configure multiple LLM providers beyond Kimi in Kimi Code. Seamlessly switch between Kimi, OpenAI, Anthropic, and custom models using the providers map in your global configuration. Learn more now.

- Repository: [Moonshot AI/kimi-code](https://github.com/MoonshotAI/kimi-code)
- Tags: how-to-guide
- Published: 2026-07-22

---

**Kimi Code supports multiple LLM providers through a declarative `providers` map in the global configuration, where each entry specifies the provider type, model, authentication credentials, and optional custom headers, enabling seamless switching between Kimi, OpenAI, Anthropic, and custom implementations via the Kosong abstraction layer.**

Kimi Code, the open-source AI coding assistant from MoonshotAI, is architected to be provider-agnostic from the ground up. While it defaults to the Kimi API, the configuration system allows you to integrate any number of external LLM services. This guide explains how to configure multiple LLM providers beyond Kimi in Kimi Code using the schema validation and runtime resolution mechanisms built into the codebase.

## Understanding the Provider Configuration Architecture

The provider system centers on a **provider-config** object stored in the global `KimiConfig.providers` record. Each provider is identified by a unique string key—such as `"openai"` or `"anthropic"`—and must conform to the Zod schema defined in [`packages/protocol/src/rest/config.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/protocol/src/rest/config.ts) [Lines 3-12]. This schema enforces the structure of authentication details, model specifications, and provider types.

At runtime, the **ProviderManager** class in [`packages/agent-core/src/session/provider-manager.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core/src/session/provider-manager.ts) handles resolution. When a session requests a model, the manager validates that the requested model belongs to the specified provider and instantiates the concrete implementation via `createProvider(this.providerConfig)` [Lines 58-77].

## Step-by-Step: Adding Additional LLM Providers

To extend Kimi Code beyond its default provider, follow these four steps:

1. **Declare the provider entry** in your configuration file (typically [`.kimi-code/config.json`](https://github.com/MoonshotAI/kimi-code/blob/main/.kimi-code/config.json)). Add a new key to the top-level `providers` object with a unique identifier.

2. **Specify the provider type** using the `type` field. This string must match a built-in implementation (e.g., `"openai"`, `"anthropic"`) or a custom type registered through the Kosong layer. The manager consults this type during instantiation in [`provider-manager.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/provider-manager.ts) [Lines 76-78].

3. **Configure authentication** by supplying either an `apiKey` string or an `oauth` sub-object. The resolution logic checks for OAuth configuration first, then falls back to a plain API key [Lines 161-163].

4. **Override model-specific settings** optionally via `model`, `baseUrl`, or `customHeaders`. These values are merged with the default model definition during request preparation [Lines 108-116].

## Code Examples for Multi-Provider Setup

### JSON Configuration for OpenAI and Anthropic

```json
{
  "providers": {
    "openai": {
      "type": "openai",
      "model": "gpt-4o-mini",
      "apiKey": "YOUR_OPENAI_API_KEY"
    },
    "anthropic": {
      "type": "anthropic",
      "model": "claude-3-5-sonnet-20241022",
      "apiKey": "YOUR_ANTHROPIC_API_KEY",
      "customHeaders": { "anthropic-version": "2023-06-01" }
    }
  },
  "default_provider": "openai"
}

```

### Programmatic Provider Selection

```typescript
import { createSession } from '@moonshot-ai/kimi-code-sdk';

const session = await createSession({
  provider: 'anthropic',
  prompt: 'Refactor this Python function to use async/await.'
});

```

### Registering a Custom Provider via Kosong

```typescript
import { registerProvider } from '@moonshot-ai/kosong';

registerProvider('my-custom-llm', {
  async call(request) {
    const response = await fetch('https://my-llm.example.com/v1/completions', {
      method: 'POST',
      headers: { 
        'Authorization': `Bearer ${process.env.MY_CUSTOM_KEY}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(request)
    });
    return response.json();
  }
});

```

## How Provider Resolution Works at Runtime

When a user selects a provider, the **ProviderManager** performs a lookup in the `providers` configuration map. It validates that the requested model exists within that provider's allowed model set, then constructs the provider instance. The architecture supports an arbitrary number of providers because the configuration is a plain record object keyed by provider name.

The web interface and CLI populate their provider selection dropdowns by querying the **Model Catalog** REST endpoint at `/v1/modelCatalog`, implemented in [`packages/protocol/src/rest/modelCatalog.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/protocol/src/rest/modelCatalog.ts) [Lines 4-30]. This endpoint exposes the provider identifier and available models, allowing users to switch between configured LLMs on-the-fly without restarting the application.

## Summary

- Kimi Code uses a `providers` map in the global configuration to support multiple LLM backends simultaneously.
- Each provider entry requires a `type`, authentication credentials (`apiKey` or `oauth`), and model specifications validated by the Zod schema in [`packages/protocol/src/rest/config.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/protocol/src/rest/config.ts).
- The `ProviderManager` in [`packages/agent-core/src/session/provider-manager.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core/src/session/provider-manager.ts) resolves provider names to concrete instances, merging runtime overrides with base configuration.
- Custom providers integrate via the Kosong abstraction layer by implementing the provider interface and calling `registerProvider`.
- The Model Catalog endpoint (`/v1/modelCatalog`) exposes configured providers to the UI, enabling dynamic provider switching.

## Frequently Asked Questions

### Can I use OAuth instead of API keys for external providers?

Yes. The provider configuration accepts an `oauth` sub-object containing OAuth-specific parameters. The `ProviderManager` checks for OAuth configuration before falling back to a plain `apiKey`, as implemented in [`packages/agent-core/src/session/provider-manager.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/agent-core/src/session/provider-manager.ts) [Lines 161-163].

### How does Kimi Code validate that a model belongs to a provider?

During session initialization, the `ProviderManager` verifies that the requested model identifier exists within the provider's configured model set. This validation occurs before calling `createProvider()` to instantiate the client [Lines 58-77].

### Is it possible to switch providers mid-session?

While the configuration supports multiple providers, provider selection typically occurs at session initialization. The UI clients fetch the available provider catalog from the `/v1/modelCatalog` endpoint defined in [`packages/protocol/src/rest/modelCatalog.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/protocol/src/rest/modelCatalog.ts) [Lines 4-30], allowing users to start new sessions with different providers without modifying configuration files.

### Where are provider types defined for built-in LLM services?

Built-in provider types such as `"openai"`, `"anthropic"`, and `"kimi"` are referenced in the `type` field of the provider configuration. The `ProviderManager` uses this string to resolve the correct implementation class during instantiation [Lines 76-78]. Custom types can be registered through the Kosong package to extend this behavior.