Anthropic Gives Claude API Builders 5x More Room to Scale

Anthropic just pushed a meaningful quality-of-life update to the Claude Platform API: rate limits are going up across the board, and the tier system has been redesigned from the ground up. The two changes together remove one of the most common friction points for teams building production systems on Claude.

Out with spend-based tiers

The old system tied your rate limit tier to how much you had spent on the API. That created a frustrating catch-22: you needed higher limits to scale, but you needed to scale to earn higher limits. Limits are now defined by usage tier, and your organization moves to a higher tier automatically over time as you use the API rather than based on cumulative spend. If you need to jump ahead, the standard limits apply for each tier, and you can request higher limits directly by clicking Request rate limit increase in the Claude Console.

The tier structure itself has also been simplified. Rate limits are set at the organization level and depend on your usage tier. There are three usage tiers: Start, Build, and Scale, with a separate Custom tier for accounts whose limits are managed with their account team.

5x more headroom for Sonnet and Haiku

The headline number is a 5x increase in rate limits for the latest Sonnet and Haiku models at the highest standard tier. This follows an earlier wave of increases in May that focused on Opus models. Tier 1 input tokens per minute jumped from 30,000 to 500,000 in that earlier round. Tier 2 moved from 450K to 2M, Tier 3 from 800K to 5M, and Tier 4 from 2M to 10M.

The broader context matters here. Dario Amodei explained the root cause at Anthropic's developer event: Anthropic planned for 10x growth per year, but saw 80x annualized growth in Q1 2026. The infrastructure simply wasn't built for that trajectory. The compute deals that followed -- including a full takeover of SpaceX's Colossus 1 data center, giving Anthropic access to more than 300 megawatts of new capacity (over 220,000 NVIDIA GPUs) -- are what's making these increases possible. More rate limit increases are likely as that compute comes online.

One limit pool across all model sizes

Perhaps the most developer-friendly change in this update is that Opus, Sonnet, and Haiku now share the same RPM and token throughput limits within each tier. Previously, choosing a cheaper model often meant accepting tighter rate limits, which forced awkward trade-offs in system design. Now you can pick the right model for each task without worrying that the choice will crater your throughput budget.

Rate limits are applied separately for each model, so you can use different models up to their respective limits simultaneously. That means a multi-agent pipeline routing tasks across Haiku, Sonnet, and Opus draws from three independent pools, not one shared bucket.

What this unlocks in practice

The practical impact depends on what you were building before. A few use cases that were previously impractical become straightforward:

• Large-context pipelines: At the old input token limits, sending a 1M token context meant consuming your entire per-minute budget in a single request. At 500K/min on Tier 1 and 10M/min on Tier 4, large-context workflows become much more usable.
• Parallel agent systems: If you were running parallel agents and hitting output ceilings constantly, that wall just moved significantly.
• Abandoned Opus pipelines: If you tried building an Opus-based pipeline and gave up because you kept hitting limits, the constraint may genuinely be gone -- worth a direct retest rather than assuming the old experience still applies.

What to check in your codebase

If you have existing retry logic built around the old limits, it's worth auditing. Search your codebase for 429 handling, rate limit error catches, and any hardcoded delays. You now have significantly more headroom before hitting those paths.

One thing worth noting: for most Claude models, only uncached input tokens count towards your ITPM rate limits. This is a key advantage that makes the rate limits effectively higher than they might initially appear. Pairing prompt caching with the new higher limits is the fastest way to maximize effective throughput. For all models without the cache exception marker, cached input tokens do not count towards rate limits and are billed at a reduced rate (10% of base input token price), meaning you can achieve significantly higher effective throughput by using prompt caching.

The changes are live now and apply automatically to all existing API users. You can check your current tier and limits under Settings > Limits in the Claude Console, or read them programmatically via the Rate Limits API.