Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Model lookup fails when provider ID contains hyphens (e.g. kimi-coding) [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#60449•Fetched 2026-04-08 02:51:03
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
goodnesssharegoodnessshare
Participants
goodnesssharegoodnessshare
Timeline (top)
closed ×1locked ×1

Root Cause

find() normalizes the provider ID on lookup but the registry stores models under the original provider ID. The normalization and storage keys are inconsistent.

RAW_BUFFERClick to expand / collapse

Problem

When a provider ID contains a hyphen (e.g. kimi-coding), the model lookup normalizes it to the base provider name (kimi), but the model registry stores models under the full provider ID (kimi-coding). This causes find() to miss registered models.

Additionally, the kimi-coding/k2p5 image model is broken — it fails to resolve for image analysis tasks due to the same provider ID normalization issue.

Steps to Reproduce

  1. Configure a provider with a hyphenated ID like kimi-coding in openclaw.json
  2. Register models under kimi-coding/* (e.g. kimi-coding/k2p5)
  3. Attempt model lookup — the normalization strips the hyphen segment, looking for kimi/k2p5 instead of kimi-coding/k2p5
  4. Lookup fails despite the model being registered
  5. Same issue affects kimi-coding/k2p5 image model — fails on image analysis tasks

Root Cause

find() normalizes the provider ID on lookup but the registry stores models under the original provider ID. The normalization and storage keys are inconsistent.

Suggested Fixes

  1. Normalize at registration time — store models under the normalized provider ID
  2. Try both normalized and original provider IDs on lookup — fallback in find()
  3. Normalize both sides consistently — pick one canonical form and use it everywhere

Option 2 is the least disruptive (~5 lines in the model discovery wrapper).

Environment

  • OpenClaw version: recent (observed with kimi-coding/k2p5 provider)
  • Affects any provider ID containing hyphens that get normalized differently than stored
  • kimi-coding/k2p5 image model confirmed broken

extent analysis

TL;DR

Try modifying the find() method to attempt lookup with both the normalized and original provider IDs to resolve the inconsistency between model registration and lookup.

Guidance

  • Verify the issue by checking if the model registry stores models under the full provider ID (e.g., kimi-coding/k2p5) while the find() method normalizes the provider ID to kimi/k2p5.
  • Implement a fallback in the find() method to try both the normalized and original provider IDs, as suggested in the "Suggested Fixes" section.
  • Consider normalizing provider IDs consistently throughout the system to prevent similar issues in the future.
  • Test the modified find() method with the kimi-coding/k2p5 image model to ensure it resolves correctly for image analysis tasks.

Example

No explicit code example is provided, but the modification to the find() method should be minimal, as mentioned in the "Suggested Fixes" section (~5 lines in the model discovery wrapper).

Notes

This solution assumes that the normalization of provider IDs is the root cause of the issue and that modifying the find() method will resolve the problem. However, a more comprehensive solution might involve normalizing provider IDs consistently throughout the system.

Recommendation

Apply the workaround by modifying the find() method to try both normalized and original provider IDs, as this is the least disruptive solution (~5 lines of code) and can be implemented quickly to resolve the issue.

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…
#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING