Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix /model status shows phantom provider extracted from OpenRouter model ID prefix [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62317•Fetched 2026-04-08 03:06:09
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
fireshfiresh
Participants
fireshfiresh
Timeline (top)
cross-referenced ×2referenced ×2

When configuring an OpenRouter model whose ID contains a known provider prefix (e.g. google/gemini-3-flash-preview), /model status displays a phantom [google] provider entry alongside the intended [openrouter] entry.

Root Cause

loadModelCatalog() in src/agents/model-catalog.ts uses @mariozechner/pi-coding-agent's ModelRegistry to parse models.json. The registry appears to split model IDs like google/gemini-3-flash-preview on the / and register google as a separate native provider — even though the model is only configured under the openrouter provider.

The buildModelPickerCatalog / /model status rendering then groups models by entry.provider, so this auto-inferred google provider shows up as a separate group with no auth.

Fix Action

Fixed

PR fix notes

PR #62323: fix: filter phantom provider entries inferred from aggregator model ID prefixes

Description (problem / solution / changelog)

Summary

  • Fixes #62317: /model status shows a phantom [google] provider entry when an OpenRouter model has an ID like google/gemini-3-flash-preview
  • The pi-coding-agent ModelRegistry splits model IDs on / and registers the prefix as a separate native provider, causing duplicate phantom entries
  • After collecting registry entries, we now detect and filter entries whose provider was auto-inferred from an aggregator model's ID prefix (e.g., google from openrouter's google/gemini-3-flash-preview) while keeping entries from explicitly configured providers
  • Also fixes pre-existing lint warnings (no-unnecessary-type-conversion) in the touched loop

Test plan

  • Added test: phantom provider entries from aggregator model ID prefixes are filtered out
  • Added test: entries from explicitly configured providers are preserved even with slashed model IDs
  • All 12 existing tests in model-catalog.test.ts continue to pass

Changed files

  • src/agents/model-catalog.test.ts (modified, +74/-0)
  • src/agents/model-catalog.ts (modified, +33/-3)

PR #62481: fix: filter phantom provider groups inferred from OpenRouter model IDs [AI-assisted]

Description (problem / solution / changelog)

Summary

This PR fixes the phantom native-provider group reported in #62317 when an aggregator model id already includes a provider-like prefix.

What changed

  • filters auto-inferred native-provider entries when the same model is already present under an aggregator-qualified id
  • keeps explicitly configured native providers intact, so real multi-provider setups still show both entries
  • adds regression coverage for the OpenRouter-prefixed model case

Why

Before this change, /model status could show a fake [google] provider with missing auth for a model that was only configured under [openrouter]. After this change, the status output keeps the real aggregator entry and suppresses only the shadow native-provider artifact.

Testing

  • Ran corepack pnpm exec vitest run src/agents/model-catalog.test.ts --environment node
  • Verified the regression case in model-catalog.test.ts

AI usage

This PR was AI-assisted. I reviewed the change manually, understand the implementation, and validated it locally.

Fixes #62317

Changed files

  • src/agents/model-catalog.test.ts (modified, +72/-0)
  • src/agents/model-catalog.ts (modified, +50/-2)

Code Example

[openrouter] endpoint: https://openrouter.ai/api/v1 api: openai-completions auth: sk-or-v1...xxxx
  • openrouter/google/gemini-3-flash-preview (gemini-3-flash)

---

[google] endpoint: default auth: missing
  • google/gemini-3-flash-preview

[openrouter] endpoint: https://openrouter.ai/api/v1 api: openai-completions auth: sk-or-v1...xxxx
  • openrouter/google/gemini-3-flash-preview (gemini-3-flash)
  • openrouter/xiaomi/mimo-v2-pro (mimo-v2-pro)
RAW_BUFFERClick to expand / collapse

Description

When configuring an OpenRouter model whose ID contains a known provider prefix (e.g. google/gemini-3-flash-preview), /model status displays a phantom [google] provider entry alongside the intended [openrouter] entry.

Steps to reproduce

  1. Configure models.json with only an openrouter provider containing a model with ID google/gemini-3-flash-preview
  2. Run /model status

Expected behavior

Only one entry under [openrouter]:

[openrouter] endpoint: https://openrouter.ai/api/v1 api: openai-completions auth: sk-or-v1...xxxx
  • openrouter/google/gemini-3-flash-preview (gemini-3-flash)

Actual behavior

An extra [google] provider group appears with auth: missing:

[google] endpoint: default auth: missing
  • google/gemini-3-flash-preview

[openrouter] endpoint: https://openrouter.ai/api/v1 api: openai-completions auth: sk-or-v1...xxxx
  • openrouter/google/gemini-3-flash-preview (gemini-3-flash)
  • openrouter/xiaomi/mimo-v2-pro (mimo-v2-pro)

Root cause

loadModelCatalog() in src/agents/model-catalog.ts uses @mariozechner/pi-coding-agent's ModelRegistry to parse models.json. The registry appears to split model IDs like google/gemini-3-flash-preview on the / and register google as a separate native provider — even though the model is only configured under the openrouter provider.

The buildModelPickerCatalog / /model status rendering then groups models by entry.provider, so this auto-inferred google provider shows up as a separate group with no auth.

Suggested fix

Either:

  1. In loadModelCatalog: after collecting entries from the registry, deduplicate/filter entries whose provider was auto-inferred from an OpenRouter (or other aggregator) model ID prefix, when the same model already exists under the aggregator provider.
  2. In /model status rendering: skip provider groups that have auth: missing and whose models are already listed under another provider.
  3. In pi-coding-agent: don't infer a native provider from model ID prefixes when the model is already scoped under a configured provider like openrouter.

Environment

  • OpenClaw 2026.4.5 (3e72c03)
  • OS: Linux (Debian)

extent analysis

TL;DR

Filter out auto-inferred providers with missing authentication in the /model status rendering to prevent duplicate entries.

Guidance

  • Identify the buildModelPickerCatalog function responsible for rendering the model status and modify it to skip provider groups with auth: missing when the models are already listed under another provider.
  • Consider implementing a deduplication step in loadModelCatalog to filter out entries whose provider was auto-inferred from an OpenRouter model ID prefix.
  • Review the ModelRegistry usage in loadModelCatalog to understand how it splits model IDs and registers providers, and adjust the logic accordingly.
  • Verify that the fix does not introduce any unintended behavior for models with legitimate native providers.

Example

// In buildModelPickerCatalog function
const providerGroups = {};
// ...
if (entry.provider !== 'google' || entry.auth !== 'missing') {
  // Add entry to provider group
}

Notes

The suggested fix assumes that the auth: missing indicator is reliable for identifying auto-inferred providers. Additional testing may be necessary to ensure the fix works correctly for all scenarios.

Recommendation

Apply workaround: Filter out auto-inferred providers with missing authentication in the /model status rendering, as this approach is more contained and less likely to introduce unintended side effects.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Only one entry under [openrouter]:

[openrouter] endpoint: https://openrouter.ai/api/v1 api: openai-completions auth: sk-or-v1...xxxx
  • openrouter/google/gemini-3-flash-preview (gemini-3-flash)
#api#installation#tensor shape#autograd error#model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING