Is 429 the same as being out of credit?

No. Out of credit or an invalid key returns 400/401 with a different error type. 429 means the request was valid but arrived too fast.

What about 529 or overloaded_error?

That is the provider being temporarily overloaded, not you exceeding a quota. Same remedy — exponential backoff with jitter — but no amount of reducing your own volume removes it.

Will raising max_tokens help?

The opposite. Reserved output tokens count against your output-per-minute budget, so an unnecessarily high max_tokens makes 429s more likely.

429 rate_limit_error from the AI API

Any AI coding tool Last checked 2026-10-14

HTTP 429 means you exceeded a quota in the current window — requests per minute, input tokens per minute, or output tokens per minute — not that your key is broken. Read the retry-after header, back off exponentially with jitter, and check which of the three limits you actually hit before you change anything else.

What you saw

429 Too Many Requests, or a JSON body containing "type": "rate_limit_error" / "code": "rate_limit_exceeded".

It often appears in bursts: fine for minutes, then a wall of failures, then fine again. Agents make this worse because a single task can fire dozens of calls in seconds.

What it actually means

Providers meter several things separately, and tripping any one of them returns 429:

Requests per minute (RPM) — too many calls, regardless of size.
Input tokens per minute (ITPM) — the usual culprit for agents. Every turn resends the whole conversation, so a long-running agent sends enormous input volume even with short replies.
Output tokens per minute (OTPM) — hit by long generations running in parallel.

429 is a *throttle*, not a rejection: the same request will usually succeed shortly afterwards. Distinguish it from 529 / overloaded_error, which means the provider itself is under load, and from 401, which is an auth problem.

Retrying immediately makes it worse. A retry storm turns one 429 into a sustained outage of your own making.

The fix

Respect the headers instead of guessing. Responses carry the limits and a reset time:

anthropic-ratelimit-input-tokens-remaining
anthropic-ratelimit-input-tokens-reset
retry-after

Back off exponentially with jitter, and cap the attempts. Fixed-interval retries from parallel workers re-synchronise and hit the wall together:
```
delay = min(cap, base * 2 ** attempt) * random.uniform(0.5, 1.5)
```
Use the official SDK's built-in retries rather than writing your own loop — they already honour retry-after for 429 and 5xx.
Cut input tokens, because ITPM is usually what you are hitting. Trim or summarise conversation history, stop re-attaching large files every turn, and enable prompt caching for the stable prefix of your system prompt.
Cap concurrency. One shared semaphore across all workers is more effective than tuning retries:
```
sem = asyncio.Semaphore(4)   # start low, raise only with evidence
```

How to stop it happening again

Log which limit tripped, with the response headers, every time. Without that you are tuning blind.

Treat 429 as expected traffic, not an exception — agents at any real volume will hit it. Build the backoff before you need it.

Put a queue in front of batch work so bursts become a steady rate instead of a spike.

If your workload is genuinely large and not latency-sensitive, move it to the provider's batch API, which is metered separately and costs less.

Check your tier's published limits before concluding something is wrong. Higher tiers unlock automatically on spend for most providers.