[BUG] claude -p rejected with "out of extra usage" while Max plan 5h limit shows 35% remaining (not the HERMES.md trigger)

Preflight

• [x] Searched existing issues — closest match is #45203 (still open). Filing fresh because my reproduction adds clearer evidence and rules out the #53262 HERMES.md trigger.
• [x] Single bug report
• [x] On latest Claude Code version (2.1.132)

What's Wrong

claude -p rejects every invocation with You're out of extra usage · resets 6:40pm (America/New_York) even though my Max plan's 5-hour limit shows 35% remaining in the Claude Desktop usage panel at the same instant.

Claude Desktop on the same account, same model, same minute, accepts requests fine.

This makes claude -p (and any tool that wraps it — opcode/claudia, claudecodeui, my own tooling) unusable while my plan is supposedly healthy.

What Should Happen

Per Use Claude Code with your Pro or Max plan:

"Both Pro and Max plans offer usage limits that are shared across Claude and Claude Code, meaning all activity in both tools counts against the same usage limits."

So claude -p requests should consume my remaining plan quota first, not reject against an empty extra-usage pool.

Error Output

$ claude -p --output-format stream-json --verbose --model claude-opus-4-7 "say hi"
{"type":"rate_limit_event","rate_limit_info":{"status":"rejected","resetsAt":1778193600,"rateLimitType":"five_hour","overageStatus":"rejected","overageDisabledReason":"out_of_credits","isUsingOverage":false}, ...}
{"type":"assistant","message":{"model":"<synthetic>","content":[{"type":"text","text":"You're out of extra usage · resets 6:40pm (America/New_York)"}]},"error":"rate_limit","isApiErrorMessage":true,"apiErrorStatus":429, ...}
{"type":"result","subtype":"success","is_error":true,"api_error_status":429,"duration_ms":400, ...}

Note rateLimitType: "five_hour" — same bucket Claude Desktop is currently serving requests from for me. The rejection is from the overage path (overageStatus: rejected, overageDisabledReason: out_of_credits), implying the request was routed to extra-usage instead of plan quota.

Steps to Reproduce

Tested at 4:28 PM EDT on May 7, 2026 (US/Eastern):

1. Open Claude Desktop → usage panel shows: 5-hour limit 65% used (resets in ~1h), weekly all models 4%, weekly Claude Design 0%, Sonnet only 0%. Confirms Max plan is healthy.
2. From any cwd, including ~:

``bash
claude -p --model claude-opus-4-7 "say hi"
``

1. Returns You're out of extra usage · resets 6:40pm (America/New_York) and exits non-zero (apiErrorStatus 429).

Every subsequent claude -p invocation fails identically. Claude Desktop chats continue working in parallel on the same account, same model.

Workarounds Attempted

• Reinstall to latest: curl -fsSL https://claude.ai/install.sh | bash completed; claude --version still 2.1.132 (already on latest); bug persists.
• Different model: tested --model claude-opus-4-7 and --model claude-opus-4-7[1m] — same rejection.
• Not the HERMES.md trigger from #53262: verified via git log --all --format=%s | grep -i hermes across every repo under ~/Developer — zero matches. Bug also reproduces from ~ with no git context at all.
• No ANTHROPIC_API_KEY env var set (ruled out the API-key override path from siteboon/claudecodeui#568).

Environment

• Claude Code: 2.1.132 (latest)
• OS: macOS 15 (Darwin 24.6.0, Apple Silicon)
• Plan: Max (OAuth subscription auth; no API key set anywhere)
• Models tested: claude-opus-4-7, claude-opus-4-7[1m]
• Extra usage credits balance: $0 (never enabled / topped up — plan should cover all usage)

Regression?

I don't know. I haven't used claude -p heavily before today, but the symptom is identical to reports going back to January 2026 (#17263, #17694, #18446 — all closed not_planned). Looks like long-standing billing-routing rather than a fresh regression.

Related Issues

| Issue | State | Note |
|---|---|---|
| #45203 | open | Closest match — Max plan billed against extra usage despite quota remaining. Last activity Apr 22, no Anthropic engineering response. |
| #45095 | open | Same symptom at 0% normal usage. |
| #53262 | closed: completed (today) | HERMES.md commit-message trigger fix. My case is not this trigger but is the same bug class. |
| #52467 | closed: not_planned | Desktop vs CLI extra-usage asymmetry. |
| #17263, #17694, #18446 | all closed: not_planned (Jan–Feb 2026) | Same symptom, closed without fix. |

Why This Matters

The rejection message gives the user zero indication that this is a routing issue rather than an actual cap. A non-engineer hitting this would assume they're genuinely out of credits, top up the extra-usage pool out of pocket (paying for the bug), and never realize their Max plan should have covered it. That's the same dynamic that cost the #53262 reporter $200 silently before they isolated the trigger.

What Would Help

1. Confirm whether the recent fix for #53262 was scoped only to the HERMES.md content trigger or addressed the underlying billing-routing logic.
2. Include actual plan-quota status in the rejection response so users can distinguish "you really hit your cap" from "your plan has room but routing misfired."
3. If CLI invocations are billed to extra-usage by design (despite the docs), update the Pro/Max docs — they currently say the opposite.

Happy to provide stream-json transcripts, additional repro variations, or test specific scenarios. Thanks for taking a look.