Anthropic API rate limits: RPM, ITPM, OTPM and how to see 429s coming

Failure facts checked on the vendor’s docs on Nov 8, 2026.

This page covers the Claude API, the one your code calls. Limits on the Claude apps are different and are not described here.

The API throttles you in more ways than the number on a pricing page suggests. A 429 can come from a per-minute limit, a sudden jump in traffic, or a monthly spend cap, and Anthropic uses the same error type for all three.

How Anthropic meters you

Messages API limits are requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM). Each applies to a model class, so heavy use of one model does not use up another's allowance. Some old models share a combined limit, noted in footnotes to Anthropic's tables. Limits attach to your organization, and your tier (Start, Build, Scale or Custom) is set automatically from usage history. New organizations may begin in an Evaluation tier with lower limits.

Three details change how you should read your own numbers:

• Token bucket. Capacity refills continuously instead of resetting on the minute. Anthropic notes that a limit of 60 RPM might be enforced as one request per second, so a burst of 20 requests in one second can fail with plenty of minute-level headroom.
• Cache-aware ITPM. For most models, cache_read_input_tokens do not count. An 80% cache hit rate lets a 2 million ITPM limit carry 10 million total input tokens a minute. If your cache hit rate falls after a prompt change, your effective limit falls with it.
• OTPM is real output. It counts generated tokens as they are produced, and max_tokens does not enter the calculation.

Batch requests, the Files API and fast mode each have their own limits, separate from the Messages API limits.

Three different 429s

The spend cap case is the dangerous one. Anthropic states that retries, including the SDK's automatic retries, fail until access resumes. A spend limit you set yourself behaves differently: it returns a 400 invalid_request_error, not a 429.

A separate 529 overloaded_error appears when the API is busy across all users. Do not count it against your own quota.

Headers to record

Every response carries anthropic-ratelimit-requests-limit, -remaining and -reset, and the same trio for tokens, input tokens and output tokens. Reset times are RFC 3339 timestamps. The token remaining values are rounded to the nearest thousand, and the tokens headers show whichever limit is currently most restrictive. A 429 adds retry-after in seconds. Every response, error or not, has a request-id header that support will ask for.

import json, time
import anthropic

client = anthropic.Anthropic(max_retries=0)  # we log and retry ourselves

def call(messages, attempt=1):
    t0 = time.time()
    try:
        raw = client.messages.with_raw_response.create(
            model="your-model", max_tokens=1024, messages=messages
        )
        status, h = 200, raw.headers
    except anthropic.APIStatusError as e:
        status, h = e.status_code, e.response.headers
        detail = (e.body or {}).get("error", {}).get("details", {})
        print(json.dumps({"msg": "vendor call", "vendor": "anthropic", "status": status,
            "attempt": attempt, "error_code": detail.get("error_code"),
            "retry_after": h.get("retry-after"), "request_id": h.get("request-id")}))
        raise
    print(json.dumps({"msg": "vendor call", "vendor": "anthropic", "status": status,
        "attempt": attempt, "duration_ms": int((time.time() - t0) * 1000),
        "input_remaining": h.get("anthropic-ratelimit-input-tokens-remaining"),
        "output_remaining": h.get("anthropic-ratelimit-output-tokens-remaining"),
        "requests_remaining": h.get("anthropic-ratelimit-requests-remaining"),
        "request_id": h.get("request-id")}))
    return raw.parse()

What to alert on

• 429 share per model over five minutes, against that model's own recent level.
• Any enforced_spend_limit_reached. Treat it as an incident the first time you see it.
• Input tokens remaining as a share of the limit, and your cache hit rate. A drop in hit rate often arrives before the 429s do.
• 529 count, tracked apart from 429, so you can tell Anthropic's capacity from your own usage.
• Attempts per successful call.

Example: a cache change that raised ITPM use

This is an example, not output from a real project. A made-up support-drafts service moves a timestamp to the top of its system prompt, which breaks its prompt cache.

09:10:02Z msg="vendor call" vendor=anthropic status=200 input_remaining=1820000 cache_read_tokens=186000
09:42:15Z msg="vendor call" vendor=anthropic status=200 input_remaining=1795000 cache_read_tokens=0
09:42:58Z msg="vendor call" vendor=anthropic status=200 input_remaining=212000 cache_read_tokens=0
09:43:07Z msg="vendor call" vendor=anthropic status=429 retry_after=11 request_id=req_example_1

Request volume did not change. Cache reads fell to zero at 09

Checklist

1. Record the anthropic-ratelimit-* headers and request-id on every call.
2. Branch on error.details.error_code before deciding to retry.
3. Set max_retries=0 in the SDK if you add your own retry layer.
4. Track cache read tokens next to ITPM headroom.
5. Ramp traffic up gradually to stay clear of acceleration limits.
6. Use the Console's Usage page to see peak ITPM and OTPM by hour before you ask for a higher tier.

See also monitoring third-party dependencies, LLM behavior drift and LLM spend spikes. Sazabi can watch these call logs for you once they reach it.