Your fallback is not broken. Scheduled jobs now stay on one account, on purpose. Here is what still works and how to get a backup back.
| What you see | What it means | Do this |
|---|---|---|
Automation candidate is incompatible with its recorded inference account and route. | A scheduled job tried a fallback on another provider | Same-provider fallbacks, or a twin job on the other provider |
Automation has no recorded inference account. Explicitly select its account with a model@profile update before running it. | An older job has no saved account | Update to 2026.11.2, run openclaw doctor --fix |
Chat stops falling back after you picked a model with /model | A model you picked yourself is strict | Pick the agent default again |
Picture this. Your 6am inbox digest runs on Claude, with an OpenAI model as the fallback for exactly the morning you get rate limited. That morning comes, and the run log says Automation candidate is incompatible with its recorded inference account and route.
I set a fallback for this. Why did it not fall back?
Because since 2026.10.10, that job is not allowed to. We checked the release notes, the docs, GitHub and the 2026.11.2 source on 10 November 2026.
What changed in 2026.10.10, and where it is documented
The change came from PR #172590 on GitHub, merged on 15 October and shipped in 2026.10.10, which reached npm on 3 November. The release note reads: "Keep the selected model account on a new isolated job and report when its access is no longer valid."
The cron docs explain the rule under "Inference account continuity". New isolated agent-turn jobs privately keep the stored account and auth route they were created with. Changing your interactive defaults, your profile order or the job's plain model choice no longer moves that job to another account or billing route.
The fallback part is one sentence in the same section: "An account refusal ends the run; it never falls back to another model or provider." In the 2026.11.2 package, the check compares the fallback candidate's provider ID with the job's recorded provider. A different provider is refused.
This is an account rule, not a fallback bug. OpenClaw decided a scheduled job should never quietly bill a different account at 3am.
It is a sound security default, and a nasty surprise if you used cross-provider fallback as uptime insurance. For everything else that landed in 2026.10.10, 2026.11.1 and 2026.11.2, see our OpenClaw latest version guide.
Why your OpenClaw fallback model is not working: chat vs scheduled jobs
The new rule only covers scheduled automations, so start with where the failure happened.
| Where it runs | Fallback to another provider | Fallback on the same provider |
|---|---|---|
| Chat on the agent's default model | Works | Works |
Chat after you picked a model with /model | No fallback (older strict rule) | No fallback |
| Scheduled job with a recorded account | Refused since 2026.10.10 | Works, same account |
| Older job with no recorded account | Stops with "no recorded inference account" | Stops until an account is recorded |
| Scheduled job on a key from env or provider config | Works only if the fallback also uses such a key | Works |
The second row predates 2026.10.10. Per the model failover docs, a model you pick with /model is strict when it differs from the configured primary, so pick the agent's configured primary again and its fallback chain comes back.
The third row is the one hurting most people. On issue #192009, a second user reported that the upgrade disabled cross-provider fallback on 44 jobs at once, and that binding each job's account also pinned its model.
Running Hermes Agent next to OpenClaw? Its fallback fails for a different reason, and our decoder entry on Hermes fallback not triggering on Codex covers that one.
How to configure fallback correctly now
The agent default chain lives in config, and each scheduled job can override it from the CLI. Here is the default chain, trimmed from the example on the docs' agent model configuration page:
{
agents: {
defaults: {
model: {
primary: "anthropic/claude-opus-4-6",
fallbacks: ["minimax/MiniMax-M2.7"],
},
},
},
}
Notice that the docs' own example crosses providers. That is fine for chat, but a scheduled job bound to the Anthropic account will refuse the MiniMax step.
For scheduled jobs, do it in this order:
- Check what you have with
openclaw models status, which shows the resolved default and fallbacks plus an auth overview. - On older jobs, run
openclaw doctor --lintto preview missing account bindings, thenopenclaw doctor --fix(2026.11.2) to record them. - To pick an account yourself, edit the job with a model and profile.
- Give the job fallbacks that stay on that provider.
- Use an empty list for a strict run, or clear the override to follow config again.
openclaw automations edit <job-id> --model "openai/gpt-4.1@work"
openclaw automations edit <job-id> --fallbacks openai/<model-a>,openai/<model-b>
openclaw automations edit <job-id> --fallbacks ""
openclaw automations edit <job-id> --clear-fallbacks
Prefer Doctor over a manual --model edit when you can. The docs say Doctor keeps inherited defaults and fallback lists, while a --model edit also sets the job's primary model, so it stops following agents.defaults.model.primary.
Using several accounts on one provider? Set auth.order first, so Doctor records the account every earlier run used instead of picking one.
Not sure which job should get which model? Our OpenClaw model routing guide walks through a cheaper model for routine checks and a stronger one for real work.
Three workarounds when the OpenClaw fallback model is not working
Same-provider fallback covers a busy model, not a provider outage or a rate-limited account. If you need a second vendor, you have three options.
Retries still happen. The cron docs say a recurring job that fails backs off for 30 seconds, 1 minute, 5 minutes, 15 minutes and then 60 minutes, resetting after the next success. By default a failure alert fires after 2 consecutive failures, if the job has a failure route or announce target.
1. A twin automation on the other provider
Create a second copy of the job, bound to the other provider's account, and disable it. When the failure alert for the main job lands, run the twin with openclaw automations run <twin-job-id>. The docs say a manual run is forced and leaves the job's cadence as it was, but check the twin is still disabled afterwards.
This is our default pick: every account is chosen on purpose. If a duplicate run costs you nothing, such as a status check, just schedule both.
2. A router such as OpenRouter in front
Put the job on OpenRouter as its only provider. Every model then sits under one provider ID, openrouter/..., so fallbacks between them pass the check (our reading of the 2026.11.2 source). OpenRouter's provider routing docs add a second layer: allow_fallbacks defaults to true, so it can move a request to another host of the same model.
The cost is a credit fee, one more company seeing your prompts, and one more service that can go down. Our breakdown of OpenRouter fees versus direct API keys shows when that trade is worth it.
3. Stay on 2026.10.9, with the risks
You can pin it with npm install -g openclaw@2026.10.9, but only as a short bridge. You give up the 2026.11.1 and 2026.11.2 patches, both with security and privacy fixes, and the rule is still there on main.
There is a trap too: an older binary refuses config written by a newer OpenClaw, with a message saying the binary "is older than the config last written by OpenClaw", followed by the newer version number. So roll back by restoring the backup you took before updating, not by reinstalling over the new state.
Tired of keeping account bindings straight job by job? Each BetterClaw agent runs on the model you choose, with your own key from any of 28+ providers at zero markup, and you can set a primary model and a fallback for when one is busy. Plans start from $19 a month, and your first workspace starts with a 7-day free trial. See BetterClaw plans
The open feature request, and whether fallback comes back
The request is issue #192009 on GitHub: "Feature: Explicitly authorize cross-provider cron fallback accounts". It was opened on 3 November and is still open, labelled P2 and waiting on a product decision.
The automated review on the issue says main has no per-fallback account authorization, which looks intentional, and that it needs a maintainer decision first. A regression report, #192463, was closed as its duplicate, and #193855 asks for jobs to follow their agent's account instead.
So will fallback come back? Not the old silent kind. Our bet: if anything ships, it will be an opt-in where you approve each fallback account.
On the Claude CLI runtime, issue #191818 reports "no recorded inference account" even after a model@profile edit. The 2026.11.2 notes include a fix for scheduled CLI runs not using their recorded account, so update first.
A fallback you never approved was never a plan
Before 2026.10.10, your backup worked because OpenClaw would spend from whatever account it could reach. That felt like resilience. It was a blank cheque.
Write down, for each scheduled job, which account pays for it and what happens when that account is down. If the honest answer is "it fails and I get an alert", give the job a twin.
Frequently Asked Questions
Why is my OpenClaw fallback not working?
In a scheduled automation it is by design since 2026.10.10: a job stays on its recorded inference account, so a fallback on another provider is refused. In chat, check whether you picked the model yourself with /model, because a user-picked model is strict.
Does OpenClaw support fallback across providers?
In chat, yes, through agents.defaults.model.fallbacks. In scheduled jobs with a recorded account, no: the 2026.11.2 check refuses any candidate whose provider differs from the job's recorded provider. A twin job on the other provider, or a router used as one provider, are the workarounds.
How do I set a fallback model in OpenClaw?
Set agents.defaults.model.primary and agents.defaults.model.fallbacks in your config, or use openclaw models fallbacks add. For one scheduled job, use openclaw automations edit with --fallbacks and a comma-separated list. On a job with a recorded account, keep that list on the same provider.
Will fallback come back?
Not the old automatic kind. Feature request #192009 asks for explicitly authorized cross-provider fallback accounts and is open, waiting on a product decision. If it ships, expect an opt-in where you approve each fallback account.
What does "Automation has no recorded inference account" mean?
Usually the job was created before OpenClaw recorded accounts for scheduled jobs, so it has no saved account. On 2026.11.2, run openclaw doctor --lint to see affected jobs and openclaw doctor --fix to record an eligible account. You can also pick one yourself with a model@profile edit.
Should I roll back to OpenClaw 2026.10.9?
Only as a short bridge. You lose the 2026.11.1 and 2026.11.2 security and privacy fixes, and an older binary refuses config written by a newer version, so restore your pre-update backup.
