api rate limits

Claude API rate limits on the Start tier allow most current models 2,000,000 input tokens and 400,000 output tokens per minute, with 1,000 or 4,000 requests per minute depending on the model. There is no fixed number of concurrent sessions: how many requests you can keep in flight depends on which of those per-minute limits your workload hits first, and how long each request takes.

Last verified: 5 November 2026, against Anthropic’s rate limits documentation.

Key Takeaways

• The Claude API sets per-minute limits on requests, input tokens and output tokens, and none of them is a fixed concurrent-session count.
• For any workload, the lowest of RPM, ITPM ÷ input per call and OTPM ÷ output per call sets your throughput.
• Multiply that throughput by average request duration, divided by 60, to estimate requests in flight.
• Cache reads don’t count toward ITPM on most models, so caching can lift input-bound workloads several times over.
• Workspace overrides can lower a team’s effective limit below the organisation’s.
• Plan below the maximum, read the rate-limit headers and retry with backoff and jitter.

---

Quick Navigation

---

Current Claude API rate limits by tier

Anthropic now groups organisations into Start, Build and Scale tiers, plus a Custom tier arranged with its account team. New organisations may begin in an Evaluation tier with lower limits while they build a usage history. Anthropic places organisations on a tier automatically, and you can ask for an increase from the Rate limits page in the Claude Console.

Each model group has three separate limits. Requests per minute (RPM) counts API calls. Input tokens per minute (ITPM) counts the prompt tokens you send. Output tokens per minute (OTPM) counts the tokens the model generates.

Tier	Model group	RPM	ITPM	OTPM
Start	Opus 5.5, Sonnet 5.5, Haiku 5.5	4,000	2,000,000	400,000
Start	Opus 5, Opus 4.x, Sonnet 5, Sonnet 4.x, Haiku 4.5	1,000	2,000,000	400,000
Start	Fable 5.x	4,000	500,000	100,000
Build	Opus 5.5, Sonnet 5.5, Haiku 5.5	10,000	5,000,000	1,000,000
Build	Opus 5, Opus 4.x, Sonnet 5, Sonnet 4.x, Haiku 4.5	5,000	5,000,000	1,000,000
Build	Fable 5.x	10,000	1,500,000	300,000
Scale	Opus 5.5, Sonnet 5.5, Haiku 5.5	13,000	10,000,000	2,000,000
Scale	Opus 5, Opus 4.x, Sonnet 5, Sonnet 4.x, Haiku 4.5	10,000	10,000,000	2,000,000
Scale	Fable 5.x	13,000	4,000,000	800,000

Source: Anthropic rate limits documentation, Messages API tables, checked 5 November 2026.

Each row in the table describes a limit for one model group, and groups don’t share a budget. Opus 4.8, 4.7, 4.6 and 4.5 draw from one combined Opus 4.x limit, while Opus 5.5 and Opus 5 each have their own. Sonnet 4.6 and 4.5 share a Sonnet 4.x limit, and Fable 5.1 and Fable 5 share a Fable limit. The Rate Limits API lists exactly which model IDs count against each group for your organisation.

Each tier also carries a monthly spend cap of $500 on Start, $1,000 on Build and $200,000 on Scale. Reaching it pauses usage until the first day of the next month, unless you get a higher limit approved sooner.

How many concurrent requests can you run?

The API publishes per-minute limits, not a cap on simultaneous connections. To estimate concurrency, work out how many requests per minute each limit allows for your workload, take the lowest, and multiply by how long a request lasts.

The formula

Estimated in-flight requests = permitted requests per minute × average request duration in seconds ÷ 60.

Permitted requests per minute is the smallest of three numbers:

• your RPM limit;
• your ITPM limit divided by the input tokens that count against it per request;
• your OTPM limit divided by the output tokens per request.

The result is a sustainable average for a steady workload. It doesn’t promise that a given number of requests can start at the same instant.

Worked example 1: an output-limited workload

This illustrative workload runs on the Start tier with Opus 5, which allows 1,000 RPM, 2,000,000 ITPM and 400,000 OTPM.

1. Each prompt is 20,000 tokens, and 80% of them are read from the prompt cache. Cache reads don’t count toward ITPM on this model, so each call counts 20,000 × 0.2 = 4,000 uncached input tokens.
2. Input allows 2,000,000 ÷ 4,000 = 500 calls per minute.
3. Each response is 2,000 tokens. Output allows 400,000 ÷ 2,000 = 200 calls per minute.
4. RPM allows 1,000 calls per minute.
5. The lowest of 500, 200 and 1,000 is 200 calls per minute, so output is the binding limit.
6. With an average call lasting 30 seconds, in-flight requests come to 200 × 30 ÷ 60 = 100.

Output binds here because each response is long relative to the uncached prompt. On Opus 5.5, the RPM figure would rise to 4,000, but the answer would stay at 200 calls a minute because the token limits are the same. Even then, 100 is an average to plan around, and bursts above it can still trigger 429 errors.

Worked example 2: an input-limited workload

This second illustrative workload uses the same Start-tier limits for Opus 5, but each request summarises a fresh document.

1. Each prompt is 50,000 tokens. Every document is new, so the cache hit rate is 0% and all 50,000 tokens count toward ITPM.
2. Input allows 2,000,000 ÷ 50,000 = 40 calls per minute.
3. Each summary is 1,000 tokens. Output allows 400,000 ÷ 1,000 = 400 calls per minute.
4. RPM allows 1,000 calls per minute.
5. The lowest of 40, 400 and 1,000 is 40 calls per minute, so input is the binding limit.
6. With an average call lasting 15 seconds, in-flight requests come to 40 × 15 ÷ 60 = 10.

