Skip to content

fix(moonshot): accept moonshotai/<model> as direct-API alias#74946

Merged
steipete merged 2 commits into
openclaw:mainfrom
jeffrey701:fix/moonshot-provider-id-alias-73876
May 10, 2026
Merged

fix(moonshot): accept moonshotai/<model> as direct-API alias#74946
steipete merged 2 commits into
openclaw:mainfrom
jeffrey701:fix/moonshot-provider-id-alias-73876

Conversation

@jeffrey701

@jeffrey701 jeffrey701 commented Apr 30, 2026

Copy link
Copy Markdown
Contributor 
### Summary

Users who copy a Kimi model id from OpenRouter (which lists models as
`moonshotai/kimi-k2.6`) and drop the `openrouter/` prefix to hit the
direct API see `Unknown model: moonshotai/kimi-k2.6`. The direct
provider is registered only as `moonshot`, so only `moonshot/kimi-k2.6`
resolves. OpenRouter's org slug, Moonshot AI's own branding, and even
this manifest's `modelPricing.providers.moonshot.openRouter` entry
already use `moonshotai` — only the direct-API name disagreed.

### Fix

The OpenAI plugin already shipped the manifest pattern for this exact
shape (`azure-openai-responses` → `openai`), with planner test coverage
at `src/model-catalog/manifest-planner.test.ts:95`. Reuse the same
`modelCatalog.aliases` mechanism in the moonshot manifest:

