Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Configured openrouter:free model refs are mis-resolved to anthropic/openrouter:free on OpenClaw 2026.3.24 and 2026.3.28.

Steps to reproduce

1. Configure an agent model as openrouter:free.
2. Run openclaw models status --agent <agent-id>.
3. Observe the warning Model "openrouter:free" specified without provider. Falling back to "anthropic/openrouter:free".
4. Observe the effective model becomes anthropic/openrouter:free.
5. When the model is actually used in a run, it fails with Unknown model: anthropic/openrouter:free.

Expected behavior

openrouter:free should not fall back to Anthropic. It should resolve through an OpenRouter compatibility path, ideally to a configured concrete OpenRouter free model. Relatedly, openrouter:auto should be handled explicitly as openrouter/auto.

Actual behavior

openrouter:free is treated as providerless in resolveConfiguredModelRef(), rewritten to anthropic/openrouter:free, and then fails at runtime as an unknown model. A naive generic provider:model parse also produces an invalid OpenRouter path (openrouter/openrouter/free) due to OpenRouter model normalization.

OpenClaw version

2026.3.24 and 2026.3.28

Operating system

Windows 11 host + WSL2 Ubuntu on the affected machine

Install method

npm global

Model

openrouter:free

Provider / routing chain

openclaw -> openrouter

Additional provider/model setup details

Observed with configured agent models and cron usage.

Concrete OpenRouter free refs such as openrouter/meta-llama/llama-3.3-70b-instruct:free can resolve successfully, so this appears specific to the shorthand/compatibility path for openrouter:free.

I also tested a draft source-level compatibility-alias approach on an upstream clone via repo-local tsx execution:

• openrouter:free -> { provider: "openrouter", model: "meta-llama/llama-3.3-70b-instruct:free" }
• openrouter:auto -> { provider: "openrouter", model: "auto" }

That suggests explicit OpenRouter compatibility alias handling is viable, while generic colon parsing is not.

Logs, screenshots, and evidence

Observed warning from `openclaw models status --agent probe-openrouter-free` on 2026.3.28:

[model-selection] Model "openrouter:free" specified without provider. Falling back to "anthropic/openrouter:free". Please use "anthropic/openrouter:free" in your config.

Effective model:
Default (agent): anthropic/openrouter:free (from openrouter:free)

Runtime failure previously observed:
FailoverError: Unknown model: anthropic/openrouter:free

Additional source-level evidence:
- `resolveConfiguredModelRef()` currently treats refs without `/` as providerless unless they match an alias.
- OpenRouter normalization currently does:
  if (provider === "openrouter") return model.includes("/") ? model : `openrouter/${model}`;
- That means a naive generic parse of `openrouter:free` as `{ provider: "openrouter", model: "free" }` leads toward invalid refs like `openrouter/openrouter/free`.

Impact and severity

Affected: users configuring agent models or cron jobs with openrouter:free
Severity: Medium to High (breaks model resolution for that shorthand and can block scheduled jobs)
Frequency: consistently observed on tested versions 2026.3.24 and 2026.3.28
Consequence: model resolution fails, jobs can error before completion, and users may incorrectly think OpenRouter auth/connectivity is broken

Additional information

This appears to be a regression/compatibility gap rather than a generic OpenRouter outage.

Observed:

• stable 2026.3.24: openrouter:free -> anthropic/openrouter:free
• stable 2026.3.28: same behavior

A related improvement opportunity is explicit compatibility handling for:

• openrouter:free
• openrouter:auto

Suggested direction:

• openrouter:free -> resolve to the first configured concrete openrouter/...:free model
• openrouter:auto -> resolve to canonical openrouter/auto

This would avoid both:

• anthropic/openrouter:free
• openrouter/openrouter/free