All OpenRouter models showing "Unknown model" after config edit — gateway won't resolve any models

[lavish loom]

Running OpenClaw 2026.4.21 on WSL2 Ubuntu 24.04.

All OpenRouter models suddenly showing "Unknown model: meta-llama/llama-3.1-8b-instruct:free" — every model in my fallback chain fails with model_not_found. Was working fine this morning.

What I did before it broke:

• Removed openai/gpt-4.1-mini from agents.defaults.model.fallbacks
• Removed openai from models.providers
• Disabled openai plugin
• Restored openclaw.json from backup and re-added openai provider — still broken
• Ran openclaw doctor --fix (moved legacy tools.web.search to plugins.entries.searxng)
• Cleared sessions.json — still broken
• Restored models.json from git — still broken

Error from journalctl:
All models failed (5): meta-llama/llama-3.1-8b-instruct🆓 Unknown model (model_not_found) | google/gemma-3n-e4b-it🆓 Unknown model (model_not_found) | meta-llama/llama-3.3-70b-instruct🆓 Unknown model (model_not_found) | meta-llama/llama-3.1-8b-instruct: Unknown model (model_not_found) | deepseek/deepseek-v4-flash: No API key found for provider "deepseek"

OpenRouter API is up — curl confirms models exist. Config has the models defined in models.providers.openrouter with correct API key. tools.profile is "full". openrouter plugin enabled.

Any ideas what's corrupted?

[agile coral]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[pearl sable]

This probably isn’t corrupted state — the log strongly suggests OpenClaw is resolving those as non-OpenRouter model refs.

OpenRouter refs need the extra provider prefix:

agents: {
  defaults: {
    model: {
      primary: "openrouter/meta-llama/llama-3.1-8b-instruct:free",
      fallbacks: [
        "openrouter/google/gemma-3n-e4b-it:free",
        "openrouter/meta-llama/llama-3.3-70b-instruct",
        "openrouter/deepseek/deepseek-v4-flash",
      ],
    },
  },

}

The giveaway is this part:

deepseek/deepseek-v4-flash: No API key found for provider "deepseek"

If it were going through OpenRouter, the provider would be openrouter and the model id would be deepseek/deepseek-v4-flash. Right now it’s trying the direct deepseek provider.

Also check for a stale session/user override from /model: if a session override is meta-llama/... instead of openrouter/meta-llama/..., configured fallbacks may not behave how you expect. Try /model status, then select/set an openrouter/... model explicitly.

Docs confirm the expected shape: https://docs.openclaw.ai/providers/openrouter

[lavish loom]

this is from claude, i want deepseek 4 flash and claude says deepseek chat is the same. is it?

Follow up — got the openrouter/ prefix fix working, thanks. Free models are resolving now but hitting 429 rate limits tonight. Agent is falling through the chain but NOT reaching deepseek/deepseek-chat (direct API) which was added as the last fallback. DeepSeek provider is configured with baseUrl, apiKey, and model ID "deepseek-chat". Fallback chain is now: openrouter/meta-llama/llama-3.1-8b-instruct:free, openrouter/google/gemma-3n-e4b-it:free, openrouter/meta-llama/llama-3.3-70b-instruct:free, openrouter/meta-llama/llama-3.1-8b-instruct, openrouter/deepseek/deepseek-v4-flash, deepseek/deepseek-chat. Agent gets stuck at the 429s and never reaches the direct DeepSeek fallback. Is the deepseek provider ID correct for direct API, or does it need a different prefix? Gateway was restarted after changes.

[pearl sable]

No — deepseek-chat is not the same as DeepSeek V4 Flash in OpenClaw’s catalog.

Direct DeepSeek provider ID is correct: deepseek.

But the direct model you want is:

deepseek/deepseek-v4-flash

not:

deepseek/deepseek-chat

Docs/catalog currently list:

• deepseek/deepseek-v4-flash = DeepSeek V4 Flash, V4 thinking-capable
• deepseek/deepseek-v4-pro = DeepSeek V4 Pro
• deepseek/deepseek-chat = DeepSeek V3.2 non-thinking surface
• deepseek/deepseek-reasoner = V3.2 reasoning surface

So I’d change the end of the chain to:

"openrouter/deepseek/deepseek-v4-flash",
"deepseek/deepseek-v4-flash"

For the 429/fallback behavior: 429s should be failover-worthy, but OpenClaw may wait on provider/SDK retry-after/cooldown handling before moving on. If it appears stuck, check whether the log eventually emits All models failed (...) or a cooldown message. Also check you’re not in a session with a user /model override, because user-selected session models are strict; run /model status or start /new after changing the config.

DeepSeek docs: https://docs.openclaw.ai/providers/deepseek
Failover behavior: https://docs.openclaw.ai/concepts/model-failover

[lavish loom]

Follow up — logs show agent is stuck cycling on OpenRouter free models and never reaching deepseek/deepseek-v4-flash (direct) at the end of the chain. Here's what's happening:

1. openrouter/meta-llama/llama-3.1-8b-instruct:free — fails (not shown but skipped)
2. openrouter/google/gemma-3n-e4b-it:free — 404 "No endpoints found"
3. openrouter/meta-llama/llama-3.3-70b-instruct:free — HTTP 402, then timeout, then repeated 429s

After step 3 it just keeps retrying 429 on the same model every 60 seconds. Never emits "All models failed", never moves to openrouter/meta-llama/llama-3.1-8b-instruct (paid) or deepseek/deepseek-v4-flash (direct).

Fallback chain: openrouter/meta-llama/llama-3.1-8b-instruct:free, openrouter/google/gemma-3n-e4b-it:free, openrouter/meta-llama/llama-3.3-70b-instruct:free, openrouter/meta-llama/llama-3.1-8b-instruct, openrouter/deepseek/deepseek-v4-flash, deepseek/deepseek-v4-flash

Is 429 not treated as failover-worthy? Or is there a retry loop that keeps trying the same model instead of advancing down the chain?

[pearl sable]

429 is failover-worthy, but there’s a catch: it only becomes failover-worthy after the provider SDK/transport gives the error back to OpenClaw.

What you’re describing — retrying the same OpenRouter model every ~60s — looks like OpenRouter is returning a Retry-After: 60, and the OpenAI-compatible SDK is honoring that retry instead of surfacing the 429 to OpenClaw’s model-fallback layer.

OpenClaw has a guard for “long retry-after” responses, but the default cap is 60s. So if OpenRouter says exactly 60s, it may still be considered retryable rather than terminal/failover-worthy.

Try setting this for the Gateway process:

OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=10

or even:

OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS=1