Claude API Usage Limits Explained

If you've hit a 429 error or an unexpectedly slow response from Claude, you've run into a usage limit. Claude API usage limits are restrictions Anthropic places on how many requests, tokens, and concurrent connections an account can send within a given time window. They exist to protect infrastructure stability and to scale access gradually as accounts prove reliable usage patterns.

There are three separate limit types to understand: requests per minute (RPM), tokens per minute (TPM), and tokens per day (TPD) on some tiers. Each model (Opus, Sonnet, Haiku) typically has its own limit bucket, and limits increase automatically as your account moves through usage tiers based on spend history and account age. Understanding which limit you're hitting — and why — is the first step to fixing it.

The Three Limit Dimensions

Requests Per Minute (RPM)

This caps how many individual API calls you can make in a 60-second window, regardless of how small each request is. If you're firing off many short requests in a tight loop (common in batch processing or testing scripts), RPM is usually the first wall you hit.

Tokens Per Minute (TPM)

This caps the total number of input + output tokens processed across all requests in a 60-second window. A single large request with a long context window can consume a big chunk of your TPM budget on its own, even if it only counts as one request against your RPM limit.

Tokens Per Day (TPD)

Some account tiers also enforce a rolling daily token cap, separate from the per-minute limits. This matters most for high-volume production workloads that run consistently throughout the day rather than in short bursts.

How Usage Tiers Work

Anthropic assigns accounts to usage tiers that determine the actual numeric limits for each dimension above. New accounts start at the lowest tier with conservative limits. As you make successful API calls and accumulate billing history, your account is automatically promoted to higher tiers with higher RPM/TPM ceilings — there's no manual request process for the lower tiers, though very high-volume use cases can request custom limits directly.

This means a limit you hit in week one of using the API may simply disappear a few weeks later as your tier increases. If you're building something that needs predictable throughput before that natural ramp-up happens, plan around burst behavior rather than assuming flat limits forever.

What Happens When You Hit a Limit

When a request exceeds your current rate limit, the API returns an HTTP 429 Too Many Requests response. The response headers typically include information about which limit was breached and how long to wait before retrying. The correct handling pattern is exponential backoff with jitter — retry after a short delay, and increase that delay on repeated failures rather than hammering the endpoint immediately.

A naive retry loop without backoff will often make the problem worse, since it adds more requests into the same rate window that's already saturated.

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) {
        const delay = Math.pow(2, attempt) * 1000 + Math.random() * 500;
        await new Promise((r) => setTimeout(r, delay));
        continue;
      }
      throw err;
    }
  }
}

Token Limits vs Rate Limits

It's worth separating two concepts that get confused often: context window limits and rate limits. The context window is the maximum number of tokens (input + output combined) a single request can contain — this is a per-call ceiling tied to the model itself, not a time-based throttle. Rate limits, by contrast, are about how many tokens or requests you can send across all calls within a time window. You can be well under your context window per request and still hit a rate limit if you're sending too many requests too fast.

Practical Ways to Stay Under Limits

• Batch logically, not aggressively. Combine smaller requests where it makes sense instead of firing many tiny calls.
• Cache repeated prompts. If the same system prompt or context is reused across calls, avoid re-sending identical large blocks unnecessarily.
• Spread load across time. For bulk jobs, add deliberate pacing instead of maximizing throughput immediately.
• Monitor usage proactively. Track your request and token counts before you hit a wall, not after.
• Separate workloads by model. Routing lightweight tasks to a smaller/faster model keeps your heavier model's TPM budget free for complex calls.

Where SubToAPI Fits In

If you're integrating Claude into a product and want usage visibility without building your own tracking layer, SubToAPI turns your Claude access into a standard HTTPS API with per-key usage metadata included in every response. That means you can see token counts and request patterns per application key without instrumenting your own logging pipeline. Team plans also let you split usage across seats so one noisy integration doesn't eat a shared limit budget unnoticed. Check the docs or the quickstart to see how key-based access and metadata reporting work in practice.

FAQ

What's the difference between RPM and TPM limits?

RPM counts the number of API calls per minute regardless of size; TPM counts the total tokens (input and output) processed per minute regardless of how many calls that spans. A few large requests can hit a TPM wall while staying well under the RPM cap, and vice versa.

Do Claude API usage limits increase automatically?

Yes, for most tiers. Anthropic raises RPM/TPM limits automatically as an account accumulates usage history and billing activity. High-volume teams needing limits beyond standard tiers can request custom increases directly from Anthropic.

How do I know which limit I hit when I get a 429?

The 429 response includes headers indicating which specific limit (RPM, TPM, or TPD) was exceeded and guidance on retry timing. Logging these headers in your error handling is the fastest way to diagnose repeated throttling instead of guessing.