```json
"modelCatalog": {
  "aliases": {
    "moonshotai": { "provider": "moonshot" }
  },
  ...
}

moonshot stays as the canonical provider id — operators whose
configs already say moonshot/... are unchanged. The catalog planner
now resolves moonshotai/<model> through moonshot's existing models
list, baseUrl, api class, discovery, pricing, and auth choices.
providers, providerEndpoints, providerRequest,
providerAuthEnvVars, and providerAuthChoices all stay keyed on
moonshot — no duplication, no provider-id divergence.

Tests

src/model-catalog/manifest-planner.test.ts:

  • New plans moonshotai alias rows from the moonshot provider catalog
    case mirrors the existing azure-openai-responses test. Asserts
    that with providerFilter: "moonshotai" the planner returns rows
    with ref: "moonshotai/<model>" and the moonshot catalog's
    api/baseUrl/discovery values.
  • Existing moonshot plugin-registration contract test
    (src/plugins/contracts/plugin-registration.moonshot.contract.test.ts)
    continues to pass against the modified manifest (canonical
    providerIds: ["moonshot"] unchanged — alias is at the catalog
    layer, not the provider-registration layer).

Verification

OPENCLAW_LOCAL_CHECK=1 pnpm test src/model-catalog/manifest-planner.test.ts
# Test Files  1 passed (1)
# Tests       7 passed (7)

OPENCLAW_LOCAL_CHECK=1 pnpm test src/plugins/contracts/plugin-registration.moonshot.contract.test.ts
# Test Files  1 passed (1)
# Tests       4 passed (4)

pnpm exec oxfmt --check --threads=1 \
  src/model-catalog/manifest-planner.test.ts \
  extensions/moonshot/openclaw.plugin.json
# All matched files use the correct format.

Closes #73876

@clawsweeper

clawsweeper Bot commented Apr 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs changes before merge.

Summary
The PR adds a moonshotai modelCatalog.aliases entry to the Moonshot plugin manifest and a manifest-planner test for alias-filtered catalog rows.

Reproducibility: yes. The linked issue provides concrete logs and current-main source shows moonshotai/kimi-k2.6 keeps provider moonshotai because the runtime provider normalizer has no Moonshot AI alias.

Next step before merge
A narrow automated repair can amend this PR by adding the missing runtime alias, focused regression coverage, and the required user-facing changelog entry.

Security
Cleared: The diff changes only plugin manifest metadata and a unit test, with no new dependency, workflow, permission, artifact-download, publishing, or secret-handling surface.

Review findings

  • [P2] Normalize the runtime provider alias — extensions/moonshot/openclaw.plugin.json:36-40
Review details

Best possible solution:

Add runtime provider-id normalization for moonshotai and moonshot-ai to the canonical moonshot id, keep moonshot as the provider/plugin/auth/config key, preserve useful catalog coverage, and add the required changelog entry.

Do we have a high-confidence way to reproduce the issue?

Yes. The linked issue provides concrete logs and current-main source shows moonshotai/kimi-k2.6 keeps provider moonshotai because the runtime provider normalizer has no Moonshot AI alias.

Is this the best way to solve the issue?

No. modelCatalog.aliases only affects catalog/suppression planning, while the reported failure is direct runtime model resolution; provider-id normalization is the narrow maintainable fix.

Full review comments:

  • [P2] Normalize the runtime provider alias — extensions/moonshot/openclaw.plugin.json:36-40
    Adding moonshotai only under modelCatalog.aliases plans provider-filtered catalog rows, but the reported failure is runtime model resolution. parseModelRef and resolveModelWithRegistry still keep moonshotai as the provider because normalizeProviderId has no Moonshot alias, so moonshotai/kimi-k2.6 can still hit Unknown model. Add the runtime alias and cover direct model resolution.
    Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.9

Acceptance criteria:

  • OPENCLAW_LOCAL_CHECK=1 pnpm test src/agents/model-selection.test.ts src/agents/pi-embedded-runner/model.test.ts src/model-catalog/manifest-planner.test.ts
  • pnpm exec oxfmt --check --threads=1 src/agents/provider-id.ts src/agents/model-selection.test.ts src/agents/pi-embedded-runner/model.test.ts src/model-catalog/manifest-planner.test.ts extensions/moonshot/openclaw.plugin.json CHANGELOG.md
  • pnpm check:changed in Testbox before handoff

What I checked:

Likely related people:

  • steipete: Provider alias/auth normalization and provider-prefixed model resolution history includes commits touching src/agents/provider-id.ts and src/agents/pi-embedded-runner/model.ts, the files that need the runtime alias fix. (role: runtime provider-id and model resolver maintainer; confidence: high; commits: 9e4f478f866c, c64f6adc83a5, 6b0c72bec8c4; files: src/agents/provider-id.ts, src/agents/pi-embedded-runner/model.ts, src/agents/model-selection-normalize.ts)
  • Vincent Koc: Current blame for the provider normalization, model resolver, Moonshot manifest, model catalog planner, and manifest docs in this checkout points to the recent broad commit that reintroduced these paths on main. (role: recent adjacent maintainer; confidence: medium; commits: e3d76d2e1f76; files: src/agents/provider-id.ts, src/agents/pi-embedded-runner/model.ts, extensions/moonshot/openclaw.plugin.json)

Remaining risk / open question:

  • Merging as-is would make moonshotai appear in catalog-filtered planning while the direct runtime path can still report Unknown model: moonshotai/kimi-k2.6.
  • This read-only review did not execute tests; the verdict is based on PR diff, current-main source, docs, and related issue/PR context.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 13dc14d43ec2.

@clawsweeper clawsweeper Bot mentioned this pull request Apr 30, 2026
Closed
jeffrey701 and others added 2 commits May 10, 2026 07:07
@jeffrey701 @steipete
fix(moonshot): accept moonshotai/<model> as direct-API alias
ec5b9ce 
Users copying a Kimi model id from OpenRouter (which lists models as
moonshotai/kimi-k2.6) and dropping the openrouter/ prefix to hit the
direct API saw 'Unknown model: moonshotai/kimi-k2.6'. The direct
provider was registered only as moonshot, so only moonshot/kimi-k2.6
resolved. The OpenRouter org slug, Moonshot AI's own branding, and the
existing moonshot manifest's modelPricing.providers.moonshot.openRouter
entry all use the moonshotai form — only the direct-API name disagreed.

The OpenAI plugin already shipped the manifest pattern for this exact
shape (azure-openai-responses → openai), and there's a planner test
that pins it down. Reuse the same modelCatalog.aliases mechanism in
the moonshot manifest:

  "modelCatalog": {
    "aliases": {
      "moonshotai": { "provider": "moonshot" }
    },
    ...
  }

This keeps moonshot as the canonical id (no rename, no breaking
change for operators whose configs already say moonshot/...). The
catalog planner now resolves moonshotai/<model> through moonshot's
existing models list, baseUrl, api class, discovery, pricing, and
auth choices unchanged. providers, providerEndpoints,
providerRequest, providerAuthEnvVars, and providerAuthChoices stay
keyed on moonshot — no duplication, no provider-id divergence.

Test: new planner case in
src/model-catalog/manifest-planner.test.ts mirrors the existing
azure-openai-responses test — asserts that with providerFilter:
'moonshotai' the planner returns rows with ref 'moonshotai/<model>'
and the moonshot catalog's api/baseUrl/discovery values. The existing
moonshot plugin-registration contract test continues to pass against
the modified manifest (canonical providerIds: ['moonshot']
unchanged).

Closes openclaw#73876
@steipete
fix(moonshot): resolve moonshotai direct model refs
5905d2b
@steipete
steipete force-pushed the fix/moonshot-provider-id-alias-73876 branch from e9d91de to 5905d2b Compare May 10, 2026 06:11
steipete
steipete approved these changes May 10, 2026
View reviewed changes

@steipete steipete left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blocking findings.

This now fixes the reported direct-provider path, not just the catalog display path: normalizeProviderId() maps both moonshotai and moonshot-ai to canonical moonshot, the Moonshot manifest exposes both catalog aliases, and resolver tests prove moonshotai/kimi-k2.6 plus moonshot-ai/kimi-k2.6 resolve through the direct Moonshot config.

Verification:

  • pnpm test src/agents/model-selection.test.ts src/agents/pi-embedded-runner/model.test.ts src/model-catalog/manifest-planner.test.ts
  • pnpm test src/plugins/contracts/plugin-registration.moonshot.contract.test.ts
  • git diff --check
  • OPENCLAW_TESTBOX=0 pnpm check:changed

@openclaw-barnacle openclaw-barnacle Bot added the agents Agent runtime and tooling label May 10, 2026
@steipete
steipete merged commit c919702 into openclaw:main May 10, 2026
100 of 103 checks passed
@openclaw-barnacle openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 10, 2026
This was referenced Jun 19, 2026
Closed
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@steipete steipete steipete approved these changes

Assignees

No one assigned

Labels

agents Agent runtime and tooling extensions: moonshot size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[Bug]: Direct provider names inconsistency (Eg. 'moonshot' should be 'moonshotai' to match OpenRouter slug convention)

2 participants

@jeffrey701 @steipete