[BUG] Fable 5 on Max: "You've hit your monthly spend limit" despite Unlimited spend limit and meters at 5% session / 41% weekly

Adding a sanitized related signal because this is another case where Claude usage-credit controls and user-visible billing state appear to disagree.

Your report is about Claude Code rejecting requests for a monthly spend limit even while the usage page shows the spend limit as Unlimited and other meters are not exhausted. My direct case is a different usage-credit surface: manual prepaid / bulk Claude usage-credit purchases fail or fail to commit, while automatic usage-credit reloads on the same paid billing setup continue charging successfully.

The overlap is the important part: usage-credit purchase/commit state, auto-reload charging, spend-limit/account controls, entitlement/model access gates, and the visible credit ledger can diverge in ways that the customer cannot resolve with ordinary card troubleshooting or local restarts. When the UI says Unlimited but the API path says monthly spend limit, or when auto-topups work but manual prepaid purchase fails, this needs Billing Platform / payment-operations / entitlement reconciliation rather than generic support scripts.

Requested triage path: please route this class of issues to a human owner who can inspect usage-credit ledger state, model-access flags, spend-limit evaluation, auto-reload triggers, manual purchase/commit state, and the exact API error rendered at request time.

Privacy-sanitized public evidence hub for my related case:
https://coolak.github.io/anthropic-claude-billing-incident/

I am intentionally not posting card details, bank names, payment IDs, invoice IDs, support IDs, screenshots, raw logs, or private support-thread text here.

Additional public owner map / reconciliation matrix:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html

Same failure in a non-interactive / CI context, with the raw error payload — which I don't think any report here has yet.

Environment

• anthropics/claude-code-action in GitHub Actions (not interactive Claude Code)
• Auth: claude_code_oauth_token from a Max 20x seat
• claude_args: --model fable --fallback-model opus
• Reproduced identically on v1.0.186 and v1.0.191 — not action-version specific

Account state at time of failure

| | |
|---|---|
| Fable | 100% used, resets Sunday |
| All models | 84% used, resets Sunday |
| Usage credits | On |
| Monthly spend limit | Unlimited |
| Current balance | $494.42, auto-reload on |
| Credits spent | $201.41 (resets Sep 1) |

Per Fable 5 on your plan — "When you reach your Fable 5 limit, you can keep using Fable 5 with usage credits" — credits should cover this. They don't.

Raw payload (SDK result object):

{
  "type": "rate_limit_event",
  "rate_limit_info": { "rateLimitType": "seven_day_overage_included" },
  "error": "rate_limit",
  "terminal_reason": "api_error",
  "is_error": true,
  "subtype": "success",
  "duration_ms": 587,
  "num_turns": 1,
  "total_cost_usd": 0,
  "result": "You've hit your monthly spend limit. /model to switch models."
}

Note rateLimitType: "seven_day_overage_included" alongside result text naming a monthly spend limit — while the account's monthly spend limit is Unlimited. The session dies on turn 1 at ~590 ms with zero cost, so nothing is billed and no work is attempted.

Not transient here. ~10 runs across 7 hours, 100% failure, identical payload each time. (I see the original report recovered on retry — that isn't the case for us.)

--fallback-model does not engage. With --fallback-model opus set, the session initialises as claude-fable-5 and terminates without attempting the fallback — telemetry reports fallback model used: no. So the documented "switch to another model" remedy has to be applied manually; the configured fallback won't rescue it.

The raw payload @no-flaks-given posted is the tell: "rateLimitType": "seven_day_overage_included". That's a seven-day (rolling weekly) overage limiter, not a monthly spend limit — so the "You've hit your monthly spend limit → claude.ai/settings/usage" chip is pointing at the wrong control. That's why the settings page contradicts it: your monthly spend limit really is Unlimited; the thing rejecting the request is the seven-day overage bucket, which isn't the meter shown on that page.

That also explains why it's intermittent for you specifically. Your ultracode/Workflow runs fan out many concurrent claude-fable-5 requests, so you brush the seven-day overage bucket in bursts at the fan-out boundary — one request gets rejected and, seconds later as the burst clears, the retry lands with no state change. @no-flaks-given's CI case is the saturated end of the same axis: Fable at 100% weekly, so the bucket stays exhausted and the retry can't clear it — even though usage credits + Unlimited spend limit should cover it per the Fable-5-on-your-plan doc.

So there look to be two separable defects in this one thread:

1. Rendering — a seven_day_overage_included rate-limit is shown with monthly-spend-limit copy and a link to a page that reads Unlimited, which makes the state impossible to reason about. Rendering the actual rateLimitType (and pointing at the meter that's actually saturated) would clear the "UI contradicts the error" problem for all three reports here.
2. Entitlement — if usage credits are on and the plan keeps Fable available on credits past the weekly limit, a seven_day_overage_included rejection while balance/credits remain is the substantive bug behind the 100%-weekly case, and that one needs a Billing Platform / entitlement look rather than a copy fix.

Cheap confirmation for anyone else landing here: capture the SDK result object (as @no-flaks-given did) and check rate_limit_info.rateLimitType. If it's seven_day_overage_included, the "monthly spend limit" chip is a misnomer and your monthly limit isn't the blocker.