A 429 is free. The ninth retry is not.

Almost everything written about LLM rate limits is a table of limits. Requests per minute by tier, tokens per minute by model, how to qualify for the next rung. Those tables are useful for about six weeks, which is roughly how long it takes a vendor to restructure them — Anthropic’s tiers are now called Start, Build and Scale, OpenAI moved its entire developer documentation to a new domain, and SpaceXAI changed how tier qualification is computed in January.

What none of them tell you is the part that shows up on an invoice. A 429 is not a billing event. It is the response to a 429 that costs money, and the amount depends on something most retry code has never heard of: whether your backoff outlasts your prompt cache.

We read the current rate-limit and error documentation at Anthropic, OpenAI, Google, SpaceXAI and DeepSeek, then did the arithmetic against our own pricing snapshot. Three things came out of it that we have not seen written down anywhere.

The error itself is free

A rate-limited request is rejected before it reaches a model. No prompt is processed, no tokens are generated, so there is nothing to bill. This follows so directly from token-based pricing that vendors rarely bother to state it — the one place we found it written explicitly is OpenAI’s Flex documentation, describing a 429 resource_unavailable: “You will not be charged when this occurs.”

So if the error is free, where does the money go? Three channels, in descending order of how badly they bite.

Channel one: your backoff outlives your cache

Here is the mechanism, in two sentences from Anthropic’s caching documentation:

“By default, the cache has a 5-minute lifetime. The cache is refreshed for no additional cost each time the cached content is used.”

That second sentence is the whole problem. The TTL is a sliding window, and it slides only when something reads the cache. A failed request reads nothing. So during a backoff, the clock runs and nothing refreshes it — and the same documentation adds that the lifetime “is measured from the start of the request that writes or reads the cache entry, not from the end of its response.”

Now lay a textbook exponential backoff against a 300-second window. One-second base, doubling, counting only the waits:

Eight retries are free. The ninth is not. That is the sharpest practical line in this whole subject: your retry budget is not set by the vendor’s patience, it is set by your own cache TTL, and it happens to be eight attempts deep for the most common backoff shape in the wild. Add full jitter and the expected cumulative wait roughly halves, which buys you about one more attempt — it does not change the shape.

What crossing the line actually costs

Once the entry has expired, the next request re-writes the entire prefix instead of reading it. The ratio is fixed by Anthropic’s multipliers — 5-minute writes at 1.25x base input, 1-hour writes at 2x, reads at 0.1x — so it does not move when prices move:

• Re-writing at the 5-minute rate costs 12.5x the cached read.
• Re-writing at the 1-hour rate costs 20x the cached read.

In dollars, for a 200,000-token agent context, one crossing:

Forty-six cents sounds like nothing. It is a per-worker, per-incident charge, which is where it stops sounding like nothing:

Nothing in that table is a token you asked for. It is the same context, paid for repeatedly, because a queue waited too long.

Channel two: a cold retry spends rate limit, not just money

This is the part that turns a cost story into a throughput story, and it is documented in one paragraph that deserves far more attention than it gets:

“For most Claude models, only uncached input tokens count toward your ITPM rate limits.”

Anthropic then itemises it. Tokens after your last cache breakpoint count. Tokens being written to the cache count. Tokens read from the cache do not.

So a cache miss is charged twice. Once in dollars, at 12.5x. And once against the rate limit that caused the problem in the first place.

Put numbers on a Sonnet 5 agent on the Start tier — 1,000 RPM, 2,000,000 ITPM — carrying a 200,000-token cached prefix and sending 2,000 new tokens per turn:

A cold request consumes 101 times the rate-limit budget of a warm one. The same tier, the same model, the same work: a thousand requests a minute warm, nine cold. Anthropic’s own worked example says the same thing from the other side — a 2,000,000 ITPM limit at an 80% hit rate carries 10,000,000 total input tokens per minute.

One exception worth knowing: Claude Haiku 3.5 does count cache_read_input_tokens toward ITPM. It is retired except on Bedrock and Google Cloud, so this matters mainly if you are still running it there.

The loop this creates

Read the last two sections together and the failure mode assembles itself.

A 429 arrives. Your code backs off. The backoff crosses the TTL. The retry is now cold, which means it bills 101 times the ITPM of the request it replaced. That consumption makes the next 429 more likely, which triggers another backoff, which crosses another TTL.

This is the only cost mechanism in LLM billing we know of that pays for its own recurrence.

