OpenAI and Claude API Rate Limits: What Retries Really Cost

What counts against the limit differs by provider

OpenAI measures limits in requests per minute and per day, tokens per minute and per day, and images per minute, with limits set at the organization and project level and varying by model. Its guide states that your rate limit is calculated as the maximum of max_tokens and the estimated number of tokens based on the character count of your request. As a hypothetical, with a 150,000 tokens-per-minute limit (the sample value in OpenAI's header table), requests estimated at 1,500 tokens fit 100 to the minute. Set max_tokens to 8,000 on the same requests and each one counts as 8,000, so only 18 fit.

Anthropic measures requests per minute, input tokens per minute (ITPM), and output tokens per minute (OTPM) per model class. Its guide says OTPM counts only tokens actually generated, and that max_tokens does not factor into OTPM, so a high ceiling carries no rate-limit downside. For most Claude models, only uncached input tokens and cache writes count toward ITPM; cache reads do not. Anthropic's own example: with a 2,000,000 ITPM limit and an 80 percent cache hit rate, you can process 10,000,000 input tokens per minute.

• On OpenAI, oversized max_tokens values spend rate-limit headroom you never use.
• On Anthropic, prompt caching raises effective input throughput without a tier change.
• Both providers return rate-limit headers on responses, so log them next to each request.

Retries that make throttling worse

OpenAI's guide is direct: unsuccessful requests contribute to your per-minute limit, so continuously resending a request will not work. A retry that fires immediately takes capacity the original queue needed. As a hypothetical, 50 workers that each retry a throttled call 5 times without waiting turn 50 rejected requests into 250 attempts against the same per-minute budget, and most of them fail too.

Both providers describe the same discipline. When a Retry-After header is present, wait at least that long. OpenAI says to treat the value as a minimum and add a small random delay so clients do not retry together, and to fall back to exponential backoff with jitter when the header is missing, while limiting both the attempt count and the total retry time. OpenAI also documents a slow_down error that can occur within your limits when traffic rises too quickly, with a rule of thumb that above 1 million input tokens per minute you increase traffic by no more than 50 percent every 15 minutes.

• Honor Retry-After first, then exponential backoff with jitter.
• Cap attempts and total retry time per request.
• Ramp large jobs gradually instead of releasing a full queue at once.

When a 429 is a spend problem, not a speed problem

Not every 429 clears with time. Anthropic's errors page says a 429 rate_limit_error can mean your organization hit a rate limit, reached its usage tier's monthly spend cap, or reached a spend limit on a Claude Code workspace. OpenAI's guide says Retry-After does not mean that quota, billing, or other errors that require user action can be resolved by retrying.

A retry loop that treats every 429 the same will spin on a spend cap until it gives up, which hides the real cause from whoever is on call. Read the error type and message, retry only temporary throttling, and route cap and quota errors to an alert. That alert is also a budget signal: it is the provider telling you a limit you or your tier set has been reached.

Where retries add to the bill

Neither provider's rate-limit or error page states that a rejected 429 is charged, and this page does not claim it is. The cost risk sits in attempts that start work and then fail. Anthropic's errors page says some networks drop idle connections, which can make a request fail or time out without a response, and that an error can arrive after a 200 response while streaming. It recommends streaming or the Message Batches API instead of a large max_tokens on a plain request.

When an attempt like that is retried, the retry is a new request and is billed in full when it succeeds, including the whole prompt again unless part of it is served from a prompt cache. Whether the failed attempt was also billed is not stated on those pages, so measure it. Write one ledger row per attempt with its status, then reconcile against the provider usage report, as described in our token metering guide. As a hypothetical, if 3 percent of long requests drop and are retried, input token spend on that route rises by up to 3 percent before anyone sees an error rate.

• Stream long generations so idle connections do not cut them off.
• Record every attempt, not only the final success.
• Compare attempt-level token totals with the provider report to price retries.