Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When two different providers have a model with the same model ID, executing /model <provider_a>/<model_id> reports success, but the actual API call silently falls back to <provider_b>/<model_id> with "(selected model unavailable)".

Additionally, the fallback bypasses the user's configured fallback chain entirely — even though the user had minimax-portal/MiniMax-M2.7 configured as the fallback, the actual request was routed to Deepseek/deepseek-v4-flash instead.

Steps to reproduce

1.Configure two providers with identical model IDs, e.g.: Deepseek/deepseek-v4-flash and qianfan/deepseek-v4-flash
2.Run /model qianfan/deepseek-v4-flash → shows success
3.Check /status → shows: "Fallback: Deepseek/deepseek-v4-flash (selected model unavailable)"
4.All requests silently use the other provider's model with the same ID, ignoring the configured fallback list

Expected behavior

Models with the same ID from different providers should be treated as independent model entries
Fallback should follow the user's configured fallback chain, not auto-redirect to another provider with the same model ID

Actual behavior

Actual behavior use Deepseek/deepseek-v4-flash

OpenClaw version

OpenClaw version: 2026.5.7

Operating system

window11 / centos 8

Install method

No response

Model

qianfan/deepseek-v4-flash & Deepseek/deepseek-v4-flash

Provider / routing chain

openclaw qianfan/deepseek-v4-flash

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response