Claude CLI Auth displaying 'Out of usage'

[slim lintel]

Hi Krill,

**Environment: ** Hostinger Debian, Openclaw 2026.5.12

I've recently updated to 2026.5.12 and since the update I'm getting the following error message when sending messages: LLM error invalid_request_error: You're out of extra usage. Add more at claude.ai/settings/usage and keep going

I'm setup on the claude CLI auth which is confirmed as working and live and I am nowhere near the limits so not sure why this is happening.

I have tried logging out of the claude CLI and logging back in to reset the token but still the same.

[zenith path]

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

[slim harbor]

This looks like Anthropic Extra Usage billing, not a stale Claude CLI token. I checked current docs/source: OpenClaw classifies You're out of extra usage as a billing/extra-usage error, and the related docs call out long-context/1M context as the common trigger.

Things to check on the VPS:

openclaw --version
openclaw models status
openclaw config get agents.defaults.model
openclaw config get agents.defaults.models
openclaw logs --follow

In the logs/config, look for either:

• params.context1m: true on an Anthropic Opus/Sonnet model
• an Opus 4.7 Claude CLI route, which docs say has a 1M context window by default
• a long existing session/thread causing the request to cross into the long-context path

[slim harbor]

Fastest workaround: switch that agent/session to a non-1M Anthropic setup or disable context1m for the configured model, then restart the gateway and start a fresh session/thread. If you want predictable always-on VPS behavior, an Anthropic API key is usually less surprising than Claude CLI subscription auth.

Docs:
https://docs.openclaw.ai/gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context
https://docs.openclaw.ai/providers/anthropic
https://docs.openclaw.ai/help/faq

If those commands show no context1m and no 1M/long-context model route, paste the redacted openclaw status --all plus the nearby log lines and this is probably worth a GitHub issue: https://github.com/openclaw/openclaw/issues

[slim lintel]

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-opus-4-7
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : opus -> anthropic/claude-opus-4-7, sonnet -> anthropic/claude-sonnet-4-6
Configured models (6): anthropic/claude-opus-4-7, anthropic/claude-sonnet-4-6, anthropic/claude-opus-4-6, anthropic/claude-opus-4-5, anthropic/claude-sonnet-4-5, anthropic/claude-haiku-4-5

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): anthropic (1), claude-cli (1)

• anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | anthropic:claude-cli=OAuth [disabled:billing 4h]
• claude-cli effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | anthropic:claude-cli=OAuth [disabled:billing 4h] | synthetic=plugin-owned | source=Claude CLI native auth

OAuth/token status

• claude-cli
  • anthropic:claude-cli expiring expires in 7h

[slim harbor]

That status output pretty much confirms the failure path.

Key bits:

• Default: anthropic/claude-opus-4-7
• Fallbacks (0)
• anthropic:claude-cli=OAuth [disabled:billing 4h]

So OpenClaw saw Anthropic return a billing/extra-usage shaped error and disabled that Claude CLI OAuth profile for a billing backoff window. Because there are no fallbacks, there’s nowhere else for the run to go.

The likely trigger is Opus 4.7: current docs say that route has a 1M context window by default, and Anthropic can route that through Extra Usage instead of normal Claude subscription quota.

Practical fix:

openclaw config set agents.defaults.model "anthropic/claude-sonnet-4-6"
openclaw models fallbacks add anthropic/claude-haiku-4-5

[slim harbor]

openclaw gateway restart

Then start a fresh thread/session and try again. The existing profile may still show disabled:billing until the backoff expires, but moving away from the Opus 4.7 long-context route should avoid immediately retriggering it.

Also worth refreshing before the token expires:

claude auth login
openclaw models status

Docs for the behavior:
https://docs.openclaw.ai/providers/anthropic
https://docs.openclaw.ai/concepts/model-failover

[slim lintel]

Why is there a backoff though?

[slim harbor]

The backoff is OpenClaw-side, not Anthropic saying “try again in exactly 4h”.

When a provider returns something that looks like real billing/credit failure, OpenClaw marks that auth profile as temporarily unusable so it doesn’t keep hammering the same failing credential on every message. That also lets model/auth failover move on cleanly if you have another profile or fallback configured.

For billing-shaped errors the default backoff starts around 5h and caps higher; yours shows disabled:billing 4h because some of that window has already elapsed. The source matcher includes out of extra usage, so that exact Anthropic message put the Claude CLI OAuth profile into the billing lane.

Important nuance: this is protective state. It doesn’t mean your Claude account token is broken, and it doesn’t prove your normal Claude subscription quota is exhausted. It means the request path OpenClaw used triggered Anthropic’s Extra Usage billing response, so OpenClaw paused that profile rather than retrying it repeatedly.

Docs: https://docs.openclaw.ai/concepts/model-failover

[slim lintel]

What could have triggered openclaw to mark it as temporarily unusable then

[slim harbor]

Most likely: one agent turn using that Claude CLI OAuth profile got this provider response:

