API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited

Read the parenthetical, because it is the entire message. The service is throttling the rate at which it accepts your traffic; it is not telling you that a balance ran out. That rules out an exhausted plan allowance, an expired key, and a malformed request — and it also rules out the response most people reach for, which is to wait for a quota window to roll over. Nothing is draining, so nothing is going to refill.

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

A limit on a balance versus a limit on a rate

Quota errors and throttling errors feel identical from the terminal and behave nothing alike. A quota is a stock: you spend it down, it is gone, and it comes back on a schedule you cannot influence. A throttle is a valve on a flow: it reacts to how fast requests are arriving, right now, and it stops reacting as soon as they arrive more slowly.

That difference decides everything you do next. Against a stock, the only levers are time and buying more. Against a flow, time and money are both nearly useless, and the lever that works is the one nobody reaches for first: send less at once. Concurrency, not volume — the number of requests in flight simultaneously, not the number of tokens in any one of them.

It also explains the word “temporarily,” which is doing less work than it appears to. There is no published duration attached to it, because the duration is partly a function of what your client does next. A throttle that measures arrival rate is measuring every request, including the automatic retries fired at it by your own SDK and by whatever wrapper sits above that. The official SDKs retry transient failures — rate limits included — with exponential backoff, twice by default, honoring retry-after when it is present. That is sane behavior for one client. Multiply it across a dozen parallel workers and the retries alone can hold the valve shut. The naive response to this error extends the condition it is responding to.

Is retrying useful?

Yes — but only a retry that is both slower and narrower than the attempt that failed.

Honor retry-after if the response carries one. If it does not, back off exponentially; the docs specify exponential backoff and publish no base delay, so do not invent a fixed “wait N seconds” rule. None of that is the important part. The important part is that you must reduce the number of concurrent requests at the same time you back off. Retrying the same fan-out after a pause recreates the burst that triggered the throttle, one pause later.

The termination condition: if serial requests succeed while your parallel workload keeps getting throttled, retrying as configured will never converge. Stop tuning the delay and cut the concurrency instead.

Is it really not your usage? Four checks

The message asserts that this is not your usage limit. Verify it rather than trusting it, because a mislabeled refusal sends you down the wrong page for an hour.

Fire one request, on its own, with nothing else running. If the single request succeeds, the refusal is rate-shaped and the message is telling the truth. If the single request fails too, you are looking at an account-level limit and the mechanics on the rate limit reached page apply instead — in particular the test for a monthly spend cap, which is a 429 with no retry-after header.
Check what changed in the minutes before the first failure. Sharp increases in usage can trigger refusals from acceleration limits, which are separate from the published per-tier table. Going from idle to full fan-out in one step is the classic trigger; so is launching a batch of parallel agents against a project that was previously being driven by one person typing.
Check whether other people are seeing it simultaneously. A 529 overloaded_error reflects platform-wide traffic rather than anything about your organization. If the whole neighborhood is failing at once, your concurrency is not the variable — back off and wait it out.
Check whether you are behind a shared gateway or proxy. If your traffic reaches the API through a shared key or a relay serving multiple users, the arrival rate being measured is everyone’s, not yours. Your own request graph can be tiny and still be throttled. The test is to send the same request directly with your own key and see whether it clears.

What not to buy

The reflex when any API says “limited” is to upgrade something. Be precise about what an upgrade actually moves.

Raising an organization’s tier raises the published per-minute numbers — for the Opus 5 / Sonnet 5 / Haiku 4.5 class, requests per minute go from 1,000 on Start to 5,000 on Build to 10,000 on Scale, with input and output token limits rising alongside. That is real, and it is the correct response when you are genuinely exceeding your documented limits. It is not aimed at a protective throttle that has explicitly disclaimed your usage limit. Adding credits or moving to a larger plan against this message is money spent on a stock problem you do not have.

If you are unsure which of the two you have — plan allowance versus arrival rate — the Claude Code usage limit calculator answers the stock question directly: it tells you how much of a plan’s allowance your actual consumption represents. If the answer is “not much,” stop treating this as a quota problem.

Fix by scenario

Single request succeeds, parallel workload fails — cap in-flight requests. Pick a number, hold it, and raise it only after a clean full run. A worker pool with a fixed ceiling beats a retry policy every time here.
Started right after you increased parallelism — ramp instead of stepping. Reaching your steady-state concurrency over a minute rather than instantly is often the entire fix.
Everyone is failing at once — nothing on your side is wrong. Back off with exponential delay and let it pass.
Shared gateway or relay in the path — the throttle is measuring traffic you do not control. Move to your own credentials for the test, and treat the gateway’s capacity as the real constraint.
Bulk work that does not need to be interactive — move it off the synchronous path. The Message Batches API carries its own separate limits, which is the point: bulk traffic stops competing with the requests a human is waiting on.

How to confirm it’s fixed

A single successful request proves nothing, because a throttle releases on its own and you cannot tell that apart from your fix working.

Re-run the workload that failed, at the reduced concurrency, end to end, twice in a row, and watch for zero throttled responses across both runs. If you also changed the ramp, confirm the ceiling is actually being enforced — log the number of in-flight requests at peak rather than trusting the configuration value, since a pool limit that is set but not wired in looks exactly like a fix that worked once.

If the refusal names your usage or arrives with no retry-after header, it is the other kind of limit and API Error: Rate limit reached has the test that separates an ordinary throttle from a spend cap. If the failure mentions an upstream rather than a limit, your request did not reach the model service at all — 503 no healthy upstream is a routing failure and none of the advice on this page applies to it.