This isn't about picking your first model. If you're new to OpenClaw and still deciding between providers, our guide on choosing an LLM for OpenClaw is the right place to start. This post is for teams already past that: your agent is live, it's got weeks or months of conversation history behind it, it's answering customers on WhatsApp or routing requests in Slack, and now you want to change which model is running it. Maybe the provider you picked raised prices, maybe a newer model shipped, maybe you just want to test something faster. Whatever the reason, the question isn't "which model" anymore. It's "how do I change this without the agent going dark for even five minutes."
The good news: switching models on a running OpenClaw agent doesn't touch your memory, your workflows, or your channel connections. Those live separately from the model setting. The risk isn't in the switch itself, it's in the order you do things. Get the sequence right and this is a low-drama change you can make on a Tuesday afternoon without anyone noticing except your invoice.
Why teams switch models after going live
Nobody sets up OpenClaw expecting to touch the model choice again. Then reality happens.
Pricing changes. Providers adjust their rates, sometimes up, sometimes down, and a model that made sense at launch might not be the best value six months later. For a Dubai SME running an agent on WhatsApp all day, the difference between providers at scale shows up clearly in AED on the monthly bill.
New models ship. Providers push out new releases fast, and a model that came out after you set up might genuinely outperform what you're running, on speed, on reasoning, on cost, or all three.
Reliability becomes a factor. Every provider has occasional rough patches, rate limits, slower response times, brief outages. A business depending on its agent to answer customers in real time doesn't want to sit through that if there's a reasonable alternative.
And sometimes it's simpler than any of that: you want to try a model everyone's talking about and see if it's better for your use case. That's a fine reason on its own, as long as you test before you commit.
None of these are emergencies most of the time. That's exactly why it's worth doing the switch properly instead of rushing it.
The config file underneath it all
OpenClaw's configuration lives at `~/.openclaw/openclaw.json` (some setups use `~/.config/openclaw/openclaw.json5` instead). The setting that controls which model your agent uses is `agents.defaults.model.primary`, and it holds a simple `provider/model` string, something like `anthropic/claude-sonnet` or `openai/gpt-4`. That one line is what your agent reads to decide who's answering.
Separately, `models.providers` is a map where every provider you've authenticated gets registered, keyed by its provider ID. This is the part that makes safe switching possible: you're not limited to one provider at a time. You can have two, three, or more providers configured side by side, each with its credentials already in place, and simply change which one is marked default. You don't need to re-enter API keys or reauthorize anything when you switch again.
We go deeper into the shape of this file, including the other settings that live alongside the model config, in OpenClaw's config file, explained. Worth a read if you want the full picture of what else is in there.
The safe sequence: register, test, then flip
Here's the mistake to avoid: editing `agents.defaults.model.primary` straight to a new provider before that provider is authenticated and working. If the new provider isn't set up correctly, and your agent's next message comes in on WhatsApp two minutes later, it can't respond. That's the actual downtime risk in all of this, and it has nothing to do with OpenClaw being fragile. It's just doing things in the wrong order.
The safe sequence is three steps, always in this order.
First, register the new provider without touching the default. Get its credentials into `models.providers` and confirm OpenClaw can authenticate with it. Your agent keeps running on the current model the entire time this is happening, because you haven't changed the default yet.
Second, test the new provider before it's live. Send it a few real prompts, the kind your agent handles day to day: a customer question, a routing decision, whatever your workflows normally look like. Confirm the responses are what you'd expect. This is the step people skip when they're in a hurry, and it's the one that catches problems (wrong model name, missing permission, unexpected response format) before a real customer sees them.
Third, only then flip the default. Once you're confident the new provider works, update `agents.defaults.model.primary` to point at it. Your agent's memory, conversation history, and connected channels don't move. You're changing who answers the phone, not the phone number itself.
Skip step one or two and you're editing the config live against an unverified provider, which is precisely the scenario that causes a gap in service. Do it in order and there's no gap at all.
The commands
OpenClaw gives you two commands for this, and which one you reach for depends on whether the new provider is already registered.
If you're switching to a provider you've used before, one that's already sitting in `models.providers` from an earlier setup, use:
```
openclaw models set <provider/model>
```
This switches the default model directly to whatever you specify, no re-authentication needed, since the credentials are already on file.
If you're moving to a provider you haven't authenticated yet, use:
```
openclaw models auth login --provider <id> --set-default
```
This handles both steps in one move: it authenticates the new provider and sets it as the default the moment authentication succeeds. It's convenient, but it also means you're skipping the separate "test before default" window described above. If you use this command, do your testing immediately after, and be ready to switch back fast if something's off (more on that below).
For most production switches, we'd lean toward registering and testing the provider first with whatever authentication step it needs, confirming it behaves, and then using `openclaw models set` to flip the default only once you're satisfied. That keeps the test window clearly separate from the live switch.
What to verify after switching
Don't consider the switch done the moment the command returns successfully. Check three things.
First, have a real conversation with the agent. Not a health check, an actual message like the ones your customers send. Confirm the response quality, tone, and speed look right.
Second, check every channel that's connected. If your OpenClaw agent talks over WhatsApp, Telegram, Slack, or some combination of those, send a test message through each one. The model switch happens at the agent level, but it's worth confirming nothing about the channel connections shifted unexpectedly, since that's the part your customers touch.
Third, watch it for the first hour or so of real traffic, not just your test messages. Response times, tone consistency, whether it's handling edge cases the way the old model did. Some differences between models only show up under real, varied use, not in a handful of manual tests.
If all three check out, you're done. If something feels off, you've got a fast way back.
Rollback: switching back is just as fast
This is the part that should take the anxiety out of trying a new model: because your old provider is still sitting in `models.providers`, rolling back doesn't mean starting over. It's the same command, pointed the other way.
```
openclaw models set <old-provider/old-model>
```
Your previous provider's credentials never left the config. You didn't deregister anything when you switched, so reverting is a one-line change, not a rebuild. You don't re-authenticate, you don't wait, and you don't lose any history. If the new model underperforms, feels slower, handles your Arabic-English mix worse, whatever the issue, you can be back on the old setup in under a minute.
That's really the whole point of registering providers before flipping the default rather than replacing one with another. You're not choosing between "old model" and "new model" and burning the bridge behind you. You're keeping both on file and deciding, with real evidence, which one stays default. It's the same low-risk, test-before-you-commit approach we build into every OpenClaw setup we deploy. It's also why we keep a human checkpoint in place for moments like this: a quiet config change can otherwise turn into a customer-facing problem if nobody's watching.
Frequently asked questions
Will switching models on OpenClaw affect my agent's memory or conversation history?
No. Conversation history and memory are stored separately from the model setting. Changing `agents.defaults.model.primary` changes which model generates the next response; it doesn't touch what the agent already remembers or the workflows built around it.
Do I need to remove my old provider when I switch to a new one?
No, and we'd recommend against it. Leaving the old provider registered in `models.providers` means you can roll back instantly with `openclaw models set` if the new model doesn't work out, instead of having to re-authenticate from scratch.
How long does a model switch take?
The command itself runs in seconds. The part worth spending real time on is testing the new provider before you flip the default, plus a short monitoring window afterward. Done properly, the whole process is usually well under an hour and involves zero downtime for your customers.
What if I'm not confident making this change myself?
That's fair, especially on an agent that's already live and handling real customer conversations. Our OpenClaw setup service covers model switches for teams already running OpenClaw in production, registering and testing the new provider properly before anything goes live, so there's no gap in service. Email us at team@ins.ae or message us on WhatsApp at +971 58 995 4553 and we'll handle the switch for you.
