1 API minimax
2 API kimi k2.5
3 API GPT Codex
4 locall ollama
Today all api are giving me errors that they out of creditis.
Ive realised that something happened few days ago and all of them must been running through fall back model (haiku)
I have credits on Moonshot, Minimax, OpenAI and misteriously below zero on anthropic so Openclaw must been running all chats and crons through fall back model last few days without me noticing.
anyone has idea what happened and how to fix it?
#Hey, I have 4 agents
1 messages · Page 1 of 1 (latest)
Yep — this smells like failover + auth-order/env drift, not “all providers suddenly broke.”
What likely happened:
- your main provider creds became unavailable (or excluded by auth order),
- OpenClaw fell through to Anthropic fallback,
- fallback stayed “sticky” in active sessions / cron runs,
- Anthropic burned down first.
First, paste this so we can confirm quickly:
openclaw --version
openclaw models status --probe
openclaw models fallbacks list
openclaw models auth order get --provider anthropic
Then quick mitigation (to stop burning Anthropic right now):
- Remove Anthropic from fallbacks (copy exact model id from
fallbacks list). - Set your intended primary again:
openclaw models set <provider/model>
- In active chats, reset session model state with
/new(or/model <provider/model>).
Also check this common root cause after restarts: service lost shell env keys.
If your keys are only in shell rc files, move them to ~/.openclaw/.env and restart gateway.
Useful docs:
If you paste those command outputs, I can tell you exactly which profile/order/fallback is causing it.
OpenClaw 2026.4.5 (3e72c03)
Perfect, thanks — 2026.4.5 is recent, so this is probably config/auth state, not an ancient version bug.
Can you run this exact bundle and paste it?
openclaw models status --probe
openclaw models fallbacks list
openclaw models auth order get --provider anthropic
openclaw models auth order get --provider openai
openclaw models auth order get --provider openai-codex
openclaw models auth order get --provider minimax
openclaw models auth order get --provider moonshot
Quick “stop burning Anthropic” temporary fix
(you can do this now)
openclaw models fallbacks list
# remove the Anthropic fallback model(s) shown above:
openclaw models fallbacks remove <exact-anthropic-fallback-id>
Then set your intended primary again:
openclaw models set <provider/model>
And restart + reset active thread/session model state:
openclaw gateway restart
In chat, send /new once (or /model <provider/model>).
Most common root cause I see: non-Anthropic creds weren’t being loaded by the daemon (service env drift), so fallback took over. If that’s the case, move keys to ~/.openclaw/.env.
Refs:
On AWS ec2 server....and it's just ripppping through cpu after most recent update; any thoughts? Still at 114%. That's the gateway itself just running — not cron related. This is the baseline cost of the OpenClaw
gateway process with 4 channels (Discord, Slack, Telegram, WhatsApp), 10 plugins, and 20 agents loaded.
On a 2-core machine, that's roughly 57% of one core which is high but may be the floor for this setup. The difference
from before is that it's stable at this level instead of spiraling to 200%+ with failed auth cascades.
Yeah, 114% idle is higher than expected — especially if no runs/cron are active.
With 4 channels + 10 plugins + 20 agents on 2 vCPU, you’re close to saturation already, but this still sounds like a retry/index loop on top.
Fast triage (copy/paste):
openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw doctor
openclaw logs --follow
What to look for in logs:
- repeated auth/reconnect errors (Discord/Slack/Telegram/WhatsApp),
- repeated provider auth failures/fallback churn,
- repeated
qmd/memory index update activity.