429 {"type":"error","error":{"type":"rate_limit_error","message":"Number of request tokens has exceeded your per-minute rate limit (https://docs.anthropic.com/en/api/rate-limits); see the response headers for current usage. Please reduce the prompt length or the maximum tokens requested, or try again later. You may also contact sales at https://www.anthropic.com/contact-sales to discuss your options for a rate limit increase."}}

Your request was well-formed and authenticated; an organization-level limit declined to run it right now. That rules out the usual suspects — not your API key, not a malformed body, not the model, and not platform capacity, which arrives as a 529 and explicitly is not about your usage. It is also not a subscription plan allowance: those print a named reset time rather than this, and they are a different accounting system entirely. And unlike most rate limit messages, this one has already told you which of the limits refused you. It says tokens, and it says request tokens — input, not output.

Data as of 2026-09. Vendor limits and defaults change; check the official docs for current values before acting on any number below.

The message did the triage; read the matching headers

Claude API rate limits are per-organization and per-model, and three of them are counted separately: requests per minute, input tokens per minute, and output tokens per minute. You can sit far below two of them and be refused by the third. Most rate limit text names none of them, which is why triage usually comes first. Here it does not have to.

That has a direct consequence for the headers, and it is the single fastest thing to get right on this page. Rate-limited responses carry the anthropic-ratelimit-{requests,tokens,input-tokens,output-tokens}-{limit,remaining,reset} family. The generic anthropic-ratelimit-tokens-* members report whichever limit is currently most restrictive — so reading them while debugging an input-side refusal can hand you a number that describes a different dimension. Read anthropic-ratelimit-input-tokens-remaining and anthropic-ratelimit-input-tokens-limit specifically. Two details in that family trip people up: reset values are RFC 3339 timestamps rather than durations, so you subtract rather than sleep on them, and remaining token counts are rounded to the nearest thousand, so a remaining count reading zero is not proof you were at exactly zero.

Is retrying useful?

Yes — but bound it, because one shape of this error retries forever.

When the response carries a retry-after header, honor it. The official SDKs already do: they retry transient failures including rate limits with exponential backoff, twice by default, honoring retry-after when present. Do not hard-code a wait of your own — the published guidance is exponential backoff, and no base delay is documented for you to copy. The refill helps you here: capacity replenishes continuously rather than resetting on a fixed boundary, so you are waiting for the bucket to hold what your next request needs, not for a clock to turn over.

The bound matters because of the next section. If a single request’s input exceeds your per-minute input allowance, no wait is long enough — the bucket never holds that much, and a retry loop on this error will run until you stop it. Retry twice; if the second attempt fails at the same size with the same headers showing near-full capacity, you are not being throttled by traffic, and the rest of this page applies.

Can one request even fit?

This is the question the message does not ask and the one that decides your whole response, because it separates a pacing problem from an impossible request.

A per-minute input budget is spent by whatever lands in that minute, including a single large request. So the arithmetic to run first is: the uncached input of one request, against your tier’s input-tokens-per-minute limit. Not your average, not your daily volume — one request.

The numbers make it concrete, and they are not intuitive. On the Start tier, the Fable 5.x class has an input limit of 500,000 tokens per minute, while Claude Fable 5.1’s context window is 1M tokens. A request can therefore be entirely legal for the model — comfortably inside the window it advertises — and still be one your rate limit can never admit. Nothing about that request is malformed; it is simply larger than a minute of your allowance.

The same arithmetic with more headroom: Opus 5, Sonnet 5 and Haiku 4.5 get 2,000,000 input tokens per minute on Start, against 1M-token context windows for Opus 5 and Sonnet 5. Two near-full-context requests of uncached input in one minute exhausts that allowance exactly. If you fire three agent turns in parallel on a long conversation that is not cached, you are not near the limit — you are through it.

So the discriminator is: does it fail when you send exactly one request into an idle minute? If yes, this is a per-request size problem and pacing will never fix it. If no, it is a traffic problem and size changes are the wrong lever.

What the message’s own advice gets right, and where it misleads

The text suggests two remedies, and they are not equally useful.

“Reduce the prompt length” is directionally right but measures the wrong thing, because the count is not your prompt — it is your uncached prompt. For most Claude models only uncached input counts toward the input-token limit: tokens after the last cache breakpoint count, tokens written to the cache count, and tokens read back from the cache do not. Claude Haiku 3.5 is the documented exception, which does count cache reads. If your prompt is a long cached prefix plus a short tail, trimming the prefix reduces a number that was never being charged. Trim the tail, or move the breakpoint.

“Reduce the maximum tokens requested” is the one to be careful with. Output tokens are counted as they are actually produced, and max_tokens does not factor into the output-per-minute accounting at all — a ceiling you never reach carries no penalty there. Since this refusal is on the input side anyway, lowering max_tokens is the change most likely to cost you truncated responses while leaving the error exactly where it was.

Fix by what the one-request test told you

One request into an idle minute fails — the request is too big for your tier, full stop. Shrink the uncached portion: cache the stable prefix, stop attaching whole files when a summary or a path would do, and split the work across turns. If the content genuinely cannot shrink, the remaining levers are a higher tier or a model class with a larger input allowance — those are the cases the message’s closing sentence about contacting sales is written for.
One request succeeds, the workload fails — this is concurrency. Halving in-flight requests is a faster lever than rewriting prompts, because a per-minute limit is about arrival rate. For bulk work the Message Batches API has its own separate limits and does not draw on these.
Failures began right after you scaled up, while headers still show headroom — acceleration limits, which are separate from the published tier table and triggered by how sharply traffic rose rather than by its total. Ramp gradually and it clears.
Every request is mostly the same long prefix — prompt caching is the highest-leverage change available, because it converts counted tokens into uncached ones. This is the one fix that reduces the number without reducing what the model sees.
You are on a plan rather than a metered organization key — then these counters are not the ones constraining you. The Claude Code usage limit calculator works in the plan’s accounting instead, which is where that answer lives.

How to confirm it is fixed

One successful request proves nothing: the bucket refills continuously, so a single pass is indistinguishable from having waited long enough while reading this page.

Re-run the workload that failed, at the same concurrency, for longer than a minute of traffic, and watch anthropic-ratelimit-input-tokens-remaining stay above zero for the whole run. That is the falsifiable version, and it is specifically the input-tokens member — watching the generic tokens family can show you a healthy number for a dimension that was never the problem.

For the single-request case the test is different and sharper: send the one request that failed, alone, into a minute with no other traffic. If it returns, the size change worked. If it returns the same 429 while the headers report near-full capacity, your request is still larger than a minute’s allowance and the number you reduced was a cached one.

If your client collapses this into a short line that names no dimension, the triage you skipped here is on the general rate limit reached page — including the 429 that carries no retry-after at all, which is a monthly spend cap and never clears by waiting. If the refusal explicitly disclaims your usage limit, it is server-side throttling rather than your quota, and waiting for a reset is the wrong move by construction. And if the block is about the long-context window rather than the rate at which you use it, 1M context requires usage credits is a different gate on the same large requests — worth checking before you conclude your tier is the problem.