Anthropic raises Claude API rate limits and consolidates tiers into Start, Build, and Scale

Anthropic raised rate limits across the Claude API and consolidated usage tiers into three: Start, Build, and Scale. Anthropic's own release notes date the change to June 26, 2026 and describe it as Claude Sonnet and Claude Haiku rate limits "now match Claude Opus at every usage tier," with most organizations moving to a higher tier and none receiving lower limits than before. (Claude Platform release notes, Claude Platform docs)

Key Takeaways

• Standard tiers are now Start, Build, and Scale, replacing the older numbered usage tiers. A Custom tier is arranged with an account team above Scale.
• Opus 5, Sonnet 5, Sonnet 4.x, and Haiku 4.5 carry identical limits at each tier: 1,000 RPM on Start, 5,000 on Build, 10,000 on Scale.
• Tier placement is automatic and based on usage history and account standing, not on what you spend.
• Each tier still carries a monthly spend cap: $500 on Start, $1,000 on Build, $200,000 on Scale.
• New organizations may start in an Evaluation tier below the published limits, which rises automatically as account history builds.
• For most models, cached input tokens do not count toward your input-token limit, which usually matters more than the tier number.
• Acceleration limits can return a 429 even when you are inside your published limits, if traffic ramps sharply.

Update: What Anthropic's Own Documentation Says (August 12, 2026)

This article originally rested on a single developer post on X, and reported two things from it: that tiers are "no longer based on API spend," and that "the latest Sonnet and Haiku models now provide 5x higher rate limits at the highest tier." Anthropic's release notes and rate limit documentation now carry the same change on durable, first-party pages, and they describe it more precisely than the announcement did. Both were re-read in full for this update; the corrections below come from them.

Three things changed in how this page reports the news:

1. The vendor event is dated June 26, 2026, per Anthropic's release notes. The developer post publicising it is dated July 2. The change shipped first.
2. The mechanism is parity, not a multiplier. Anthropic's release note says Sonnet and Haiku limits "now match Claude Opus at every usage tier." The published tables confirm exactly that. No Anthropic documentation states a "5x" figure, and it is not derivable from tables that show only current state, so this page no longer presents that number as a fact.
3. The tiers now have names. "Simplified the tiers" meant consolidating numbered usage tiers into Start, Build, and Scale. The numbers below are what those names are worth.

The Three Standard Tiers, and What Each Is Worth

Rate limits are set per organization, per model, and measured in three ways at once: requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Exceeding any one of them returns a 429 naming the limit you hit, plus a retry-after header. These are the standard published limits for the Messages API.

Above Scale is the Custom tier, arranged through sales from the Rate limits page in the Console. Below Start is the Evaluation tier: Anthropic's docs say new organizations and those with limited usage history "may start in the Evaluation tier, with limits below the standard limits shown on this page while account history is established," and that those starting limits increase automatically. If you are standing up a new organization, budget for that floor rather than for the Start row.

Two footnotes in the tables matter more than they look:

• Opus 4.x is a shared bucket. The Opus 4.x limit applies to combined traffic across Opus 4.8, 4.7, 4.6, and 4.5. Opus 5 has its own separate limit and is not part of that bucket.
• Sonnet 4.x is a shared bucket across Sonnet 4.6 and 4.5, and Sonnet 5 is separate the same way. Migrating to a Claude Sonnet 5 workload therefore gives you a fresh limit rather than a share of an existing one. (See our Sonnet 5 launch coverage.)

Limits also apply separately per model, so you can run several models up to their respective limits at the same time. They are shared across inference_geo values, though: requests sent with inference_geo: "us" and inference_geo: "global" draw from the same pool.

Spend Caps Still Exist, and That Is Not a Contradiction

The original announcement's "no longer based on API spend" and the documentation's spend-cap table are both accurate, because they describe different things. Placement is no longer earned by spend: Anthropic's docs say organizations "are placed on a tier automatically based on usage history and account standing and can move to a higher tier over time as they use the API." Consumption is still capped: each standard tier carries a maximum monthly API spend.

Once you reach your tier's cap, API usage pauses until the next calendar month unless you request a higher limit. You can also set your own spend limit below the cap on the Billing page in the Console, which is the mechanism most teams actually want for cost control.

Two Limits That Bite Before Your Tier Does

Most throttling questions are answered by two rules that have nothing to do with which tier you are on.

