Why Your AI Automation Hits 429 Rate Limits

A 429 from an AI API means your organization crossed a per-minute limit. It is almost never the model being down, and it is almost never your request-per-minute limit. The limit you actually blew through is tokens per minute, and because a failed request still spends that budget, adding blind retries makes it worse. The fix is to read the rate-limit headers, find the exact dimension you are bound on, and act on that dimension.

Most guides answer a 429 with one word: backoff. Add exponential backoff, retry, done. That advice treats every 429 as the same problem. It is not. A request-limit 429, a token-limit 429, and a provider-overload error each need a different response, and the response that clears one will thrash the others.

What a 429 actually means, and what it does not

A 429 is a statement about your account, not about the model. You sent more than your organization is allowed to send in a rolling 60-second window, so the API rejected the call. The model is fine. Your budget for the minute is spent.

There is a separate error for the model being overloaded, and operators confuse the two constantly. On Anthropic's API that is a 529. On OpenAI it is a 503. Those mean the provider is out of capacity, and they are the one case where retrying with backoff is the right move, ideally paired with a fallback to a second provider. A 429 is the opposite situation. Retrying against a limit you have already maxed out just adds more rejected calls to a window that is already full. If your automation treats a 429 and a 529 the same way, half your retry logic is aimed at the wrong problem. We cover the provider-down case in AI provider outages: how to build a fallback.

The two big providers also count tokens differently, which matters once you start tuning. OpenAI enforces one combined tokens-per-minute number that includes both your prompt and the model's output. Anthropic splits it into two separate meters: input tokens per minute (ITPM) and output tokens per minute (OTPM). You can be bound on input while output sits idle, or the reverse. Knowing which one changes what you cut.

The limit you hit is tokens, not requests

Request-per-minute ceilings are high. On Anthropic's Start tier, the entry level, a current Sonnet or Opus model allows 1,000 requests per minute. Most small-business automations do not come close to sending a thousand API calls a minute. So the request meter is rarely the one that trips.

Tokens are a different story. The same Start tier allows 2,000,000 input tokens per minute and 400,000 output tokens per minute on those models. That sounds like a lot until you look at what one real call costs. Summarizing a 40,000-token PDF spends 40,000 of your input budget in a single request. Fifty of those documents run through a loop node is 2,000,000 input tokens, exactly the Start-tier ceiling, consumed in whatever fraction of a minute your platform fires them in. The request count for that job is 50, nowhere near the 1,000 RPM limit. You did not hit a wall on requests. You emptied the token budget.

This is why the common mental model, "I am only making a few calls, why am I rate limited," leads people to the wrong fix. The number of calls is not the constraint. The size of each call multiplied by how fast you send them is the constraint.

Why your automation platform is the actual cause

The rate limit is set by the API. The pattern that overruns it is set by your automation. n8n's Loop Over Items node, a Zapier multi-step Zap fired by a batch trigger, and Make's array aggregator all do the same thing: they take a list and push items through as fast as the platform can, often several at once. None of these tools has any awareness of your API's token budget. They will happily fire 50 concurrent requests into a limit built for a steady trickle.

So the cause is your concurrency and batch shape, not the model and not the API being stingy. That reframing matters because it points at the real lever. You control how fast items leave your workflow. The API only controls what happens when they arrive too fast.

Retries make this worse in a specific, avoidable way. A rejected 429 request still counted against your budget on the way in, because usage is estimated when the request starts, not only when it succeeds. If your workflow catches the 429 and immediately resends, you have now spent the estimated tokens twice, and the second attempt lands in the same saturated window. Backoff without spacing out the whole batch is just a slower way to keep hitting the same wall. The retry logic has to space the entire job, not each individual call. Our guide on when an automation should retry a failed step covers how to classify the failure before you reach for a retry count.

Read the headers to find the dimension you are bound on

Every response, success or 429, tells you exactly how much headroom is left on each meter. Stop guessing and read it. These are the values worth capturing in your workflow's error branch.

Provider	Requests left	Input tokens left	Output tokens left	How long to wait
Anthropic	anthropic-ratelimit-requests-remaining	anthropic-ratelimit-input-tokens-remaining	anthropic-ratelimit-output-tokens-remaining	retry-after (seconds)
OpenAI	x-ratelimit-remaining-requests	x-ratelimit-remaining-tokens (input + output combined)	(same combined counter)	x-ratelimit-reset-tokens / -requests

The rule is simple. Whichever remaining value sits near zero when you get the 429 is the dimension you are bound on. If requests-remaining is healthy but input-tokens-remaining is at zero, you have a token problem and cutting your request count will do nothing. Anthropic also hands you a retry-after in seconds on a 429. Wait at least that long. Retrying before it elapses is guaranteed to fail, so an earlier retry is pure waste.

Match the fix to the dimension

Once you know which meter tripped, the fix is specific. Here is the mapping.

What tripped	Wrong reflex	Right fix
Requests per minute	Shrink the prompt	Cap concurrency, add spacing, or pack multiple items into one request
Input tokens per minute	Send faster to catch up	Shrink prompts, cache the static prefix, or move to the Batch API
Output tokens per minute	Lower max_tokens	Reduce what you actually ask the model to generate
Provider overloaded (529 / 503)	Keep retrying the same provider	Back off and fail over to a second provider

A few of these deserve a sentence each.

If you are bound on input tokens and you are reusing the same large context across calls, prompt caching is close to free headroom. On most current Claude models, cached input tokens do not count toward your ITPM limit at all. With an 80 percent cache hit rate against a 2,000,000 ITPM ceiling, you can push roughly 10,000,000 total input tokens a minute, because the 8,000,000 cached tokens are invisible to the limiter. Caching a big static document or a long system prompt raises your real ceiling without asking anyone for a limit increase. We walk through when this fires in prompt caching in automations.

If you are bound on output tokens, note one thing that trips people up: on Anthropic's API, your max_tokens setting does not count toward the output meter. Only the tokens the model actually generates count. So setting a generous max_tokens has no rate-limit cost, and the real fix is to ask for less output, not to cap the ceiling.

And if nothing is waiting on the result, the cleanest answer to a token limit is to stop making synchronous calls at all. The asynchronous Batch API runs the same model against its own separate queue, off your per-minute meters, usually at half the price. That is the right home for overnight enrichment and bulk document jobs. We compare the two modes in batch versus real-time AI calls.

What to do next

Start by capturing the rate-limit headers in your workflow's error handling, even before you change anything else. When the next 429 fires, you will know in one glance whether it was requests, input tokens, output tokens, or a provider outage, and that single fact decides the fix. Then set your concurrency deliberately. Pick a number of parallel requests your token budget can actually sustain, and space the batch instead of firing it all at once.

Most rate-limit pain in a small operation comes from one loop node set to full speed against an entry-tier budget. It is fixable in an afternoon once you stop treating every 429 as the same error. If you want a second set of eyes on an automation that keeps stalling under load, tell us what it does and we will help you find the meter it is hitting. You can also see how we structure resilient AI pipelines on our workflow automation systems page.