TL;DR (July 2026): Yes - a request that comes back 429 Too Many Requests still counts. On the major LLM APIs a rejected call generally counts toward your rate limit and can still consume tokens from your quota, so the instinct to retry immediately and aggressively is exactly wrong: fast retries pile more requests onto an already-saturated limit and turn a brief throttle into a self-inflicted retry storm that keeps you rate-limited longer and burns quota the whole time. On top of that, AWS Bedrock and Azure OpenAI enforce quotas at the cloud-account level that you raise through a support ticket, not a settings toggle - so the ceiling you are hitting may not even be the model's. The uncomfortable part for your bill: a 429 is a real cost line - wasted tokens plus engineering time - and it is invisible unless you meter failed calls, not just successful ones.
Almost every rate-limit bug starts with the same reasonable-sounding assumption: a rejected request is free. It got refused, so it did not do anything, so retrying it right away is harmless. That assumption is what turns a two-second hiccup into a ten-minute outage. The rate limiter does not see "a request that failed." It sees "a request," and it counts it. Understanding that one detail changes how you write every retry loop, how you read your usage, and whether your throttling incidents are short or self-perpetuating.
Does a 429 count against your rate limit? Yes.
Rate limits are enforced at the edge, before the interesting work happens, and the counter increments when the request arrives - not when it succeeds. That is the whole reason a limiter can be cheap and fast: it does not need to know the outcome to decide whether to admit you. So a call that gets rejected with a 429 has still been counted against your per-minute request budget. Retry it immediately and you have now spent two of your requests to get zero successful responses, and pushed yourself further over the line you were already over.
The token side is the part people miss. Rate limits are not only about request counts - the binding constraint on most modern APIs is tokens per minute, and a rejected or partially-processed request can still draw down that token budget. As the provider rate-limit writeups document (see requesty.ai and devtk.ai's 2026 comparison), your quota is measured across both axes at once, and the exact accounting of a failed call varies by provider. The safe assumption - the one that keeps you out of trouble - is that a 429 is not free on either axis. Meter it as if it cost you, because it can.
The limits you're actually bumping against
Rate limits are tiered, and the tier structure is the map of what you can do about a 429. Here is how the major APIs draw the line as of mid-2026.
| Provider / tier | Representative limit | How you raise it |
|---|---|---|
| Gemini 2.5 Flash-Lite, Tier 1 | 4,000,000 input tokens/min | Automatic tier progression with usage |
| OpenAI, Tier 3 | 2,000,000 tokens/min | Requires $100+ cumulative spend and 7+ days on the account |
| Anthropic, Tier 4 | 2,000,000 input TPM + 400,000 output TPM | Usage-based tier progression |
| DeepSeek V4 | Dynamic concurrency (no fixed TPM) | Adapts to load rather than a published ceiling |
| AWS Bedrock / Azure OpenAI | Cloud-account-level quota | Support ticket / quota-increase request |
Representative July 2026 tiers; exact numbers vary by model and change over time. Sources: requesty.ai, devtk.ai, morphllm.com/llm-api.
Two things fall out of this table. First, the token-per-minute ceiling is usually the one that bites, and it scales with account maturity - OpenAI's Tier 3, for instance, is gated behind $100 of cumulative spend and at least seven days on the account, so a brand-new key hits the wall far sooner than the same code will on a seasoned one. Second, DeepSeek's dynamic-concurrency model means there is no fixed number to plan against; you are throttled by live load, which makes metering your own success-versus-429 ratio the only way to know where you actually stand.
The retry storm: the one you'll actually hit
Here is the failure mode in slow motion. Your traffic spikes and crosses the per-minute limit. The next call returns 429. Your client, doing the naive thing, retries immediately. That retry is also over the limit, so it also returns 429, and now every failed call is spawning another failed call. You have built a positive feedback loop: the more you are throttled, the harder you hammer, and the harder you hammer, the longer you stay throttled. Each attempt counts against the limit and can draw tokens, so the storm is not just noisy - it is expensive, and it actively delays your own recovery.
The fix is old and boring and works: exponential backoff with jitter. On a 429, wait - and wait longer on each successive failure, with a random offset so a fleet of clients does not all retry in lockstep. Respect the provider's Retry-After header when it sends one. Cap the number of retries so a call fails cleanly instead of forever. None of this is novel; the reason it keeps mattering is that the default behavior of a hand-written loop is the retry storm, and you only learn your loop was naive when it takes down production. The teams that avoid this are the ones who assumed the 429 was not free and designed the retry path accordingly.
The cloud-account gotcha
If you call models through AWS Bedrock or Azure OpenAI, the ceiling you are hitting may not be the model's rate limit at all - it is a quota attached to your cloud account, and you raise it by filing a support ticket or a quota-increase request, not by upgrading a plan or waiting out a tier. This changes the incident response entirely. On a direct API, a 429 means "slow down and back off." On Bedrock or Azure, a 429 can mean "you are structurally capped until a human approves more headroom," and no amount of backoff will fix it - you need the ticket in flight before the launch, not during the incident. Knowing which of the two you are looking at is the difference between a five-minute backoff and a two-day approval, and the only way to know is to have metered where your 429s cluster.
What changed in 2026
- Token-per-minute limits displaced request-per-minute limits as the binding constraint. As context windows and agent workloads grew, providers moved the real ceiling to TPM. That makes a 429's token cost more consequential and harder to reason about than in the request-counting era.
- Agents multiplied the request volume behind every user action. One agent task now fans out into tool calls, sub-agents, and retries, so the traffic that trips a rate limit is generated by your own automation, at machine speed, in bursts a human would never produce - the perfect conditions for a retry storm.
- Provider limits diverged. With Gemini publishing fixed TPM tiers, OpenAI and Anthropic gating tiers on spend and account age, DeepSeek using dynamic concurrency, and Bedrock/Azure enforcing account quotas, there is no single "the rate limit" anymore. Your effective ceiling depends on which provider, which tier, and which account you are on.
429s are a cost line you can only see if you meter failures
Most usage tracking counts successful calls, because that is what generates output and what the provider bills for on the happy path. That is precisely why the 429 tax is invisible: it lives entirely in the calls that failed. If your meter only records successes, a retry storm shows up as a mysterious latency spike and an unexplained quota drawdown, with no line item pointing at the cause. Meter the failures too - count your 429s, tag them by model, endpoint, and the code path that generated them - and the hidden cost becomes a visible one you can actually manage.
Concretely, that means treating a rejected call as a first-class event in your usage data, the same way a token gets attributed to a customer and a code path. A rising 429 rate on one endpoint tells you where you are under-provisioned before it becomes an outage. The cleanest place to capture it is the gateway every call already passes through, because a single chokepoint sees every request and every rejection, including the retries your application code never logs. And when a retry storm does start, the thing that stops it from becoming a runaway is the same hard cap and kill switch you would use against any spend runaway - a limit that trips on request rate and quota drawdown, not just on dollars. If you are choosing a provider partly on how much rate-limit headroom you get, the tier structure and how you climb it belongs in that decision, and it all sits inside the broader AI cost-tooling stack.
The honest take
The exact accounting of a 429 - whether it debits tokens, how the counter treats a partial response, when the header tells you to retry - varies by provider and shifts as they tune their systems, so do not trust any single blog post (this one included) as the final word on the mechanics. Trust the one durable conclusion: a rejected request is not free, so build every retry path as if it costs you, and measure whether it does. The teams that get surprised are the ones who counted only their successes and treated failures as nothing. A 429 is the API telling you something you are paying for is going wrong. Meter it, back off from it, and know whether it is a model limit you can wait out or an account quota you have to escalate - because guessing wrong at 2 a.m. is the expensive path.