It gets worse with a fleet, because caches that were warmed together expire together. Ten workers, same 200,000-token prefix, all retrying after a shared incident:

Ten workers running warm use one percent of the limit. The same ten workers, recovering together, use a hundred and one percent of it — so the recovery is itself rate-limited, and the herd re-triggers the incident it is recovering from.

The mitigation is not a cleverer retry policy. It is desynchronisation, and it is the same fix as the cost fix: keep the caches warm, and stagger anything that fans out. This is precisely why Claude Code staggers the agents in a workflow so they read a shared cached prefix rather than each writing their own — a design we costed in running many agents at once, where it cut a fan-out bill by up to 90%. It reads differently now: that stagger is a rate-limit mitigation as much as a billing one.

Channel three: the run that dies

The third channel is the simplest and the easiest to forget. An agent that fails at turn 25 of 30 has not saved you five turns of spending. It has spent twenty-five turns’ worth of money and produced nothing you can ship.

A 30-turn Sonnet 5 session — 12,000-token prefix, 1,500 new tokens per turn, 600 tokens of output, cache warm throughout — costs $0.5748. Where it dies decides how much of that is waste:

The tail is brutal because cost accumulates quadratically in a conversation: every turn re-reads a history that keeps growing. Four-fifths of the bill is already sunk with five turns left to go. And the same arithmetic explains why a 429 is most expensive exactly when it hurts most — late in a long task, where both the accumulated spend and the context you are about to lose are at their largest.

For the same reason, a naive failover — “retry on a different key, or a different region, or a different model” — is rarely the cheap escape it looks like. Every one of those is a different cache. Anthropic scopes cache entries per model, and notes that rate limits are “currently shared across all inference_geo values”, so switching region does not even buy you a fresh limit; it just costs you the prefix.

Not every 429 means “wait”

Here is where retry wrappers lose money silently. At Anthropic, a 429 can mean three different things, and only one of them is worth retrying at all:

The spend-cap case is the expensive one, because it looks exactly like the retryable case at the status-code level. Anthropic is direct about what happens next: “Retrying, including the SDKs’ automatic retries, fails until access resumes.” If your organization hits its cap on the third of the month, every retry your fleet issues for the next four weeks is guaranteed to fail.

OpenAI splits the same idea across four codes — credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceeded and organization_usage_limit_exceeded — all returning 429 under type insufficient_quota, with a matching warning: “Retrying billing, spend, or quota errors won’t restore API access. Update the relevant credits or limits before sending another request.”

The rule that falls out: branch on the error code, never on the HTTP status. And treat the absence of a retry-after header as a stop signal rather than a licence to pick your own delay.

Why you get 429s while under your limit

Three documented reasons, none of which appear in a limits table:

• The window is shorter than a minute. Anthropic uses a token-bucket algorithm and warns that “a rate of 60 requests per minute (RPM) might be enforced as 1 request per second.” SpaceXAI makes it explicit, deriving its per-second ceiling from your per-minute budget: “You cannot spend a full minute’s requests in a single second, which protects the API from sudden bursts.”
• Acceleration limits. Both vendors throttle the derivative, not just the level. Anthropic: “if your organization has a sharp increase in usage, you might see 429 errors because of acceleration limits.” OpenAI returns a dedicated slow_down code for the same thing. Ramping a new workload from zero to your full limit will fail even though the limit is yours.
• Scope. Google applies limits “per project, not per API key”, so provisioning extra keys buys nothing. Anthropic scopes to the organization, with optional per-workspace sub-limits, and returns the most restrictive one in the anthropic-ratelimit-tokens-* headers.

The asymmetry your code cannot see: max_tokens

Two vendors, opposite rules, identical-looking code.

OpenAI: “Your rate limit is calculated as the maximum of max_tokens and the estimated number of tokens based on the character count of your request.”

Anthropic: “OTPM rate limits are evaluated in real time as output tokens are produced, counting only the actual tokens generated. The max_tokens parameter does not factor into OTPM rate limit calculations, so there is no rate limit downside to setting a higher max_tokens value.”

So a defensive max_tokens — the kind everyone sets once and forgets — is free on one API and a throughput tax on the other. For a request with a 2,000-token prompt that actually produces 500 tokens:

