Claude CLI works directly, but OpenClaw returns an API billing error

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 normally use Claude CLI credentials with OpenClaw, but today OpenClaw reports an API billing or insufficient-balance error. My Claude subscription login appears valid.

2

First distinguish a Claude subscription route from a direct Anthropic API-key route. Check for an ANTHROPIC_API_KEY environment override, confirm the Claude CLI login, and record the exact error and CLI version. Do not post credentials or organization details.

3

Enabling paid overflow makes OpenClaw work, even though the visible utilization meter is not full. Claude Code itself works on the same model without overflow. The failure only happens through OpenClaw.

4

That changes the diagnosis, but the model prefix alone does not prove which billing path OpenClaw is using. On OpenClaw 2026.9.3, anthropic/... is the canonical model reference for both direct Anthropic API execution and models delegated to Claude CLI through an agentRuntime mapping. Legacy claude-cli/... references still work for compatibility. Update OpenClaw, then inspect the configured model, runtime mapping, and auth state without probing:

openclaw --version
openclaw models status
openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.models --json
5

The default is a claude-cli model and native CLI auth is listed, but the status also shows direct Anthropic fallbacks and older stored credentials.

6

Temporarily clear only the fallbacks that the configuration confirms use direct API-key execution. Start a fresh session pinned to an Anthropic model whose agentRuntime.id is claude-cli, then capture one sanitized live error. The important distinction is an actual 401 from the CLI subprocess versus a 429 or extra-usage response. Do not top up a direct API credential until the active runtime and auth path are proven.

7

A direct noninteractive claude -p call succeeds under the same account, but OpenClaw logs show provider=claude-cli returning HTTP 401. I cleared the stale OpenClaw profiles and restarted, yet OpenClaw still reports the API error.

8

The remaining possibilities are a different Gateway process or configuration, or an OpenClaw CLI-backend credential-handoff bug. Confirm the active Gateway version and config path with openclaw status --all, then compare one isolated local run:

openclaw agent --local --agent main --message "ping"

If direct claude -p succeeds while the isolated OpenClaw CLI backend still returns 401, preserve the sanitized version, route, and error lines for an OpenClaw issue.