Rate limits are not one number, they are three meters running at once, and only one of them ever binds. Pick your Anthropic tier, your OpenAI tier, or your Claude plan, describe one agent's workload, and this computes the org-wide concurrent-agent ceiling from published limits, names the meter that fires first, and prices the next rung against more seats and against spreading the fleet across keys.
Concurrent, not sequential. Two agents running for an hour is two agents, and this is the number people underestimate once agent teams are in play.
fits
| Meter | Published | Your demand | Allows | Used |
|---|
The highlighted row is the cheapest rung that covers what you are asking for.
An API ceiling is arithmetic. Divide each published meter by what one agent draws from it per minute, and the smallest quotient is how many agents that tier carries. A subscription plan has no published per-minute meter at all, so its ceiling comes from the published weekly allowance spread across a forty hour week, and from the rolling five-hour window.
All published limits checked August 2026. Both vendors move these, sometimes upward without notice; read your own console before you plan a quarter around a number on this page.
Every capacity conversation starts with the wrong number. The tier you are on is not your ceiling; the smallest of its meters divided by your workload is.
An Anthropic API tier publishes three limits at once: requests per minute, input tokens per minute, and output tokens per minute. They are enforced independently, which means your real ceiling is set by whichever one your particular workload exhausts first, and for a coding agent that is almost never the request meter. Agents make few calls carrying enormous context, so a fleet that is nowhere near 5,000 requests a minute can be sitting on the input meter. Change the workload and the binding meter moves: an agent doing bulk generation rather than repository reading binds on output instead, at a tenth of the token volume.
OpenAI splits it differently, with a single combined tokens-per-minute meter alongside requests. That sounds simpler and is materially harsher for agent work, because everything counts: the prompt, the context you resend on every turn, and the reply. A 500,000 TPM Tier 1 account running agents at 45,000 tokens a minute each carries roughly ten of them. Ten is not a lot when a single developer runs two.
Anthropic excludes cache reads from the input meter entirely. Cache writes count, uncached input counts, cache reads do not, and for a coding agent working a warm repository the cache reads are the overwhelming majority of the input. Anthropic's own documentation works the example: a two million ITPM limit at an eighty percent cache hit rate effectively processes ten million input tokens a minute. In ceiling terms, moving a fleet from a cold cache to an eighty percent hit rate is worth more than a full tier upgrade, and it costs nothing but structuring your prompts so the stable parts sit above the breakpoint.
This is also why two organizations on the same tier can report completely different experiences with 429s. The one that reuses system prompts, tool definitions and repository context across turns is running five times the fleet of the one that rebuilds its prompt every request, on identical published limits.
Claude Pro, Max 5x and Max 20x are not rate-limited in requests per minute. They are budgeted in a rolling five-hour window and a weekly cap, so the failure mode is different in kind: you do not get a 429 in the middle of a burst, you get a Thursday where the account is simply finished until the reset. Expressed as a sustained concurrent-agent number, Max 5x's published 140 Sonnet-hours a week works out to about three and a half agents running continuously through a forty hour week, and the five-hour window holds it nearer two and a half in any single afternoon. On Opus, divide both by 2.5 and then check the separate Opus allowance, which is the tighter of the two.
Seats scale that linearly, which is the one genuine advantage a subscription fleet has: every account carries its own window and its own weekly pool, so ten seats is ten independent ceilings rather than one larger one. What nothing in the CLI does is move a session between them when one runs out.
Rate limits are enforced per organization, not per key, so issuing a second key inside the same organization buys nothing at all. Workspace limits are a way to reserve capacity for one team rather than add any, and the organization ceiling still applies even when the workspace limits sum to more. Real extra capacity means a second organization, a second provider, or both, which turns the problem into routing: see LLM failover for the failure semantics and LLM gateway pricing compared for what the routing layer costs.
Everything the planner runs on, written out, so you can check it against your own console rather than trusting a slider.
| Tier | Monthly spend cap | Model | RPM | ITPM | OTPM |
|---|---|---|---|---|---|
| Start | $500 | Opus 5 / Sonnet 5 / Haiku 4.5 | 1,000 | 2,000,000 | 400,000 |
| Start | $500 | Fable 5 | 1,000 | 500,000 | 100,000 |
| Build | $1,000 | Opus 5 / Sonnet 5 / Haiku 4.5 | 5,000 | 5,000,000 | 1,000,000 |
| Build | $1,000 | Fable 5 | 2,000 | 1,500,000 | 300,000 |
| Scale | $200,000 | Opus 5 / Sonnet 5 / Haiku 4.5 | 10,000 | 10,000,000 | 2,000,000 |
| Scale | $200,000 | Fable 5 | 4,000 | 4,000,000 | 800,000 |
Source: platform.claude.com/docs/en/api/rate-limits, read 20 August 2026. Opus 4.x and Sonnet 4.x carry their own combined buckets not shown here. Cache reads do not count toward ITPM on any of these models. Above Scale is a Custom tier arranged with sales.
| Tier | Qualifies at | Monthly usage limit | RPM | TPM (combined) |
|---|---|---|---|---|
| Tier 1 | $5 paid | $100 | 500 | 500,000 |
| Tier 2 | $50 paid | $500 | 5,000 | 1,000,000 |
| Tier 3 | $100 paid | $1,000 | 5,000 | 2,000,000 |
| Tier 4 | $250 paid | $5,000 | 10,000 | 4,000,000 |
| Tier 5 | $1,000 paid | $200,000 | 15,000 | 40,000,000 |
Sources: developers.openai.com/api/docs/models/gpt-5.6 and the GPT-5.2 model page for the per-tier limits, developers.openai.com/api/docs/guides/rate-limits for the qualification thresholds and monthly usage limits. All read 20 August 2026. Smaller models carry their own, usually higher, limits.
| Plan | Price / mo | Sonnet hours / wk | Opus hours / wk | Fable 5 | 5-hour window |
|---|---|---|---|---|---|
| Claude Pro | $20 | 40 to 80 | not published | usage credits, outside the plan | baseline |
| Claude Max 5x | $100 | 140 to 280 | 15 to 35 | up to 50% of the pool | 5x Pro |
| Claude Max 20x | $200 | 240 to 480 | 24 to 40 | up to 50% of the pool | 20x Pro |
The planner uses the low end of each range. There is no published per-minute meter on these plans; the concurrent-agent numbers it shows are the weekly allowance spread across a forty hour week, and a derived five-hour window capacity. Detail in the Claude Code rate limits guide.
Longer versions live in Claude Code rate limits and LLM failover.
It depends almost entirely on your cache hit rate, because Anthropic excludes cache reads from the input-tokens-per-minute meter. On Build tier with Claude Sonnet 5 the published limits are 5,000 requests per minute, 5,000,000 input tokens per minute and 1,000,000 output tokens per minute. A coding agent drawing 45,000 total input tokens per minute at an 80 percent cache hit rate presents 9,000 uncached, so the input meter alone allows roughly 555 concurrent agents. Run the same agents with a cold cache and that falls to about 111. The tier did not change; the caching did.
As of August 2026 Anthropic names them Start, Build, Scale and Custom, not Tier 1 to Tier 4. For Claude Opus 5, Sonnet 5 and Haiku 4.5 the published limits are 1,000 RPM with 2M ITPM and 400k OTPM on Start, 5,000 RPM with 5M ITPM and 1M OTPM on Build, and 10,000 RPM with 10M ITPM and 2M OTPM on Scale. Claude Fable 5 is metered separately and much lower: 500k ITPM and 100k OTPM on Start. Each tier also carries a monthly spend cap: $500 on Start, $1,000 on Build, $200,000 on Scale.
OpenAI runs five paid usage tiers that you move up automatically as cumulative spend clears a threshold: $5 for Tier 1, $50 for Tier 2, $100 for Tier 3, $250 for Tier 4 and $1,000 for Tier 5. For the flagship GPT-5.6 and GPT-5.2 models the published limits are 500 RPM and 500,000 TPM on Tier 1, 5,000 RPM and 1M TPM on Tier 2, 5,000 RPM and 2M TPM on Tier 3, 10,000 RPM and 4M TPM on Tier 4, and 15,000 RPM and 40M TPM on Tier 5. Unlike Anthropic's split input and output meters, TPM is a single combined token meter.
No. Rate limits are enforced at the organization level, not per key, so a second key inside the same organization draws from exactly the same bucket. What does raise the ceiling is a second organization, a second provider, or a workspace-level split that reserves capacity rather than adding it. A gateway in front of several credentials turns that into automatic routing instead of a developer noticing a 429 and switching by hand.
Three reasons, all of them about time resolution. A per-minute limit is usually enforced over a much shorter interval, so 60 requests per minute can behave like one per second and a burst trips it while the minute-level average looks fine. Anthropic also applies acceleration limits when an organization's usage climbs sharply, which fire even below the published ceiling. And input token limits are estimated at the start of a request and corrected during it, so a request that turns out larger than its estimate can push you over after it was admitted.
Live gauges on every account and every key, side by side, so the wall arrives as a rising bar rather than a 429. Run several accounts and several providers at once, with the routing in the tool instead of in a developer's head.
one command · reads local history · sends nothing on its own