Cached reads are usually free of your input limit. For most Claude models, only uncached input tokens count toward ITPM. Tokens after your last cache breakpoint (input_tokens) and cache-writes (cache_creation_input_tokens) count; cache reads (cache_read_input_tokens) do not. Anthropic's worked example: with a 2,000,000 ITPM limit and an 80% cache hit rate, you can effectively process about 10,000,000 total input tokens per minute. The exception is Claude Haiku 3.5, marked with a dagger in Anthropic's tables, which does count cache reads toward ITPM. Prompt caching is therefore a larger throughput lever than a tier upgrade for most repeated-context workloads.

Acceleration limits are separate from rate limits. Anthropic's docs warn that you may get 429s "because of acceleration limits on the API if your organization has a sharp increase in usage," and advise ramping traffic gradually and keeping usage patterns consistent. A load test that jumps straight to your ceiling can fail while a steady workload at the same rate succeeds. Limits are enforced with a token bucket, so capacity replenishes continuously rather than resetting on a clock, and a 60 RPM limit may be enforced as roughly one request per second.

One smaller rule worth knowing: max_tokens does not factor into OTPM. Output limits are evaluated in real time against tokens actually generated, so setting a generous max_tokens carries no rate limit penalty.

Batches, Managed Agents, and Fast Mode Have Their Own Limits

The Messages API tables are not the whole picture. Three surfaces are limited separately.

Managed Agents endpoints are limited per organization and independently of the Messages API: 300 requests per minute for create operations (agents, sessions, environments) and 1,200 for read operations (retrieve, list, stream). Fast mode (research preview) with speed: "fast" on Opus 5 or Opus 4.8 draws on dedicated limits separate from standard Opus limits, and reports status in anthropic-fast-* response headers.

Anthropic also notes that Claude Platform on AWS behaves differently: those organizations are placed on the Start tier and do not move between tiers automatically, the self-service rate limit increase flow is unavailable, and per-workspace rate limit configuration and fast mode are not offered.

How to Read Your Own Limits

The published tables are standard limits, not your limits. Anthropic states plainly that all published limits "represent maximum allowed usage, not guaranteed minimums." Three ways to see the real numbers:

1. The Console. The Rate limits page shows your organization's tier and current limits; the Usage page carries input-token and output-token rate limit charts, including your cache hit rate.
2. The Rate Limits API, which returns the configured limits for your organization and workspaces programmatically.
3. Response headers on every call. anthropic-ratelimit-requests-limit, -remaining, and -reset cover requests; anthropic-ratelimit-input-tokens-* and -output-tokens-* cover throughput; anthropic-ratelimit-tokens-* reports whichever limit is currently most restrictive, including a Workspace limit if one applies.

To request more, use Request rate limit increase on the Rate limits page, which covers both rate limits and the monthly spend cap.

Practical Takeaways for Developers

1. Check your tier before you plan capacity. Start, Build, and Scale differ by 10x on RPM and 5x on throughput, and a new organization may sit below Start entirely in the Evaluation tier.
2. Cache before you upgrade. For most models an 80% cache hit rate multiplies effective input throughput about fivefold at the same tier, which is the cheaper lever.
3. Ramp gradually. Acceleration limits punish step changes in traffic independently of your tier.
4. Design for 429s regardless. Every limit returns a 429 with retry-after, so backoff remains required at every tier.
5. Split workloads across models deliberately. Limits are per model, and Opus 5 and Sonnet 5 sit outside the shared 4.x buckets.
6. Set a workspace limit if you share an organization. Workspace-level spend and rate limits protect other workspaces from one project's overuse, though they cannot be set on the default workspace and never exceed the organization limit.

Sources

Re-verified in full for the August 12, 2026 update:

• Claude Platform docs, "Rate limits": https://platform.claude.com/docs/en/api/rate-limits
• Claude Platform release notes (June 26, 2026 entry): https://platform.claude.com/docs/en/release-notes/overview

Cited as originally published, and not re-readable by an automated check:

• ClaudeDevs developer post (July 2, 2026): https://x.com/ClaudeDevs/status/2072818299361263778 -- the source of this article's original "no longer based on API spend" and "5x higher rate limits" wording. x.com blocks automated fetches, so that wording is reported as published rather than re-confirmed, and the figures above come from Anthropic's documentation instead.