Summary

OpenClaw allows configured model aliases that themselves contain /, and openclaw models list shows them as aliases. But runtime model selection only checked the alias index for inputs without /. As a result, values like xiaomi/mimo-v2-pro-mit bypass alias lookup, get parsed as real provider/model refs, and can fail at runtime with Unknown model: xiaomi/mimo-v2-pro-mit.

Reproduction

Use a config like:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/xiaomi/mimo-v2-pro-mit",
        "fallbacks": []
      },
      "models": {
        "openai/xiaomi/mimo-v2-pro-mit": {
          "alias": "xiaomi/mimo-v2-pro-mit"
        }
      }
    }
  }
}

Then set a cron job payload model to the slash-form alias:

{
  "payload": {
    "kind": "agentTurn",
    "model": "xiaomi/mimo-v2-pro-mit"
  }
}

Trigger the cron job.

Expected behavior

xiaomi/mimo-v2-pro-mit should resolve through the configured alias map and run as the canonical ref:

• openai/xiaomi/mimo-v2-pro-mit

Actual behavior

The runtime skips alias resolution because the input contains /, parses it as:

• provider = "xiaomi"
• model = "mimo-v2-pro-mit"

and can fail with:

FailoverError: Unknown model: xiaomi/mimo-v2-pro-mit

Root cause

resolveModelRefFromString() only checked aliasIndex.byAlias when the input did not contain /.

That makes slash-form aliases display correctly in config/model listing, but fail to resolve during runtime selection.

Proposed fix

In resolveModelRefFromString(), always check the alias index first, regardless of whether the input contains /. If there is no alias match, then fall back to normal provider/model parsing.

Validation

Focused regression coverage can be added around:

• resolveModelRefFromString("xiaomi/mimo-v2-pro-mit")
• resolveAllowedModelRef(... raw: "xiaomi/mimo-v2-pro-mit")

to ensure slash-form aliases resolve to the canonical configured model ref instead of being treated as a real provider/model pair.