The Claude 5-hour server-side wall is three walls, not one

It is the moment a rolling 5-hour utilization float on the claude.ai server crosses the bucket ceiling and the rate limiter starts returning 429 to your org. The field that trips it is five_hour.utilization on GET /api/organizations/{org_uuid}/usage. The wall lives on the server, not in the client. ClaudeMeter polls that endpoint every 60 seconds so you see the float move in real time instead of guessing from a local token count.

Sometimes. Overage lives on a different endpoint: /api/organizations/{org_uuid}/overage_spend_limit. That response has three fields that can block you: is_enabled (master switch), out_of_credits (monthly cap hit), and disabled_until (a wall-clock timestamp when overage is suspended, independent of the other two). If any one of those blocks, the 5-hour wall is hard again. The /usage endpoint does not mirror these flags, which is why the Settings page can look healthy while your next prompt 429s.

It is an ISO 8601 timestamp on the overage_spend_limit response. While Utc::now() is less than disabled_until, the server refuses overage spend even if is_enabled is true and you are under the monthly credit limit. We see it populated after payment failures and during manual Trust & Safety holds. ClaudeMeter reads it at src/models.rs line 37 and the CLI appends an 'until Fri Apr 26' suffix when it is set (format.rs lines 35 to 38).

Because the server returns the same generic message whether the 5-hour quota pinned, the overage hit its monthly cap, or the overage is suspended by disabled_until. Only the JSON from the three usage endpoints distinguishes them. A client that reads just /usage sees five_hour at 100 percent and assumes quota. A client that reads /usage plus /overage_spend_limit can tell you which layer is actually walling you off.

Two reasons. First, the 5-hour window is a rolling boundary, not a fixed timer, so each new message you attempt pushes the earliest-unexpired-message pointer forward and resets_at slides with it. Second, if your overage is off, on out_of_credits, or suspended via disabled_until, the 5-hour reset does not unlock you because the 5-hour bucket was never the binding constraint, the overage layer was. Both layers have to clear.

No. Those tools read ~/.claude/projects/**/*.jsonl and estimate token spend from local Claude Code sessions. They do not call /api/organizations/{org}/usage, they do not call /api/organizations/{org}/overage_spend_limit, and they cannot see the server-weighted utilization float the rate limiter checks. They answer a different question (what Claude Code burned locally) from the one the wall answers (what the server is counting against your org).

It is a boolean on the overage response. See src/models.rs line 39, `#[serde(default)] pub out_of_credits: bool,`. When the monthly credit pool is exhausted, the server sets it to true and starts 429ing overage requests. The CLI shows it as 'BLOCKED' next to the extra-usage line (format.rs line 26).

GET /api/organizations/{org_uuid}/usage returns the 5-hour and weekly buckets. GET /api/organizations/{org_uuid}/overage_spend_limit returns overage state including out_of_credits and disabled_until. GET /api/organizations/{org_uuid}/subscription_details returns payment method and next charge date, useful for guessing why disabled_until got populated. Pass your logged-in claude.ai Cookie header to each.

Because the full wall state is not on /usage. See api.rs lines 16 to 60: three serial calls, each with its own error handling, each producing one field on the UsageSnapshot struct. Dropping any one of them produces a snapshot that can say '5-hour at 42 percent' while the next prompt still 429s.

The 5-hour layer slides continuously; resets_at is whichever oldest-message-ageing-out event is next. The weekly buckets roll at a fixed time per account, usually when the week ticks over in your billing zone. The overage layer resets at the billing cycle boundary (see subscription_details.next_charge_date), not at 5 hours. So 'when does my wall lift' depends on which layer is binding right now.

The same shape, different ceiling. The five_hour.utilization field is identical, weighted more generously on Max, and the wall still trips at utilization >= 1.0. Max plans also populate seven_day_opus and seven_day_sonnet more often, so you can wall on a narrower model-specific bucket while the headline 5-hour is fine. ClaudeMeter surfaces each bucket that exists on your org without needing plan detection.