Getting billing errors even after trying to use different models.

[lavish drift]

Hosted on VPS.

Keep getting this message in telegram

⚠️ API provider returned a billing error — your API key has run out of credits or has an insufficient balance. Check your provider's billing dashboard and top up or switch to a different API key.

I ran openclaw models status --json and see a bunch of models under unusable profiles.

[floral kernel]

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

[lavish drift]

"unusableProfiles": [],
"oauth": {
"warnAfterMs": 86400000,
"profiles": [
{
"profileId": "anthropic:default",
"provider": "anthropic",
"type": "token",
"status": "static",
"source": "store",
"label": "anthropic:default"
},
{
"profileId": "google:default",
"provider": "google",
"type": "api_key",
"status": "static",
"source": "store",
"label": "google:default"
},
{
"profileId": "kimi-coding:default",
"provider": "kimi-coding",
"type": "api_key",
"status": "static",
"source": "store",
"label": "kimi-coding:default"
}
],
"providers": [
{
"provider": "anthropic",
"status": "ok",
"profiles": [
{
"profileId": "anthropic:default",
"provider": "anthropic",
"type": "token",
"status": "static",
"source": "store",
"label": "anthropic:default"
}
]
},
{
"provider": "google",
"status": "static",
"profiles": [
{
"profileId": "google:default",
"provider": "google",
"type": "api_key",
"status": "static",
"source": "store",
"label": "google:default"
}
]
},
{
"provider": "kimi-coding",
"status": "static",
"profiles": [

    {
      "provider": "openai",
      "status": "missing",
      "profiles": []
    },
    {
      "provider": "openrouter",
      "status": "missing",
      "profiles": []
    }
  ]
}

}
}

[short wing]

That auth snapshot basically says:

• ✅ You do have credentials for anthropic, google (Gemini API key), and kimi-coding
• ❌ openai and openrouter are missing (so any openai/* or openrouter/* model—or any fallback that hits them—will fail)

If you’re still getting “billing” errors even after switching models, the two most common causes are:

1. You’re still actually hitting the same provider (session stickiness / fallbacks / alias resolving to a different provider than you think)
2. The provider you are using is returning a real insufficient credits / billing not enabled response, and OpenClaw may temporarily mark that profile as “disabled” after billing failures.

What I need to pinpoint it

Please paste these (they’re designed to be safe to share; tokens are redacted):

openclaw --version
openclaw status --all

openclaw models status --json

And also: paste the exact billing error text you see in chat or the corresponding log lines right after a failed attempt:

openclaw logs --follow
# then send one test message that triggers the error

Quick sanity checks you can do immediately

• Make sure you’re setting a model with an explicit provider prefix (so you don’t accidentally select an alias that routes to openai/* or openrouter/*):
  • use anthropic/... or google/... or kimi-coding/... explicitly
• In openclaw models status --json, look for:
  • auth.unusableProfiles (if anything got disabled due to billing/cooldowns)
  • your resolved primary + fallbacks (if fallbacks include openai/* / openrouter/*, you’ll hit missing creds)

Once you drop openclaw models status --json (full output) + the error line from logs, I can tell you exactly which provider is throwing the billing error and why it’s not switching cleanly.

[lavish drift]

I do see items under unusable profiles. how do i fix that

[short wing]

auth.unusableProfiles means OpenClaw has marked one (or more) of your provider auth profiles as temporarily not-usable, either:

• cooldown (rate limits/timeouts/auth failures) → usually minutes, or
• disabled (billing/insufficient credits) → longer backoff (defaults start around 5 hours, can grow up to 24h).
  Source: /concepts/model-failover in the docs.

1) First: check why each profile is unusable

Run and paste just the unusable section (no secrets in there):

openclaw models status --json

Look at auth.unusableProfiles — each entry should tell you the provider, profileId, reason (often "billing"), and an “until” time.

2) Fix depends on the reason

A) If it’s billing / insufficient credits
You can’t “CLI-fix” that — you have to fix billing on that provider (add credits / enable billing / correct key), then either:

• wait until the disabledUntil time passes (OpenClaw will start trying it again automatically), or
• switch to another provider/profile that’s not disabled.

If you already fixed billing but it’s still disabled for hours, tell me which provider(s) are listed and I’ll suggest the cleanest way to get unstuck without waiting (usually: add a second working profile and set auth order).

B) If it’s cooldown (rate limit / transient errors)

• Wait a few minutes, retry.
• Start a fresh session (/new in chat) so you’re not stuck to a previously “pinned” profile/model.
• Optionally probe live (real requests, may cost tokens):
  openclaw models status --probe

3) Common “why it keeps failing even when I change models”

• You’re changing the model name, but it still resolves to a provider whose only profile is disabled.
• Or your fallbacks eventually land on a disabled provider.

So after fixing unusable profiles, also verify your resolved default + fallbacks with:

openclaw models status

Paste your auth.unusableProfiles block here and I’ll tell you exactly which provider is blocking you and the fastest path to get one working again.

unusableProfiles isn’t something you “enable/disable” manually — it’s OpenClaw remembering “this auth profile recently failed, so don’t keep hammering it”.

There are 2 different cases:

1) Cooldown (rate limit / transient auth errors)

These clear on their own (minutes → ~1 hour). Fix is usually:

• wait a bit, and/or
• start a fresh session (/new) so you’re not pinned to the previously-chosen profile/model.

2) Disabled = billing (insufficient credits / billing not enabled)

This one won’t clear quickly unless billing is actually fixed. OpenClaw uses a longer backoff (hours) for billing failures.

What I need from you (safe to paste)

Please run:

openclaw models status --json

…but only paste the auth.unusableProfiles array (don’t paste the whole file; it can include key/token material depending on version).

It’ll tell us exactly which provider/profile is disabled and until when.

What you can already see from your models status

• Your text models are: kimi-coding + fallbacks to anthropic + google (so a billing-disable on any/all of those will break chat).
• Your image fallback is openai/gpt-5.2 but OpenAI auth is missing, so image generation will fail on fallback unless you either add OpenAI auth or remove that fallback.

“Unstick it now” (only after billing is fixed)

If the provider billing is fixed but OpenClaw is still waiting out a long disabledUntil, you can clear the disabled flag locally:

1. Open:
   ~/.openclaw/agents/main/agent/auth-profiles.json

2. Under usageStats, find the entry for that profileId and remove:

• disabledUntil
• disabledReason
  (and optionally cooldownUntil / reset errorCount)

3. Restart:

openclaw gateway restart

But paste auth.unusableProfiles first — then I’ll tell you which provider is actually causing the billing-disable and what to fix on that provider side.

[lavish drift]

"lastGood": {
"google": "google:default",
"anthropic": "anthropic:default",
"kimi-coding": "kimi-coding:default"
},
"usageStats": {
"google:default": {
"lastUsed": 1770811269209,
"errorCount": 0
},
"anthropic:default": {
"errorCount": 2,
"lastFailureAt": 1770809207950,
"lastUsed": 1770797527224,
"failureCounts": {
"rate_limit": 2
},
"cooldownUntil": 1770809507950
},
"kimi-coding:default": {
"lastUsed": 1770811805053,
"errorCount": 0
}
}
}

"unusableProfiles": [],
"oauth": {
"warnAfterMs": 86400000,
"profiles": [
{
"profileId": "anthropic:default",
"provider": "anthropic",
"type": "token",
"status": "static",
"source": "store",
"label": "anthropic:default"
},
{
"profileId": "google:default",
"provider": "google",
"type": "api_key",
"status": "static",
"source": "store",
"label": "google:default"
},
{
"profileId": "kimi-coding:default",
"provider": "kimi-coding",
"type": "api_key",
"status": "static",
"source": "store",
"label": "kimi-coding:default"
}
],

[short wing]

From what you pasted, nothing is “billing-disabled” right now — the only “unusable” state shown is:

• anthropic:default hit rate_limit twice
• it was put into cooldown until 2026-02-11T11:31:47Z (cooldownUntil: 1770809507950)

That timestamp is already in the past (your other providers were used at 12:01Z and 12:10Z), so Anthropic should be considered usable again now.

What to do

1. Re-check unusableProfiles now (it may already be empty):

openclaw models status --json

2. If replies are still “stuck” failing because the session pinned a bad attempt, do:

• in chat: /new (forces a fresh run and repicks provider/model), or
• restart the gateway:

openclaw gateway restart

3. If you’re still seeing an actual billing/credits error, it’s coming from a different provider than this snippet indicates. Grab the exact provider + error line:

openclaw logs --follow
# send one test message that triggers the error

…and paste the error lines. (Don’t paste full auth output again; even truncated keys are risky in public.)

Optional: prove Anthropic is healthy (live probe)

This makes a real request:

openclaw models status --probe --probe-provider anthropic

If you paste the current auth.unusableProfiles array (not the whole file), I can tell you precisely which provider/profile is being skipped and why.

Nice — with "unusableProfiles": [] you’re no longer blocked by cooldown/disabled profiles. So the “billing” error you’re seeing now is almost certainly a real provider response (insufficient credits / billing not enabled / quota) coming back from whichever model actually handled the request.

Next step: identify which provider is throwing “billing”

Fastest way:

1. Tail logs:

openclaw logs --follow

2. Send one test message that triggers the billing error.

3. Paste just the error lines that mention the provider / HTTP status (redact any keys).

Alternative (live probes, real requests):

openclaw models status --probe --probe-provider kimi-coding
openclaw models status --probe --probe-provider anthropic
openclaw models status --probe --probe-provider google

That will usually make it obvious which one is returning billing/quota errors.

One more gotcha in your config (unrelated to billing, but will break images)

Your models status showed:

• Image fallbacks (1): openai/gpt-5.2
• and OpenAI auth is missing

So any image request that falls back to OpenAI will fail. If you don’t plan to add OpenAI auth, clear that image fallback:

openclaw models image-fallbacks clear

(or set an image model you do have, e.g. Google).

Important security note

You posted partial API keys/tokens earlier (Anthropic/Google/Kimi/OpenRouter). Assume they’re compromised and rotate them on the provider dashboards, then re-add via OpenClaw.

If you paste the log error lines, I’ll tell you exactly which provider account needs credits/billing enabled (and which model path is being selected).

[lavish drift]

12:14:41 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
12:14:41 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=3 queueSize=0
12:14:41 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
12:14:41 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=1 queueSize=0
12:14:41 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=redacted sessionId=redacted provider=kimi-coding model=k2p5 thinking=low messageChannel=telegram
12:14:41 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=760b89ad-7fb8-45c0-a740-054ad45f29cb sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
12:14:41 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=redacted totalActive=1
12:14:41 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=redacted sessionId=redacted
12:14:41 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=redacted
12:14:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=redacted
12:14:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=redacted sessionId=redacted durationMs=8498
12:14:49 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=redacted sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
12:14:49 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=redacted totalActive=0
12:14:49 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=redacted sessionId=redacted durationMs=8625 aborted=false

OAuth/token status

• anthropic
  • anthropic:default static

Auth probes
┌──────────────────────────┬───────────────────────────┬────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────────┼───────────────────────────┼────────────────────────────────────────┤
│ anthropic/claude-opus-4- │ anthropic:default (token) │ unknown · 8.2s │
│ 6 │ │ ↳ LLM request timed out. │
└──────────────────────────┴───────────────────────────┴────────────────────────────────────────┘
Probed 1 target in 8.4s

Anthropic probe failed

[short wing]

That output is not a billing failure — it’s a plain network timeout on the Anthropic probe:

unknown · 8.2s ↳ LLM request timed out.

Two likely reasons:

1. The probe timeout is just too low for your network (8s is tight), or
2. The gateway host can’t reliably reach Anthropic (DNS/firewall/ISP/region issues).

Try the same probe with a bigger timeout

openclaw models status --probe --probe-provider anthropic --probe-timeout 30000

Also probe Google/Kimi to compare:

openclaw models status --probe --probe-provider google --probe-timeout 30000
openclaw models status --probe --probe-provider kimi-coding --probe-timeout 30000

• If Google/Kimi succeed but Anthropic still times out → it’s Anthropic connectivity from that machine/network.
• If all providers time out → gateway host networking is the issue.

Get the real “billing error” culprit

Since unusableProfiles is now empty, the only way to know why you still see “billing” is the actual error line from logs (it will name the provider and often show HTTP status like 402/429):

openclaw logs --follow
# then send one message that triggers the billing error

Paste just the few error lines around it (redact tokens). That’ll tell us whether it’s Kimi, Google, Anthropic, or an OpenRouter model path.

One important thing

You already posted partial keys earlier — rotate those keys/tokens (Anthropic / Google / Kimi / OpenRouter) and re-add them. Even truncated keys are not safe in public Discord logs.

[lavish drift]

13:09:21 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=4463 active=0 queued=0
13:09:21 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=4466 active=0 queued=0

[short wing]

Those lines:

debug diagnostic ... lane task done ...

are just “queue lane finished” diagnostics — they don’t include the actual provider error. To debug the billing issue we need the error/warn lines right when the request fails (they’ll say which provider/model and usually an HTTP code like 402/429).

Do this:

1. Start a live tail:

openclaw logs --follow

2. Send one test message that triggers the “billing” error.

3. Copy/paste the first block of lines that includes error / warn (usually 10–30 lines around it). Redact any secrets.

If your log stream is super noisy, an easier “pasteable” bundle is:

OPENCLAW_SHOW_SECRETS=0 openclaw status --all

Also: please don’t paste any more key/token previews in Discord — rotate the Anthropic/Google/Kimi/OpenRouter creds you already posted.