If you are getting 429s on OpenAI with plenty of apparent headroom, this is the first thing to check — you may be reserving twenty-five times the throughput you consume. Anthropic has its own caveat in the opposite direction: a large max_tokens without streaming risks idle-connection timeouts, and the SDKs actively validate that non-streaming requests are not expected to exceed ten minutes.

What you can buy, and what you can’t

The instinct when you hit a wall is to pay to move it. That option has narrowed.

Anthropic’s Priority Tier is closed. The service-tiers documentation now opens with a warning: “Priority Tier capacity commitments are no longer available for purchase.” Existing commitments run to their contract end date. Even while it was on sale it excluded Claude Opus 5, Sonnet 5, Fable 5.1 and the Mythos models — that is, the entire current frontier. And it would not have solved a rate-limit problem anyway, because “requests assigned Priority Tier pull from both the Priority Tier capacity and the regular rate limits. If servicing the request would exceed the rate limits, the request is declined.” You could buy prioritisation against overload; you could not buy your way past your own limit.

OpenAI still sells speed, at exactly double. Fast mode (formerly priority processing) on GPT-5.6 Sol is $8.00 input, $0.80 cached input and $40.00 output per million, against $4.00, $0.40 and $20.00 on the standard lane. Cached-input discounts still apply.

The lane that genuinely sits outside your limits is Batch. At OpenAI, Anthropic and SpaceXAI, batch requests do not consume your standard rate limits — which makes moving bulk work asynchronous the one move that buys back synchronous headroom without a tier increase. We costed when that trade is actually worth taking in the batch API discount; the short version is that it is not automatic once prompt caching is in play. OpenAI’s Flex lane is the interesting middle: priced identically to Batch ($2.00 / $0.20 / $10.00 on Sol) but synchronous, paying for the discount with capacity risk instead of latency.

And one vendor simply refuses to send you a 429 for capacity at all. DeepSeek rate-limits concurrency, but when it is busy it does not reject you — it holds the connection: “Non-streaming requests: Continuously return empty lines; Streaming requests: Continuously return SSE keep-alive comments.” If inference has not started within ten minutes, the server closes it. That is not a free lunch, it is a different currency: instead of paying for retries and lost caches, you pay in occupied workers and stalled agents. Worth knowing before you write a client that treats a silent connection as a hang.

The checklist

1. Branch on the error code, not the status. A 429 with no retry-after is usually a wall, not a queue. Check error.details.error_code at Anthropic and the insufficient_quota family at OpenAI before retrying anything.
2. Cap your retries by your cache TTL, not by a round number. For a five-minute window and doubling backoff from one second, eight attempts is the boundary. Past that, requeue rather than retry.
3. Prefer jitter, and desynchronise fan-out. Caches warmed together expire together; ten workers recovering in lockstep can exceed the limit on the retry alone.
4. Treat cache hit rate as a throughput metric. Cache reads are excluded from Anthropic’s ITPM and cache writes are not, so a 101x swing in rate-limit consumption sits behind the same lever that controls your bill. Anthropic’s Usage page charts the cache rate next to the limit for this reason.
5. Audit max_tokens on OpenAI. It reserves throughput you may not use, up to 25x. On Anthropic it costs nothing — but pair a large value with streaming.
6. Do not fail over to a different model, key or region reflexively. Every one of those is a cold cache, and at Anthropic a different region is not even a different limit.
7. Move anything that can wait to Batch. It is the only lane that reliably does not consume your synchronous limits.
8. Watch the headers you already receive. anthropic-ratelimit-input-tokens-remaining and x-ratelimit-remaining-tokens are on every successful response. Throttling yourself at 80% of the limit is cheaper than discovering it at 100%.

The theme underneath all eight is the same one we keep arriving at from different directions. A rate limit is not a separate discipline from cost control — it is the same prefix, measured in a different unit. The cache hit rate that decides your bill also decides your throughput, and the price you pay for an agent is set by the same history you are trying not to re-send. A 429 just tells you, loudly and for free, that you have been re-sending it.

Sources, each read for this article on 19 September 2026: Anthropic rate limits, errors, service tiers, prompt caching and streaming; OpenAI rate limits, error codes, flex processing and pricing; Google Gemini rate limits; SpaceXAI rate limits; DeepSeek rate limits. Model rates from our snapshot, re-verified against Anthropic’s pricing page and OpenAI’s pricing table on the same day. Rate-limit tiers and lane availability change often — see our methodology for how we re-verify, and corrections for what we have got wrong.