Anthropic models stuck in billing cooldown even with Console credits

Troubleshooting
, , ,
1

Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from September 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

I am on macOS and all of my Anthropic models started failing this morning with a billing cooldown. openclaw models auth list shows my anthropic:manual profile as disabled:billing, but my Anthropic Console still shows available API credits.

Is that a real Anthropic billing problem, or stale OpenClaw state? I would also like a supported way to test or clear it without deleting the existing auth profile.

2

disabled:billing is OpenClaw’s local circuit-breaker state for that credential profile. It is not a live reading of your Anthropic Console balance. A Claude subscription or setup token and an Anthropic Console API key can use different billing surfaces, so one can be blocked while the other still has credit.

Start with one targeted live probe:

openclaw models status --probe \
  --probe-provider anthropic \
  --probe-profile anthropic:manual \
  --probe-max-tokens 1 \
  --json

The probe makes a real provider request and may consume a small amount of quota. If the manual token remains blocked, add a normal Anthropic Console inference API key as a separate profile and test it independently:

openclaw models auth paste-api-key \
  --provider anthropic \
  --profile-id anthropic:console

openclaw models status --probe \
  --probe-provider anthropic \
  --probe-profile anthropic:console \
  --probe-max-tokens 1 \
  --json

If that profile succeeds, put it first in the provider’s auth order:

openclaw models auth order set \
  --provider anthropic \
  anthropic:console anthropic:manual

Paste the key only into OpenClaw’s protected terminal prompt. Use an inference API key, not an Admin API key. Keep tokens, account identifiers, and unredacted provider responses private.

3

Thanks, that distinction helps. I am going to try the targeted probe first. I have not deleted the existing profile or edited anything manually.

4

Sounds good. Start with a single targeted probe. If you share the result, the HTTP status and profile name are enough. Redact credentials, headers, organization details, and raw provider responses.

5

Fixed. Adding my Anthropic Console API key as anthropic:console solved it immediately. The probe returned HTTP 200 and OpenClaw is working again.

6

That confirms the Console API-key route is healthy and isolates the failure to the original token’s billing or usage surface. Keeping the credentials as separate profiles also gives the router a real fallback.

7

One extra check for anyone seeing the same thing: confirm the exact credential profile, organization, and project OpenClaw is using. A successful probe with the second Console profile points to the original credential path, not the Anthropic model IDs.

8

Exactly. The working anthropic:console probe is the important evidence. Put that profile first when you want predictable API billing, and keep a separate provider fallback if continuity matters.

For related failures, an HTTP 401 usually points to authentication or access, while an HTTP 429 usually points to quota, rate limiting, or provider capacity. That is a different diagnosis from OpenClaw’s local disabled:billing state.

Current references: model authentication and model failover.