Claude Certified Architect – Foundations
Claude API rate limits: RPM, ITPM, OTPM and 429s The Claude API limits each model by requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM). Exceed any one and you get a 429. On most models, tokens read from the prompt cache do not count toward ITPM.
What counts ITPM counts input_tokens and cache_creation_input_tokens. cache_read_input_tokens do not count on most models; Claude Haiku 3.5 is the exception. With a 2,000,000 ITPM limit, a request that reads a 100,000-token cached prefix and adds 25,000 fresh tokens uses 25,000 of the budget, so you can sustain 80 such requests a minute. At an 80% cache hit rate, the same 2,000,000 ITPM limit covers about 10,000,000 total input tokens a minute.
OTPM counts only the tokens actually generated. max_tokens does not affect it, so a high max_tokens costs you no rate-limit headroom. Each model row in the limits table has its own RPM, ITPM and OTPM, and some rows cover several models that share one limit.
How limits are enforced The API uses a token bucket. Capacity refills continuously rather than resetting on the minute. Limits can also bite over shorter intervals: 60 RPM may be enforced as 1 request per second, so a burst can fail even when the minute average is fine. A sharp rise in usage can also hit acceleration limits. Ramp traffic up gradually.
When a 429 has a retry-after header, wait that many seconds before retrying. A 429 with error.details.error_code enforced_spend_limit_reached means the monthly spend cap was reached. It has no retry-after, and retries keep failing until access resumes.
Watching your headroom Every response carries headers such as anthropic-ratelimit-requests-remaining, anthropic-ratelimit-input-tokens-remaining and anthropic-ratelimit-output-tokens-remaining, with matching -limit and -reset headers. The anthropic-ratelimit-tokens-* headers show the most restrictive limit in effect, which may be a workspace limit. You can set lower limits per workspace so one team cannot use up the organization's capacity; organization-wide limits still apply. The Message Batches API has its own separate limits.
Where the exam catches people Believing cache reads count toward ITPM at a discount: on most models they do not count at all. Believing a high max_tokens reserves OTPM: only generated tokens count. Believing limits reset each minute: a token bucket refills continuously, and short bursts can still trip it. Believing every 429 is temporary: the spend-cap 429 has no retry-after and fails until access resumes. Written from Anthropic's documentation Try 3 questions on this Pick an answer to see why each option is right or wrong.
Your ingestion worker starts receiving HTTP 429 responses from the Messages API during a traffic spike. The current client retries on a fixed one-second interval, which keeps the worker throttled. You want the retry delay to follow what the API itself reports.
Which approach should you take? Right. In the game that’s Renown for your Context Management and Reliability building.
Not that one: A is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.
The answer A. Read the retry-after response header on the 429 and wait that many seconds before retrying.A 429 from the Messages API carries a retry-after header giving the number of seconds to wait before the request can succeed. Your answer B. Retry at the top of the next clock minute, when the rate limit bucket performs its fixed reset.There is no fixed reset boundary to wait for. Claude's rate limits are enforced with a continuously replenishing token bucket, so capacity returns gradually rather than in a lump at the start of each minute. Your answer C. Read anthropic-ratelimit-requests-limit from the 429 and wait that many seconds before retrying.The anthropic-ratelimit-requests-limit header reports the size of the request bucket, not a delay. Wait times come from retry-after (in seconds); the -reset headers give an RFC 3339 timestamp for full replenishment. Your answer D. Lower max_tokens on each retry until a request is accepted by the rate limiter.max_tokens is an upper bound on the response, and OTPM meters tokens actually generated, so a large max_tokens carries no rate-limit penalty and reducing it frees no capacity.
Show the full explanation and doc quotes Honouring that value — typically as the floor of an exponential backoff with jitter — is the documented way to recover from throttling without amplifying the overload.
Written from platform.claude.com/docs/en/api/rate-limits
Your team launches a nightly job that opens its full concurrency in a single burst at 02:00, calling Claude Sonnet 5 (claude-sonnet-5). Averaged over the minute the job stays under your organization's RPM and ITPM limits, yet the first few seconds return 429 responses with a retry-after header before the job settles. You must remove the burst failures without lowering total throughput.
What change would most effectively address this issue? Right. In the game that’s Renown for your Context Management and Reliability building.
Not that one: C is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.
Your answer A. Raise max_tokens on each request so fewer requests are needed, which lowers the instantaneous request rate at start-up.max_tokens is an upper bound on a single response, not a rate-limit input. OTPM counts tokens actually generated, so raising the cap has no effect on the bucket, and the opening burst of concurrent requests stays exactly as large.Your answer B. Retry immediately on every 429 with a fixed 100 ms delay so the burst drains as soon as the per-minute window resets.There is no per-minute window to wait out. Because capacity refills continuously, an immediate fixed-delay retry storm keeps the bucket empty; the API already tells the client how long to wait in the retry-after header, and exponential backoff on top of it is the documented pattern. The answer C. Ramp concurrency up gradually and honor the retry-after value with exponential backoff, so the token bucket can replenish.Rate limits use a token bucket that replenishes continuously rather than resetting on a minute boundary, and sudden step changes in traffic can also trip acceleration limits. Your answer D. Split the job across two API keys in the same organization so each key absorbs half of the opening burst.Rate limits are enforced at the organization and model-bucket level, so a second key in the same organization consumes the same capacity. Key separation improves attribution and blast-radius control, not throughput.
Show the full explanation and doc quotes Ramping concurrency up gradually lets the bucket keep pace, and backing off for the number of seconds named in the retry-after header on a 429 avoids compounding the overload.
Written from platform.claude.com/docs/en/api/rate-limits
Your dispatcher paces admissions evenly and releases each request only when its computed input size fits inside anthropic-ratelimit-input-tokens-remaining from the most recent response, running about 300 requests concurrently. Prompt caching is not in use. Across a throttled minute the input_tokens your service records reach 70% of anthropic-ratelimit-input-tokens-limit as the same responses report it, yet 429s attributed to input tokens continue.
What is the most likely root cause? Right. In the game that’s Renown for your Context Management and Reliability building.
Not that one: A is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.
The answer A. Input tokens are charged from an estimate taken as each request begins, so requests that are still running have already drawn on the bucket.Input-token capacity is not metered from finished responses. It is claimed on an estimate made as each request begins and only adjusted while that request runs, so 300 concurrent requests have already drawn on the bucket long before any of them reports an input_tokens figure. Your answer B. Published limits describe maximum allowed usage rather than a guaranteed minimum, so the ceiling actually enforced falls below the published figure at busy times.Published limits are described as maximum allowed usage rather than guaranteed minimums. That is a statement about entitlement, not a moving ceiling, and it is not what the service is comparing against anyway — the 70% figure is measured against the limit the responses themselves report, which is the enforced value. Your answer C. The -remaining value is rounded to the nearest thousand, so your dispatcher's admission arithmetic drifts from the limiter's own count.The -remaining headers really are rounded to the nearest thousand, so a dispatcher that treats them as exact will be off — by under a thousand tokens each time it reads one. Nothing about that rounding grows with concurrency, and it cannot open a thirty-percent gap between what the service counts and what the limiter counts. Your answer D. A per-minute limit is enforced over shorter intervals as well, so brief bursts exceed it while the minute's total stays inside the ceiling.A per-minute limit can be enforced over shorter intervals, which is why a clump of requests fired together is rejected even when the minute's total would have fitted. That is a different failure from this one: the dispatcher here spreads its admissions evenly, so there is no burst for the shorter window to catch.
Show the full explanation and doc quotes A ledger assembled from completed responses therefore always trails the limiter by roughly one round of in-flight work, and admitting on a -remaining value carried by an earlier response compounds that lag rather than correcting it.
Written from platform.claude.com/docs/en/api/rate-limits
Related Certopolis is an independent study game. It is not affiliated with, endorsed by or sponsored by Anthropic, and its questions are not the exams' questions. Exam names are trademarks of their owners.