# How the Kos Provider Abstraction Layer Selects and Routes Models in Kimi Code

> Discover how the Kos provider abstraction layer in Kimi Code selects and routes models. Learn about the two-step process involving createProvider and getModelCapability for efficient model management.

- Repository: [Moonshot AI/kimi-code](https://github.com/MoonshotAI/kimi-code)
- Tags: internals
- Published: 2026-07-25

---

**The Kos provider abstraction layer determines request routing through a two-step process: `createProvider` selects the concrete adapter based on the provider type, while `getModelCapability` performs a static table lookup to resolve model-specific capabilities like vision and reasoning.**

The Kos (Kosong) package powers the LLM integration throughout the MoonshotAI/kimi-code repository, serving as the central provider abstraction layer that translates model names into executable ChatProvider instances. Understanding how this system selects adapters and routes capabilities is essential for debugging routing issues or extending the codebase with new LLM backends.

## Provider Selection via createProvider

The first step in the routing process occurs in [`packages/kosong/src/providers/index.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/index.ts), where the `createProvider` factory function (lines 26-38) maps a user-supplied **provider type** to its concrete implementation class. This switch statement instantiates the correct adapter code based solely on the `type` field in the configuration object, handling authentication, request serialization, and streaming protocols separately for each backend.

Supported provider types include `anthropic`, `openai`, `kimi`, `google-genai`, `openai_responses`, and `vertexai`. Each maps to a specific subclass:

- `AnthropicChatProvider` for Anthropic models
- `OpenAIResponsesChatProvider` for OpenAI's responses API
- `KimiChatProvider` for Moonshot AI models
- `GoogleGenAIChatProvider` for Gemini models

```typescript
// packages/kosong/src/providers/index.ts (simplified)
import { createProvider } from '#/providers';

const cfg = {
  type: 'openai_responses',
  apiKey: process.env.OPENAI_API_KEY,
  model: 'gpt-4o-mini',
};

const chat = createProvider(cfg);  // Returns OpenAIResponsesChatProvider

```

## Capability Registry and Static Model Routing

Once the provider type is established, the system resolves **what the model can do** through `getModelCapability` in [`packages/kosong/src/providers/capability-registry.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/capability-registry.ts) (lines 54-73). This function performs a deterministic, zero-network lookup that matches the model name against provider-specific catalogs using prefix rules and matcher functions.

Each provider maintains a `CapabilityCatalogEntry` array (defined in lines 18-32, 33-42, 44-53, 88-95) containing:
- **Matcher functions** such as `hasPrefix` or `isOpenAIReasoningModel` to identify model families
- **Capability constants** like `OPENAI_REASONING_CAPABILITY` or `ANTHROPIC_VISION_TOOL_CAPABILITY` that define supported features

The result is a `ModelCapability` object (defined in [`src/catalog.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/src/catalog.ts)) specifying:
- `image_in`: Vision input support
- `video_in`: Video input support
- `thinking`: Reasoning/thinking mode availability
- `tool_use`: Function calling capabilities
- `max_context_tokens`: Context window size

```typescript
// packages/kosong/src/providers/capability-registry.ts
import { getModelCapability } from '#/providers';

const caps = getModelCapability('openai_responses', 'gpt-4o-mini');
// caps = { image_in: true, video_in: false, thinking: false, tool_use: true, ... }

if (caps.thinking) {
  chat.withThinking('high');  // Enable reasoning for supported models
}

```

## How Routing Decisions Drive Request Handling

The Kos provider abstraction layer combines these two steps to determine final request routing behavior. The **provider type** selects the transport adapter (how to send the request), while the **model capabilities** determine the payload shape (what to send).

For example, in [`packages/kosong/src/providers/openai-responses.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/openai-responses.ts), the adapter consumes capability data to conditionally include fields like `thinking_effort` or `max_completion_tokens`. This separation allows the host application to route vision requests to image-capable models while using the same provider infrastructure.

```typescript
// Complete integration example
export function buildChatProvider(
  type: ProviderType,
  model: string,
  opts: Partial<ProviderConfig>
) {
  const provider = createProvider({ type, model, ...opts } as any);
  const caps = getModelCapability(type, model);

  // Automatically enable vision for image-capable models
  if (caps.image_in) {
    provider.withVision();
  }
  
  // Configure thinking mode for reasoning models
  if (caps.thinking) {
    provider.withThinking('medium');
  }
  
  return provider;
}

```

Because capability lookup is **pure and static**, requiring no network calls or external state, model selection remains fast and deterministic even under high throughput.

## Summary

- The `createProvider` factory in [`packages/kosong/src/providers/index.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/index.ts) instantiates the correct ChatProvider subclass based on the provider type string.
- `getModelCapability` in [`packages/kosong/src/providers/capability-registry.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/capability-registry.ts) performs static prefix-based lookups to resolve model capabilities without network overhead.
- Provider types determine adapter code (authentication and transport), while model names determine capability flags (vision, reasoning, tool use).
- The capability registry uses `CapabilityCatalogEntry` objects with matcher functions to map model names to capability constants.
- This architecture allows deterministic routing decisions and easy extension by adding new entries to the provider switch statement and capability catalogs.

## Frequently Asked Questions

### How does the Kos provider abstraction layer determine which adapter to use for a given model?

The layer uses the `type` field from the `ProviderConfig` object to select the implementation. In [`packages/kosong/src/providers/index.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/index.ts), a switch statement (lines 26-38) maps string values like `'anthropic'` or `'openai_responses'` to concrete classes such as `AnthropicChatProvider` or `OpenAIResponsesChatProvider`. The model name itself does not influence provider selection—only the type does.

### What is the performance impact of model capability lookup in Kos?

Capability lookup has zero network overhead and minimal CPU cost. The `getModelCapability` function performs static table scans against in-memory `CapabilityCatalogEntry` arrays using simple string prefix checks. This design ensures routing decisions occur in microseconds regardless of model complexity or provider latency.

### How can I add support for a new provider type in the Kos abstraction layer?

Extend the system by adding a new case to the switch statement in [`packages/kosong/src/providers/index.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/index.ts) that instantiates your new ChatProvider subclass. Then create a corresponding capability helper function (following the pattern of `getAnthropicModelCapability`) and register it in [`packages/kosong/src/providers/capability-registry.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/providers/capability-registry.ts) to map model names to capabilities.

### What capabilities are tracked by the Kos capability registry?

The registry tracks `ModelCapability` objects defined in [`packages/kosong/src/catalog.ts`](https://github.com/MoonshotAI/kimi-code/blob/main/packages/kosong/src/catalog.ts), including boolean flags for `image_in` (vision), `video_in`, `thinking` (reasoning modes), and `tool_use`, plus numeric values like `max_context_tokens`. These capabilities determine whether the host enables features like image uploads, reasoning effort parameters, or function calling in the request payload.