Updated guide · June 2026
The Claude API is a different world from the claude.ai chat plans. Instead of a five-hour message window, you get pay-as-you-go token pricing plus per-minute rate limits, organized into usage tiers that grow with your account. This guide explains RPM, TPM, tiers, requesting more, and how to handle the 429 errors that throttling produces.
Straight answer
The Claude API has its own per-minute rate limits and usage tiers, separate from claude.ai chat plans — check the Anthropic Console. You pay per token rather than a flat monthly fee, and your throughput is capped by requests per minute and tokens per minute, not a five-hour window. Verify your exact figures in the Console; they change.
Rate limits are grouped into usage tiers (commonly Tier 1 to Tier 4). Your tier rises automatically as your cumulative spend and account history grow, lifting your RPM and TPM ceilings; you can also request higher limits. Limits differ per model. Confirm current values on the official rate-limits docs.
Two different systems
The single biggest source of confusion is treating the API and the chat app as one product. They are billed, limited and accessed in completely different ways, and understanding the split saves a lot of wasted troubleshooting.
Free, Pro and Max chat subscriptions use a rolling five-hour limit plus weekly limits. You pay a flat monthly fee and Claude slows or pauses you when you exceed a window. There is no per-token bill.
The API throttles you per minute via requests per minute and tokens per minute, and bills you per token consumed. There is no five-hour pause; instead you get a 429 error the moment you exceed the per-minute ceiling.
The API lives on platform.claude.com and the Anthropic Console with its own keys and billing. Your claude.ai subscription does not grant API quota, and API spend does not touch your chat limits.
Developers building apps need the API and its rate limits. Individuals chatting need a subscription. Mixing the two up leads people to expect a message count on the API or per-token billing on chat, and neither exists.
The dimensions
Claude API rate limits are not a single number. They are several limits applied at once, and you can be throttled the moment you cross any one of them. The table below describes the dimensions generically; read the live figures per model and tier in the Console.
| Dimension | What it caps | How it behaves | What to do |
|---|---|---|---|
| RPM (requests per minute) | The number of separate API calls you can make in any given minute. | Bursting many small calls at once can trip this even if each call is tiny. | Queue and pace requests rather than firing them all simultaneously. |
| Input TPM (input tokens per minute) | The total tokens of prompt and context you can send per minute. | Large prompts, long histories and big documents consume this quickly. | Trim context, cache repeated material and avoid re-sending the same text. |
| Output TPM (output tokens per minute) | The total tokens the model can generate back to you per minute. | Long generations and high concurrency push against this ceiling. | Set sensible max-token limits and stream where it helps throughput. |
| Usage tier | Which set of RPM and TPM ceilings your account is allowed. | Rises automatically as spend and account age grow; differs per model. | Build usage history, or request higher limits through the Console. |
Treat the Console as the source of truth. Open it, find the rate-limits view for each model you call, and read your current RPM, input TPM and output TPM at your present tier rather than memorizing any number from a blog.
Tiers
Most developers never have to think hard about tiers, because they climb on their own. But knowing the mechanism helps you plan capacity for a launch and avoid being throttled at the worst moment.
New accounts begin at the lowest tier, with modest RPM and TPM ceilings that are fine for prototyping and small workloads.
As your cumulative spend and account history grow, Anthropic automatically promotes you through higher tiers (commonly up to Tier 4), each lifting your limits.
A given tier sets different ceilings for different models, so your throughput on a heavy model may differ from a lighter one even at the same tier.
If automatic promotion is not fast enough for a launch, you can request higher limits through the Anthropic Console. Verify the current process on the rate-limits docs.
If you expect a traffic spike, raise or request limits before the event, not during it, so you are not throttled when demand peaks.
Watch your usage and headroom in the Console so you know how close you are to each ceiling before it bites.
429 errors
When you exceed a rate limit, the API returns a 429 status code. This is normal and expected at scale; the difference between a fragile app and a robust one is how it reacts. The pattern is always the same: slow down, retry intelligently, and avoid making the problem worse.
A 429 means too many requests. You crossed an RPM or TPM ceiling for your tier and model. It is not an account error or a billing problem; it is the API telling you to pace yourself. The request was not processed, so it is safe to retry once you wait.
Do not retry immediately in a tight loop, which only deepens the throttle. Wait a short delay, then double it on each failure (for example one, two, four seconds), adding random jitter so many clients do not retry in lockstep. Honor the retry-after header when the response includes one.
The best 429 handling is needing it rarely. Queue and rate-limit your own outbound calls below your ceiling, batch where the API allows it, cache repeated context, and choose the lightest model that does the job so you consume fewer tokens per call.
Anthropic documents the exact error shapes and recommended retry behavior. Read the official API error and rate-limit pages, then bake backoff and jitter into your client library so throttling degrades gracefully instead of crashing your app.
Cost and throughput
Because the API bills per token and limits per minute, your two concerns are cost and throughput. They are linked: the same habits that lower your bill also keep you under your rate limits, because both scale with the tokens you push through.
| Lever | Effect on cost | Effect on rate limits |
|---|---|---|
| Smaller prompts and context | Fewer input tokens billed. | Less input TPM consumed per call. |
| Prompt and context caching | Avoids re-billing repeated context. | Frees input TPM for new work. |
| Capping output length | Fewer output tokens billed. | Less output TPM consumed. |
| Choosing a lighter model | Lower per-token price. | Often different and higher ceilings. |
| Batching and queueing | No direct change. | Smooths bursts so you stay under RPM. |
| Climbing or requesting tiers | No direct change. | Raises RPM and TPM ceilings outright. |
None of these numbers are published here on purpose, because token prices and per-tier limits change. The discipline is the same regardless: send fewer, smaller, cached tokens on the lightest viable model, and verify the live figures in the Console and on the pricing page.
Symptoms
Most rate-limit surprises map to a handful of causes. Match what your logs show before assuming something is broken with your key or account.
You likely spiked your request rate past RPM, often from launching many parallel calls at once. Add a queue and exponential backoff so the burst is smoothed out instead of slamming the ceiling.
If 429s appear on big requests but not small ones, you are hitting input TPM. Trim context, cache repeated material, and avoid re-sending the same long documents on every call.
If your ceilings seem small for your workload, check your tier in the Console. New accounts start low and rise with spend; you can also request higher limits before a launch.
If a heavy model throttles sooner than a lighter one, that is expected: limits differ per model at the same tier. Route lighter tasks to lighter models to preserve headroom.
Alternatives
If a single provider's rate limits or pricing constrain your project, the resilient pattern is not depending on one model. MultipleChat lets you run Claude alongside other models in one workspace, and the comparison guides below help you choose.
Run Claude-style answers next to ChatGPT, Gemini and search models in one workspace. When one provider is rate-limited or down, keep working in another model instead of waiting.
AlternativeBroad assistant and API option for writing, coding and everyday productivity when Claude is unavailable.
AlternativeUseful for Google Workspace and Google-context work, with its own API surface.
ResearchResearch-focused answers with web sources when you need citations.
Our guideHow the chat subscription limits work, separate from the API.
Our guideHow Cowork shares your chat plan usage pool.
Our guidePer-seat plans, admin controls and data terms for teams.
Sources
Rate limits, token prices and tiers change. Use these official pages and your own Anthropic Console before making decisions.
Anthropic's official explanation of RPM, TPM, tiers and how to request more.
Your live rate limits per model, current tier, keys and usage.
Official per-token API pricing and plan wording.
Context on chat usage limits, for contrast with the API.
The chat product, separate from the API, with its own subscription limits.
FAQ
Short, hedged answers for people searching Claude API rate limits, RPM, TPM, usage tiers and 429 errors.
No. The Claude API on platform.claude.com and the Anthropic Console is billed and limited separately from claude.ai chat subscriptions. The API uses pay-as-you-go token pricing plus per-minute rate limits organized into usage tiers, while chat plans use a rolling five-hour limit plus weekly limits. Verify your exact API limits in the Anthropic Console.
RPM is requests per minute, the number of API calls you can make in a minute. TPM is tokens per minute, usually split into input tokens per minute and output tokens per minute, capping how much text can flow through in a minute. You can be throttled by either dimension. Check current RPM and TPM figures per model in the Anthropic Console.
Anthropic organizes API rate limits into usage tiers, often described as Tier 1 through Tier 4. As your account history and cumulative spend grow, your tier increases automatically, which raises your RPM and TPM ceilings. Each tier has its own limits per model. Confirm your current tier and its limits in the Console.
Tiers generally rise automatically as your spend and account age increase, so consistent usage moves you up over time. If you need more before then, you can request higher limits through the Anthropic Console. Verify the current request process and eligibility on the official rate-limits documentation.
A 429 status code means too many requests, meaning you hit a rate limit such as RPM or TPM. The fix is to slow down and retry with exponential backoff, ideally honoring the retry-after header if present. Spreading load and batching reduces how often you see 429s. See the official API error documentation for specifics.
Yes. Each model can have its own RPM and TPM limits at a given tier, and heavier models often have different ceilings than lighter ones. Always read the per-model rate-limit table in the Anthropic Console rather than assuming one number applies everywhere.
The API is pay-as-you-go: you are charged per input and output token at the model's published rate, with no flat monthly message allowance. Chat subscriptions like Pro and Max are flat monthly fees with usage caps instead of per-token billing. Confirm current token pricing on the official pricing page.
Implement exponential backoff with jitter on 429s, batch and queue requests so you do not burst past RPM or TPM, cache repeated context, pick the lightest model that does the job, and monitor your usage in the Console. Building these in from the start avoids throttling as you scale. Verify limits and best practices in the official documentation.