How to Set Primary and Fallback Models in OpenClaw with OpenRouter (2026)

If you’re running OpenClaw with OpenRouter, one of the first things you’ll want to sort out is which model your agent actually uses — and what happens when that model isn’t available. The config lives in openclaw.json, and OpenClaw handles this with a clean primary/fallback model system. It’s not immediately obvious where to look or how to confirm it’s working, though.

This post covers exactly that.

Why Bother With a Fallback?

Your primary model is your first choice — the one that best fits your use case in terms of speed, capability, and cost. But AI providers aren’t perfectly reliable. Models get rate-limited, providers have outages, and sometimes a specific model is simply unavailable at a particular moment.

Without a fallback, that means your agent fails. With a fallback (or several), OpenClaw automatically routes to the next model in line and keeps going. It’s a small config change that meaningfully improves reliability.

Where the Config Lives

Everything lives in openclaw.json, the main config file for OpenClaw. Inside the agents.defaults.model section, you set two things:

• primary — the model you want to use by default
• fallbacks — an ordered list of models to try if the primary isn’t available

Here’s the relevant structure, using my current setup as a real example:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openrouter/qwen/qwen3-coder-next",
        "fallbacks": [
          "openrouter/xiaomi/mimo-v2-flash",
          "openrouter/any_model_you_want"
        ]
      }
    }
  }
}

I’m using Qwen3 Coder as my primary — it’s currently the cheapest model I could find that can handle the general agentic workflow well enough — with Mimo v2 Flash as a lightweight fallback. The model strings follow OpenRouter’s format: openrouter/<provider>/<model-name>. You can find the exact slugs on the OpenRouter models page.

You can add multiple fallbacks — just extend the array. OpenClaw will work through them in order.

Verifying It Worked

After saving your changes, navigate to the /agents route in the OpenClaw web UI. You should see the Primary Model listed correctly, along with the number of fallbacks configured. That’s your confirmation the config was picked up.

You can also check via the TUI. Run openclaw tui and you’ll see the primary model displayed in the interface — note that the TUI doesn’t currently show fallbacks, but if the primary is correct you’re good.

Troubleshooting: Config Changes Not Showing Up

This tripped me up initially. Sometimes editing openclaw.json doesn’t immediately reflect in the UI or TUI — the agent just keeps using the old model. The fix is to restart the OpenClaw gateway:

openclaw gateway restart

That forces a full config reload. Once it’s back up, check the /agents route in the web UI again and the updated primary model should be listed.

One handy shortcut: if you’re already in an active agent session, you can just ask your OpenClaw agent to restart the gateway and it’ll do it for you. Surprisingly useful when you’re mid-session and don’t want to jump to the terminal.

A Few Tips

Use different providers for your fallbacks. If your primary and fallback are both on the same provider and that provider goes down, you’re back to failing. Spreading across providers (e.g. Anthropic as primary, OpenAI as first fallback, xAI as second) gives you much better coverage.

Keep fallbacks lightweight. Your fallback is a safety net, not your primary workhorse. A fast, cheap model that can handle most tasks is usually a better fallback than another frontier model — you’re optimising for availability, not raw capability.

That’s all there is to it. Once you understand that the config lives in openclaw.json under agents.defaults.model, the rest is just filling in model slugs.