Error messages

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

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

This is a 429, the HTTP status for "too many requests", and Claude Code goes out of its way to tell you it isn't your plan running dry. In reports the whole line nearly always reads:

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

The words before the dot are Claude Code's. "Rate limited" after it is the message the API itself put in its response. If you found this by searching "Server rate limiting", that phrase comes from auto-generated GitHub issue titles, and 418 of them match it; the line in your terminal is the one above. I read how version 2.1.282 builds it, and how that differs from the other 429s and from overload.

How Claude Code tells it apart from your usage limit

When you really have used up your plan, the API's 429 carries a set of unified rate-limit headers saying which limit you hit and when it resets. Claude Code checks for them first. With them, you get one of the usage-limit messages covered in our limits pages. Without them, the 429 can't be about your quota, and on a claude.ai subscription sign-in you get this line.

Anthropic's error reference describes it as "a short-lived throttle that is unrelated to your plan quota". Neither the binary nor the docs say why the API throttles at a given moment, and I haven't seen staff explain it in the issues either, so treat any theory you read about it with care.

The same 429 for API-key users

If you sign in with an API key, or run through Bedrock or Google Cloud, the same branch writes a different prefix:

API Error: Request rejected (429) · this may be a temporary capacity issue.

That one means you've hit the rate limit configured on your key or cloud project, and it ends with the same status-page sentence the 529 page describes. The raw API side of that, with the headers and what a spend cap looks like, is on the Claude API 429 page.

Why it used to stop everything, and doesn't now

Here's what surprised me. For months this throttle wasn't retried at all on subscriptions. The reference says so directly: before v2.1.199, a session signed in with a claude.ai subscription "failed the turn on the first occurrence"; only API key and Enterprise sign-ins retried it. That explains the angriest reports. In #60562, filed May 19, 2026 on a Max plan, parallel agents died on the first throttle and "do not auto-retry", and #69594 in June described whole multi-agent workflows skipping the failed subagents and carrying on without them.

From 2.1.199 on, it's retried with backoff whichever way you log in. The 2.1.282 retry check agrees: a 429 on a subscription is retried when it has none of the quota headers. The default budget is 10 attempts, which CLAUDE_CODE_MAX_RETRIES changes, and CLAUDE_CODE_RETRY_WATCHDOG=1 keeps retrying 429s and 529s indefinitely, which is what the docs suggest for unattended jobs.

Which makes the version numbers in recent reports stand out. Issues #86958, #88015 and #91267, filed in August and September 2026, all say version 2.1.114 on Windows. That's well before the fix, so if claude --version shows something that old, updating is the first thing to try.

What to do when it shows up

Wait briefly and send again; the reference's advice stops there, plus checking status.claude.com if it keeps going. On a current version, seeing the line means the retries already ran out, so a short pause helps more than hammering the prompt.

If it goes on for hours, you aren't alone. The person behind #68521 (June 15, 2026, version 2.1.172) had it for 24 hours across several accounts. They said running /compact "seems to have helped", then came back to say "This is not fixed." No one from Anthropic replied on that thread.

And if what you're seeing is Repeated 529 Overloaded errors instead, that's overload across all users rather than a throttle, and the fix there is switching model with /model. A plain 500 Internal server error is a third thing again: a failure inside the API.