Claude API Rate Limit Per Minute Explained

Claude API rate limits are enforced across several dimensions at once, not just "requests per minute." If you're hitting 429 errors, the per-minute limit that's actually blocking you is usually one of three things: requests per minute (RPM), input tokens per minute (ITPM), or output tokens per minute (OTPM). Understanding which one you're bumping into changes how you fix it.

This article breaks down what each limit means, how Anthropic's usage tiers affect them, and what to actually do when your app starts getting throttled.

The three per-minute limits that matter

Anthropic enforces rate limits per organization, per model, and they reset on a rolling basis (not a fixed clock minute). The limits that apply are:

• RPM (requests per minute) — total number of API calls you can make, regardless of size.
• ITPM (input tokens per minute) — total tokens sent in request bodies, including system prompts, message history, and tool definitions.
• OTPM (output tokens per minute) — total tokens generated in responses.

You can hit a 429 on any one of these even if the other two have plenty of headroom. A common failure mode: you batch 50 small requests per minute (fine for RPM) but each includes a large document in context, blowing through ITPM. Another common one: you ask for long completions (high max_tokens usage) and OTPM becomes the bottleneck well before RPM does.

The response headers on every API call tell you exactly where you stand:

anthropic-ratelimit-requests-limit: 50
anthropic-ratelimit-requests-remaining: 12
anthropic-ratelimit-requests-reset: 2024-06-01T12:01:00Z
anthropic-ratelimit-input-tokens-limit: 40000
anthropic-ratelimit-input-tokens-remaining: 3500
anthropic-ratelimit-output-tokens-limit: 8000
anthropic-ratelimit-output-tokens-remaining: 0

Check these before assuming RPM is the culprit — in practice, token-based limits bite first for most real-world workloads.

Rate limits scale with usage tier

Anthropic assigns accounts to usage tiers based on billing history and account age, not something you configure directly. Newer or lower-spend accounts get stricter limits; as spend and account age increase, limits scale up automatically. This means:

• A fresh account on Claude might see RPM in the dozens and ITPM in the tens of thousands.
• An account with months of consistent spend can see those numbers go up by an order of magnitude.
• Limits also differ by model — Haiku models typically get higher throughput allowances than Opus-class models, since they're cheaper and faster to serve.

This tiering is the main reason two developers running similar code can get very different rate limit experiences. It's not arbitrary — it's tied to how much sustained traffic Anthropic has seen from that account.

What actually causes 429s in practice

In order of how often they show up in real applications:

1. Bursty traffic — a cron job or webhook that fires 20 requests simultaneously instead of spacing them out.
2. Large context windows — feeding full conversation history or long documents on every call, multiplying input tokens fast.
3. Unbounded max_tokens — setting generation length high "just in case," which caps your effective OTPM headroom even when actual output is short.
4. Concurrent users sharing one API key — a backend serving many end users through a single key, where limits apply to the whole org, not per-user.

That last point matters for teams building multi-user products. If ten users hit your service at once and all requests route through one shared key, you hit the same per-minute ceiling as a single power user making ten calls in a row.

Practical ways to handle it

Respect the reset header. Instead of guessing a backoff delay, read anthropic-ratelimit-requests-reset (or the token equivalent) and wait until that timestamp before retrying.

Implement exponential backoff with jitter. On a 429, retry with increasing delay plus randomness so retries from multiple clients don't collide:

async function callWithBackoff(fn, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      if (err.status !== 429 || attempt === maxRetries - 1) throw err;
      const delay = Math.min(1000 * 2 ** attempt, 30000) + Math.random() * 500;
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

Trim context aggressively. Summarize or truncate conversation history instead of resending everything on each turn. This directly reduces ITPM pressure.

Set realistic max_tokens. Don't request 4096 output tokens for a response that's typically 200 tokens long.

Queue and throttle client-side. Use a rate limiter (token bucket pattern) in your own backend so you never send more than your known RPM/TPM allowance, rather than discovering it via 429s in production.

Where a managed API layer helps

If you're building a product on top of Claude and want your own API keys, usage metadata per key, and team seat management without wiring up all the rate-limit handling yourself, SubToAPI sits on top of your existing Claude access and exposes it as a clean HTTPS API. You get application-level sub_live_... keys, streaming, and tool use support — see /docs/quickstart and /docs/messages for the request format, or /docs/streaming if you're building chat-style UIs that need token-by-token output. Plans start at €9/month with a free trial at /signup, and pricing scales with seats at /pricing.

This doesn't remove Anthropic's underlying rate limits — those still exist upstream — but it gives you a single place to see usage across your team and issue separate keys per application or environment instead of sharing one credential across everything.

questions

Is the Claude API rate limit the same for every account? No. Limits are assigned per usage tier based on account age and billing history, and they also vary by model — Haiku models generally allow higher throughput than Opus-class models.

Why am I getting 429 errors even though I'm under my RPM limit? You're likely hitting input or output token limits (ITPM/OTPM) instead. Check the anthropic-ratelimit-* response headers on your requests to see which specific limit is exhausted.

Do rate limits reset exactly on the clock minute? No, they're rolling windows, not fixed clock resets. Use the anthropic-ratelimit-requests-reset (or token) header value to know exactly when your quota replenishes rather than assuming a fixed interval.