Caching changes this case sharply. If a 30,000-token instruction block were cached and only 20,000 tokens per call were new, input would allow 2,000,000 ÷ 20,000 = 100 calls per minute. Output would still allow 400, so the binding limit would rise from 40 to 100 calls a minute.

Where the estimate breaks down

The formula assumes steady request sizes and durations, which real traffic rarely has. Long and short prompts mix, streaming responses hold connections open longer, and network latency and queueing add time that the model isn’t using. Retries add load at the moment you can least afford it.

The rate limits are also enforced more finely than a minute. Anthropic uses a token bucket that refills continuously, and notes that a limit of 60 RPM might be enforced as one request per second. Sharp rises in an organisation’s traffic can also hit separate acceleration limits, so Anthropic advises ramping up gradually.

Two details help planning. ITPM is estimated when a request starts and corrected as it runs. OTPM counts only tokens actually generated, so a high max_tokens setting doesn’t use up the allowance on its own. Most teams plan well below the theoretical maximum to leave room for bursts and retries.

How prompt caching raises effective input throughput

For most Claude models, only uncached input tokens count toward ITPM. The API reports three kinds of input token: input_tokens after the last cache breakpoint, cache_creation_input_tokens written to the cache, and cache_read_input_tokens read from it. The first two count toward ITPM, and cache reads don’t.

Anthropic’s own example uses a 2,000,000 ITPM limit and an 80% cache hit rate. In that case, 20% of incoming tokens count, so the limit supports 2,000,000 ÷ 0.2 = 10,000,000 total input tokens per minute: 2 million uncached and 8 million cached.

The benefit applies only to the input limit. Caching doesn’t raise RPM or OTPM, and the first request that writes a cache entry still counts in full. The retired Claude Haiku 3.5 is an exception, because it counts cache reads toward ITPM. Billing for cached tokens follows a separate price schedule from rate limiting. Our guide to structuring prompts for caching covers how to keep a stable prefix that the cache can reuse.

What happens when you hit a limit

Exceeding any one limit returns an HTTP 429 with the type rate_limit_error that names the limit you crossed. When the response includes a retry-after header, Anthropic says to wait that many seconds, because earlier retries will fail. A 429 caused by the monthly spend cap carries no retry-after header and keeps failing until access resumes, so retrying it won’t help.

Successful responses carry rate-limit headers you can use to schedule work before you hit a wall:

• anthropic-ratelimit-requests-limit, -remaining and -reset track requests.
• anthropic-ratelimit-input-tokens-limit, -remaining and -reset track input tokens.
• anthropic-ratelimit-output-tokens-limit, -remaining and -reset track output tokens.
• anthropic-ratelimit-tokens-limit, -remaining and -reset show whichever token limit is most restrictive right now.

The reset headers use RFC 3339 timestamps, and the token “remaining” values are rounded to the nearest thousand. A scheduler can slow its dispatch rate as remaining capacity falls, which avoids most 429s in the first place.

When 429s do arrive, use exponential backoff with random jitter so that many workers don’t retry at the same moment. Anthropic’s official SDKs retry automatically, twice by default, and honour retry-after. A shared queue with a fixed concurrency cap is usually safer than letting each worker retry on its own.

Workspace limits and Priority Tier

Organisation limits are the ceiling, and workspace limits can be set lower to stop one team or app using everything. Without an override, a workspace inherits the organisation’s limit. The Rate Limits API can set workspace overrides for requests, input and output tokens per minute, cache-aware input tokens per minute, tokens per minute, tokens per day and tool uses per second. The lower of the workspace and organisation values applies, and changes take effect within about an hour.

Priority Tier is a separate capacity commitment measured in input and output tokens per minute for a specific model. Anthropic says new commitments are no longer available for purchase, though existing contracts continue until they end. Priority requests still draw on the ordinary rate limits, and traffic beyond the commitment falls back to the standard tier.

Claude.ai, Claude Code and API limits are separate

Usage limits on Claude.ai and Claude Code subscriptions are a different system from the API rate limits above. Anthropic bills the API separately from paid Claude plans, and its support documentation explains how the two relate. For plan allowances, check the current articles on Claude’s help centre.

How Claude API rate limits compare with other providers

Other providers combine request limits, token throughput, account tiers, daily caps and per-model rules in different ways, so their figures can’t be compared directly. Our overview of AI API rate limits across providers sets them side by side, and our guide to LLM cost per task shows how to price the same workloads.

Frequently asked questions

Does the Claude API have a fixed concurrent-session limit?

The rate-limit documentation doesn’t list one. Concurrency follows from the per-minute limits and request length, so a workload with short responses can run far more parallel calls than one producing long outputs.

Can multiple applications share the same Anthropic API rate limits?

Yes. Every key in an organisation draws on the same organisation limits, and the anthropic-workspace-id response header shows which workspace a request counted against. Giving each application its own workspace with lower overrides stops one from using all the capacity, though the organisation limits still cap the total.

What is the difference between a 429 rate-limit error and a server error?

A 429 means your organisation has used its allowance, so the fix is to slow down or wait for retry-after. A 500 signals an internal error and a 529 signals that the API is overloaded for everyone. Both are temporary and worth retrying with backoff.

Can prompt caching increase Claude API request concurrency?

Only when input tokens are the binding limit. Caching leaves RPM and OTPM unchanged, so an output-bound workload gets no extra concurrency from it.

---

Keep reading

Here are the latest posts from the blog.