Claude Code 5-hour rate limits doubled. The weekly cap is the new wall.

What Anthropic actually said

The post is short and concrete. Three numbers, one capacity announcement. We are reading it next to the live usage endpoint, not next to the marketing copy, so the framing below maps every claim to a specific bucket in the JSON payload that drives enforcement.

The wedge in one sentence

Doubling the 5-hour bucket shifts where the wall lands. The weekly bucket is the wall most heavy users actually hit by mid-week. That bucket did not move.

For users whose only constraint was the 5-hour cap, the announcement is pure relief. For users running Claude Code in agentic loops, the binding cap has been seven_day_opus since early 2026. Doubling 5-hour does not relieve that bucket; it just changes the order in which the two walls arrive. Mid-session walls turn into mid-week walls.

Same JSON, two snapshots

The endpoint GET /api/organizations/{org_uuid}/usage did not change shape. The numbers shifted in exactly one field. Here is the same workload reading before and after the retune.

Same prompts, same day of the week, same Opus model. five_hour.utilization went from 0.84 to 0.42. The two weekly fractions are unchanged. The next 429 will fire on whichever bucket fills first; with 5-hour halved, that is now seven_day_opus.

One struct, all four buckets

ClaudeMeter deserializes the entire payload into a strict Rust struct in src/models.rs. The May 6 retune did not require a code change because the shape did not change. Only the value in five_hour.utilization reads lower for the same workload.

One Opus prompt, four buckets ticked

Each completion increments the 5-hour bucket and the two weekly buckets. Doubling the 5-hour bucket lowers its utilization for the same prompt count; the weekly buckets tick at exactly the same rate.

Reproduce it yourself in one curl

You do not need a tool to verify the doubling landed. Open DevTools on claude.ai/settings/usage, copy your cookie header from the Network panel, and call the endpoint directly:

Same payload as the Settings page. The 5-hour bar will read materially lower than it did a week ago for the same workload; the weekly bars will read the same.

What the Twitter thread called early

The doubling landed at noon Pacific on May 6. By 2pm, the consensus take was “more headroom, problem solved”. Two hours of reads against the live endpoint said otherwise. The thread that called the wedge in real time:

Plan the new week, in four steps

Pre-May 6 vs post-May 6, every lever

Side-by-side reading of which fields moved and which did not. The columns are the same JSON shape pre and post-announcement.

What feeds the bucket the announcement did not touch

Common myths to drop

What a real-time tracker shows now

Why local jsonl estimators drift further now

ccusage and similar tools read raw token counts from ~/.claude/projects/*.jsonl. Pre-May 6, those token counts were closest to the 5-hour bucket because both were dominated by the most recent few hours of activity. Post-May 6, the 5-hour bucket has twice the headroom, so a JSONL reading of “78 percent” is much further from the actual five_hour.utilization on the server. Meanwhile the bucket that does 429 you (weekly) was never well-correlated with token JSONL because token JSONL ignores attachment cost, peak-hour multiplier, browser-chat usage, and model class weighting.

This is not a knock on JSONL tools. They are great for per-project attribution (“which repo did I burn 50 percent of my Opus on?”), and they are the only way to see your token spend offline. They are not a faithful proxy for the bucket the rate limiter actually checks. Post-May 6 they are even less so.

The capacity context

Anthropic packaged the limit changes with three capacity announcements. SpaceX’s Colossus 1 will provide over 300 MW of new capacity within a month, roughly 220,000 NVIDIA GPUs. Amazon’s previously announced ~1 GW deal lands by end of 2026. Google capacity comes online in 2027. The link between capacity and limits is straightforward: the 5-hour cap was previously dimensioned around peak-hour GPU availability. With more peak-hour GPUs, peak-hour penalties can be removed and the 5-hour ceiling can rise without increasing the risk of plan oversubscription.

The weekly cap is a fairness lever, not a capacity lever. It exists to keep heavy users from monopolizing GPUs at the expense of light users on the same plan tier. More GPUs do not directly relax that constraint, which is why the weekly bucket is conspicuously absent from the announcement. The watch item over the next quarter: whether the weekly cap also gets a relaxation, or whether Anthropic keeps it as a per-account fairness mechanism even with surplus capacity.

Plan-by-plan impact

• Claude Pro ($20): 5-hour window twice as tall, peak-hours penalty gone on Claude Code. seven_day and seven_day_opus unchanged. If you were hitting five_hour before, big relief. If you were hitting weekly, unchanged.
• Claude Max ($100/$200): same retune. The Max users posting “rate-limited at hour 4 on a $200 plan” should see materially better mid-day sessions. The Max users posting “78 percent weekly by Tuesday” will not see a difference.
• Claude Team and Enterprise (seat): also doubled on the 5-hour bucket. Per-seat rate limit math now favors interactive bursts more than before.
• Anthropic API (Opus): higher rate limits across tiers, separate from the consumer plan caps. Programmatic Opus customers get more throughput headroom; the announcement cites “substantially higher”. Specific tier numbers are in Anthropic’s rate limit documentation.

The honest caveats

The endpoint on claude.ai/api/organizations/{org}/usage is internal and undocumented. The field names have been stable for many months, but Anthropic could rename, add, or remove buckets in any release. ClaudeMeter handles that with strict deserialization and ships patches the same day a shape change is detected.

The exact “doubled” multiplier is not formally published as a precise integer for every plan. The announcement says “doubling Claude Code’s five-hour rate limits”. Reads on real accounts post-May 6 are consistent with a roughly 2.0x multiplier on five_hour.utilization for the same workload, so we use the announcement’s wording as the source of truth. Significant deviations should surface as parse drift in the struct, not silent miscalibration.