Claude Max weekly quota tightening: the weekly bucket did not move

No. The seven_day bucket returned by /api/organizations/{org_uuid}/usage has the same utilization curve it had on 2026-03-20. What changed is the five_hour bucket's decay rate on weekdays between 13:00 and 19:00 UTC. Same weekly total, faster 5-hour climb. Anthropic's own communication says overall weekly limits stay the same, just how they're distributed across the week is changing. The endpoint data backs that up.

Because the visible symptom is that heavy weekday users run out earlier in the week than they used to. Readers interpret running out earlier as a weekly squeeze. Mechanically it is a 5-hour squeeze that compounds across the week, but the five_hour bucket is the one carrying the change. The seven_day aggregate stays on its pre-change curve.

Open DevTools on claude.ai/settings/usage during off-peak hours, copy the response JSON of /api/organizations/{org_uuid}/usage, note five_hour.utilization. Send a fixed workload (say 50 Sonnet messages). Record the delta. Repeat the exact same workload starting at 13:10 UTC on a weekday. The delta on five_hour is larger during peak. The delta on seven_day is proportional and unchanged. ClaudeMeter does this every 60 seconds for you, so you see it as a slope rather than two snapshots.

Because they read local Claude Code JSONL logs and count tokens. Tokens per message did not change on 2026-03-26. What changed is how the server weights those tokens into the five_hour bucket during peak hours. The server truth lives only in the JSON response at /api/organizations/{org_uuid}/usage. ClaudeMeter's extension fetches that endpoint with your existing claude.ai cookies.

Once per 60 seconds. The extension runs chrome.alarms.create('refresh', { periodInMinutes: POLL_MINUTES }) with POLL_MINUTES = 1. That cadence is fast enough to capture the moment at 13:00 UTC when the five_hour slope shifts, and slow enough that you are not hammering Anthropic's endpoint.

Not that we have observed. The per-model weekly caps (seven_day_sonnet, seven_day_opus) stay on their usual curves. The tightening lives at the five_hour level. That means a heavy Opus user watching only seven_day_opus will not notice the change; they will only notice it when the 5-hour window hits its ceiling sooner during peak afternoons.

Both. Some buckets come back as 0.94, others as 94.0 in the same payload. ClaudeMeter normalizes with the clamp u <= 1 ? u * 100 : u so you are comparing apples to apples. If you are building your own dashboard on the endpoint, do the same clamp before plotting a slope or you will draw a vertical line in the wrong direction.

No. /api/organizations/{org_uuid}/usage is internal and undocumented. It powers claude.ai/settings/usage. Anthropic can change the field names or remove buckets in any release. ClaudeMeter deserializes into an explicit Rust struct, so a schema change surfaces as a loud error rather than silent corruption. The seven fields named in this article (five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) were stable through 2026-04-24.

The peak-hour multiplier only applies Monday to Friday. On Saturday and Sunday the five_hour slope tracks the same curve as off-peak weekday hours. You can verify this by polling the endpoint on a Sunday afternoon with a fixed workload and comparing against a Tuesday 14:00 UTC sample.

Yes, easily. The rate limiter fires on the first bucket to hit 100. During peak hours the five_hour bucket reaches 100 much sooner than usual. seven_day sitting at 30 percent tells you nothing about the five_hour curve. If you want to avoid surprise cutoffs during weekday afternoons, watch five_hour on a live poller, not seven_day on a snapshot page.