Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The direct Moonshot AI provider is named moonshot in openclaw, but OpenRouter (and Moonshot AI's own branding) uses moonshotai as the organization slug. This creates a confusing and inconsistent naming mismatch for users who configure both direct and OpenRouter access.

Steps to reproduce

1. Browse OpenRouter's model catalog — Kimi K2 is listed as moonshotai/kimi-k2.6
2. Configure openclaw to use kimi as the primary model by specifying moonshotai/kimi-k2.6 (the string you see on 3. OpenRouter, without the openrouter/ prefix)
3. Observe that openclaw fails with Unknown model: moonshotai/kimi-k2.6 The working direct-API form is actually moonshot/kimi-k2.6

Expected behavior

Direct provider names should match OpenRouter's organization slugs. The openrouter/ prefix should act as a clean scope operator, meaning:

moonshotai/kimi-k2.6 → direct Moonshot API (user's own key) openrouter/moonshotai/kimi-k2.6 → routed via OpenRouter This convention already works correctly for xiaomi:

xiaomi/mimo-v2-flash → direct Xiaomi API ✓ openrouter/xiaomi/mimo-v2-flash → via OpenRouter ✓

Actual behavior

The direct Moonshot provider is named moonshot instead of moonshotai, breaking the convention that works for every other provider. Users who copy moonshotai/kimi-k2.6 from OpenRouter's UI and attempt to use it as a direct provider get a cryptic "Unknown model" error with no hint that the correct name is moonshot/kimi-k2.6.

OpenClaw version

2026.4.26

Operating system

EndeavourOS Titan

Install method

npm

Model

Kimi-2.6

Provider / routing chain

User configures: moonshotai/kimi-k2.6 (copied from OpenRouter UI) ↓ openclaw model resolver: "Unknown model: moonshotai/kimi-k2.6" ↓ fallback chain triggered → openrouter/minimax/minimax-m2.7 Intended path (after discovering correct name via wizard): moonshot/kimi-k2.6 → auth profile: moonshot:default (api_key mode) → provider: moonshot → baseUrl: https://api.moonshot.ai/v1 → direct Moonshot AI API (no OpenRouter involvement) Equivalent working path for reference: xiaomi/mimo-v2-flash → auth profile: xiaomi:default (api_key mode) → provider: xiaomi → baseUrl: https://api.xiaomimimo.com/v1

Additional provider/model setup details

Auth profiles involved: moonshot:default (provider: moonshot, mode: api_key). No per-agent overrides. Provider definition in models.providers.moonshot with api: openai-completions. The moonshotai plugin entry (added manually by user following OpenRouter naming) generates a repeated config warning on every gateway start/reload: plugins.entries.moonshotai: plugin not found: moonshotai (stale config entry ignored). The onboarding wizard (openclaw onboard) correctly resolves to moonshot/kimi-k2.6 during initial setup, meaning users who run the wizard are unaffected — only users who configure models manually after onboarding hit this.

Logs, screenshots, and evidence

# Failure: model specified as moonshotai/kimi-k2.6 (OpenRouter naming)
error  diagnostic  lane task error: lane=cron-nested durationMs=26043
       error="FailoverError: Unknown model: moonshotai/kimi-k2.6"

warn   model-fallback  Model "moonshotai/kimi-k2.6" not found.
       Fell back to "openrouter/minimax/minimax-m2.7".

# Stale plugin warning (repeated on every restart/reload):
warn   Config warnings:
       - plugins.entries.moonshotai: plugin not found: moonshotai
         (stale config entry ignored; remove it from plugins config)

# Success: after wizard resolved correct name
info   gateway  agent model: moonshot/kimi-k2.6

# Wizard auto-enabling correct provider:
info   gateway  gateway: auto-enabled plugins:
                - moonshot/kimi-k2.6 model configured, enabled automatically.
openclaw version: 2026.4.26

Impact and severity

Affected users: Any user who configures kimi/Moonshot AI models manually (rather than exclusively through the onboarding wizard) — specifically users who reference the model ID from OpenRouter's model browser or documentation, where it is displayed as moonshotai/kimi-k2.6

Severity: Blocks workflow — the model silently fails and falls back to a different provider, consuming fallback quota and potentially using a paid OpenRouter model when the user intended to use their free direct Moonshot API key

Frequency: Always reproducible when the model is specified as moonshotai/kimi-k2.6 without the openrouter/ prefix

Consequence: Silent wrong-model execution (user believes they are on kimi direct but the fallback runs on minimax via OpenRouter), unnecessary rate-limit pressure on fallback models, and repeated noisy config warnings on every gateway restart once a user adds the moonshotai plugin entry following the logical-but-wrong naming assumption

Additional information

Suggested fix

Rename the internal provider from moonshot to moonshotai Add a migration alias so existing configs using moonshot/... continue to work (with an optional deprecation warning) Update any documentation or wizard-generated configs that reference moonshot/ Additional context

Discovered while debugging model fallback issues. The openclaw onboarding wizard correctly resolved this to moonshot/kimi-k2.6 during setup, but users who configure models manually after the fact (e.g., adding kimi as a fallback by copying the model ID from OpenRouter's website) will hit this inconsistency every time.

The inconsistency is specific to this one provider — all other direct providers observed use naming that matches OpenRouter's slugs (e.g., xiaomi/mimo-v2-flash works correctly as both the direct provider name and the OpenRouter sub-path). The moonshot vs moonshotai divergence appears to be a historical naming choice that predates or diverged from OpenRouter's slug convention for this provider. No regression context available — cannot confirm a version where moonshotai/ worked as a direct provider name.