# Complete List of LLM Provider Aliases in ai-agent-book

> Discover the 14 LLM provider aliases in ai-agent-book. Map human-friendly names like moonshot to backend providers like kimi for easier integration.

- Repository: [Bojie Li/ai-agent-book](https://github.com/bojieli/ai-agent-book)
- Tags: api-reference
- Published: 2026-08-22

---

**The ai-agent-book repository defines 14 LLM provider aliases in [`agentbook/providers/registry.py`](https://github.com/bojieli/ai-agent-book/blob/main/agentbook/providers/registry.py) that map human-friendly names like "moonshot" and "qwen" to canonical backend providers such as "kimi" and "dashscope".**

The `bojieli/ai-agent-book` project simplifies LLM integration by allowing developers to refer to providers using intuitive nicknames rather than strict canonical names. This alias system is centralized in the provider registry module and enforced through comprehensive unit tests. Understanding these mappings ensures your agent configurations and API calls resolve to the correct backend infrastructure.

## Complete Alias-to-Provider Mapping

The `_ALIASES` dictionary in [`agentbook/providers/registry.py`](https://github.com/bojieli/ai-agent-book/blob/main/agentbook/providers/registry.py) establishes the following canonical relationships:

| Alias | Canonical Provider |
|-------|-------------------|
| `dashscope` | `dashscope` |
| `qwen` | `dashscope` |
| `bailian` | `dashscope` |
| `siliconflow` | `siliconflow` |
| `doubao` | `doubao` |
| `kimi` | `kimi` |
| `moonshot` | `kimi` |
| `openrouter` | `openrouter` |
| `openai` | `openai` |
| `google` | `gemini` |
| `gemini` | `gemini` |
| `ark` | `openai` |
| `ollama` | `ollama` |

**Key observations:**

- **Dashscope** aggregates multiple Alibaba Cloud service names including `qwen` and `bailian`
- **Kimi** recognizes both the official name and the `moonshot` alias
- **Gemini** accepts both `google` and `gemini` as valid identifiers
- **Ark** (ByteDance's platform) maps to the `openai` compatible interface

## How the Alias Registry Works

The registry module implements a two-tier lookup system that decouples user-facing names from internal backend implementations.

### Core Provider Definitions

The `PROVIDERS` set contains the canonical backend identifiers: `dashscope`, `siliconflow`, `doubao`, `kimi`, `openrouter`, `openai`, `gemini`, and `ollama`. These strings correspond to actual implementation classes and API endpoints configured elsewhere in the codebase.

### Alias Resolution Logic

The `canonical_provider(name)` function in [`agentbook/providers/registry.py`](https://github.com/bojieli/ai-agent-book/blob/main/agentbook/providers/registry.py) performs the translation:

```python
from agentbook.providers import canonical_provider, SUPPORTED_PROVIDERS

# Returns the canonical name for any valid alias

canonical_provider("moonshot")  # Returns: 'kimi'

canonical_provider("qwen")      # Returns: 'dashscope'

```

The `SUPPORTED_PROVIDERS` constant is dynamically constructed as the union of `PROVIDERS` and all keys in `_ALIASES`, enabling the rest of the framework to accept either canonical names or aliases interchangeably.

### Runtime Backend Resolution

The `resolve_backend()` function utilizes the canonical name to instantiate the appropriate client:

```python
from agentbook.providers import resolve_backend

# Accepts aliases and returns the configured backend instance

backend = resolve_backend("google")  # Resolves to Gemini backend

```

## Practical Usage Examples

You can leverage these aliases throughout the ai-agent-book codebase when defining agents or configuring model interactions.

### Python API Resolution

```python
from agentbook.providers import canonical_provider, resolve_backend

def initialize_llm(provider_alias: str):
    """Initialize LLM using either canonical name or alias."""
    canonical = canonical_provider(provider_alias)
    backend = resolve_backend(canonical)
    return backend.get_client()

# All of these resolve correctly

client = initialize_llm("moonshot")
client = initialize_llm("kimi")
client = initialize_llm("ark")

```

### YAML Configuration Files

Agent configuration files accept aliases in the `provider` field:

```yaml
provider: moonshot          # Interpreted as kimi

model: moonshot-v1-8k
temperature: 0.7

```

```yaml
provider: bailian           # Interpreted as dashscope

model: qwen-max

```

### Verification via Test Suite

The [`tests/test_providers.py`](https://github.com/bojieli/ai-agent-book/blob/main/tests/test_providers.py) file validates that each alias resolves to its designated canonical provider, ensuring the mapping remains synchronized across releases. These tests explicitly verify entries like `assert canonical_provider("google") == "gemini"` and validate that `SUPPORTED_PROVIDERS` contains all alias keys.

## Summary

- **14 total aliases** map to 8 canonical providers in [`agentbook/providers/registry.py`](https://github.com/bojieli/ai-agent-book/blob/main/agentbook/providers/registry.py)
- **Dashscope** recognizes `dashscope`, `qwen`, and `bailian` as equivalent identifiers
- **Kimi** accepts both `kimi` and `moonshot` aliases for the Moonshot AI backend
- **Gemini** treats `google` and `gemini` as interchangeable
- **Ark** maps to the `openai` compatible interface for ByteDance's platform
- The `canonical_provider()` function in the registry converts any alias to its canonical form before backend instantiation

## Frequently Asked Questions

### How do I add a new custom alias for a provider?

Edit the `_ALIASES` dictionary in [`agentbook/providers/registry.py`](https://github.com/bojieli/ai-agent-book/blob/main/agentbook/providers/registry.py) to include your custom mapping, then add a corresponding test case in [`tests/test_providers.py`](https://github.com/bojieli/ai-agent-book/blob/main/tests/test_providers.py) to verify resolution. The framework automatically includes new aliases in `SUPPORTED_PROVIDERS` upon import.

### Why does the "google" alias resolve to "gemini" instead of "openai"?

The mapping reflects the architectural decision to route Google AI requests through the native Gemini API rather than the OpenAI-compatible endpoint. This ensures access to Gemini-specific features and native authentication flows implemented in the `gemini` backend class.

### Can I use aliases when specifying models via environment variables?

Yes. The CLI and configuration loader both call `canonical_provider()` during initialization, so environment variables like `PROVIDER=moonshot` or `PROVIDER=qwen` resolve correctly to `kimi` and `dashscope` respectively before establishing the API connection.

### What happens if I provide an unsupported alias?

The `canonical_provider()` function raises a `ValueError` with the message "Unknown provider: {alias}" when encountering strings not present in `PROVIDERS` or `_ALIASES`. This validation occurs early in the initialization process to prevent runtime API errors.