You're out of extra usage. Add more at claude.ai/settings/usage and keep going

OpenClaw has a billing-error matcher for phrases like out of extra usage / extra usage is required. When it sees that, it records the profile as disabled:billing for a backoff window.

What could have produced that response:

• A normal message in a long existing session/thread, especially if the context had grown large
• Using anthropic/claude-opus-4-7, which docs say has a 1M context route by default
• A heartbeat, cron, follow-up, or background session using the same default model/profile
• A media/PDF/image pre-processing or tool-heavy run that pushed the request into a larger context path
• A retry after the update where the migrated/default model became Opus 4.7 with no fallback

The quickest way to identify the exact trigger is to search the logs around the first billing disable:

[slim harbor]

openclaw logs --follow
# or inspect recent logs for:
# out of extra usage
# disabled:billing
# claude-opus-4-7
# context1m

If the timestamp lines show it happened during a heartbeat/background task rather than your visible Discord message, that explains why it felt like it came out of nowhere.

[slim lintel]

I havent been anywhere near my limits though at any point, thats why i'm confused

[slim harbor]

Yeah, that confusion is valid. The key distinction is that this probably isn’t your normal Claude plan limit.

Anthropic has separate buckets/paths here:

• normal Claude subscription usage
• Claude CLI/OAuth auth token validity
• Extra Usage / long-context billing path

Your status says the OAuth token is still valid, and you may be nowhere near normal Claude usage limits. But the specific error text says Anthropic routed that request into the Extra Usage path and found no Extra Usage balance/eligibility for it.

The suspicious part in your config is anthropic/claude-opus-4-7. Current docs say Opus 4.7 has a 1M context window by default. If OpenClaw sends a request that qualifies for that long-context route, Anthropic can require Extra Usage even when your regular Claude usage looks fine.

So I’d treat this as: “the selected request path is wrong/surprising for your account,” not “you used up Claude.” Switching the default to Sonnet/Haiku or an Anthropic API key path should confirm it quickly. If Sonnet still throws the same exact Extra Usage message on a fresh session, that’s much stronger evidence of a 2026.5.12 regression or Anthropic-side routing change, and I’d file it with the status output + log excerpt: https://github.com/openclaw/openclaw/issues

[slim lintel]

How can i update the default model to sonnet

[slim harbor]

Use the config helper, then restart the gateway:

openclaw config set agents.defaults.model "anthropic/claude-sonnet-4-6"
openclaw gateway restart
openclaw models status

After restart, openclaw models status should show:

Default : anthropic/claude-sonnet-4-6

Then start a fresh Discord thread/session to test, because an existing session can still have route/session state hanging around.

If you also want a fallback so one Anthropic failure doesn’t hard-stop replies:

[slim harbor]

openclaw models fallbacks add anthropic/claude-haiku-4-5
openclaw gateway restart

Docs: https://docs.openclaw.ai/concepts/models

[slim lintel]

I'm still getting issues with claude so i set a fallback to openai, I completed the auth but now I get this: ⚠️ Agent failed before reply: Requested agent harness "codex" is not registered.

[slim harbor]

That error is harness selection, not OpenAI auth itself.

OpenClaw is being told to use the codex embedded harness, but the bundled Codex plugin did not register. Most likely one of these is true:

• config or env has agents.defaults.embeddedHarness.runtime: "codex" / OPENCLAW_AGENT_RUNTIME=codex
• but plugins.entries.codex.enabled is missing/false
• or you use plugins.allow and it does not include codex

First, can you paste:

openclaw --version
openclaw status --all

If you just want normal OpenAI API fallback, don’t force the Codex harness. Use an openai/... model fallback and leave embeddedHarness.runtime as auto or pi.

[slim harbor]

If you specifically want the native Codex harness, the config needs the plugin enabled, roughly:

{
  plugins: {
    entries: {
      codex: { enabled: true }
    }
  },
  agents: {
    defaults: {
      embeddedHarness: {
        runtime: "codex",
        fallback: "none"
      }
    }

[slim harbor]

  }
}

And if your config has plugins.allow, add "codex" there too. After changing harness settings, restart the gateway and start a fresh session with /new or /reset, because harness choice is pinned per session.

Docs:
https://docs.openclaw.ai/plugins/codex-harness
https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultsembeddedharness

[slim lintel]

How do i enable the harness then

[slim harbor]

Add/merge this into your OpenClaw config, usually ~/.openclaw/openclaw.json:

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
      embeddedHarness: {
        runtime: "codex",

[slim harbor]

        fallback: "none",
      },
    },
  },
}

If you already have plugins.allow, make sure codex is included too:

plugins: {
  allow: ["codex"],
  entries: {
    codex: { enabled: true },
  },

[slim harbor]

}

Then restart the gateway and start a fresh session:

openclaw gateway restart

In Discord, run /new or /reset after the restart. Harness selection is pinned per session, so existing sessions may keep using the old runner.

Also make sure the Codex CLI/app-server is installed and recent enough:

codex --version