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

The ai-agent-book repository defines 14 LLM provider aliases in 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 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 performs the translation:

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:

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

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:

provider: moonshot          # Interpreted as kimi

model: moonshot-v1-8k
temperature: 0.7

provider: bailian           # Interpreted as dashscope

model: qwen-max

Verification via Test Suite

The 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
• 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 to include your custom mapping, then add a corresponding test case in 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}