Q.429 Too Many Requests: what it means and how long to wait

A 429 is the provider setting the speed limit for its road. Fair enough, it is their road. The trouble is that most APIs never post the sign: when we sent one request to 17 public APIs, only 3 told us the limit in their headers before we hit it. So the fix is yours to build.

Key numbers

What a 429 actually says

The code comes from RFC 6585, written by Mark Nottingham and Roy Fielding in April 2012: the user "has sent too many requests in a given amount of time". The response may include a Retry-After header, and it must not be cached.

Just as important is what the standard leaves out. It "does not define how the origin server identifies the user, nor how it counts requests." Every API decides for itself whether it counts per key, per account, per IP address, per endpoint or per model, and over which window. That is why the same code means "slow down for a second" on one API and "come back in an hour" on another.

How long to wait

Read the response before you retry. In order of preference:

1. Retry-After. Per RFC 9110, it is either a whole number of seconds (Retry-After: 120 means 2 minutes) or an HTTP date. OpenAI's docs say to treat it as a minimum and add a small random delay so many clients do not retry at the same instant.
2. A reset header. GitHub sends x-ratelimit-reset as a Unix time in seconds; when x-ratelimit-remaining is 0, wait until then. Anthropic sends anthropic-ratelimit-requests-reset as an RFC 3339 time. Paste a Unix value into our timestamp converter to read it.
3. A body field. Discord puts retry_after (a float in seconds) in the JSON body as well as the header. Stack Exchange reports quota_remaining in every response body.
4. Nothing. Back off exponentially with full jitter (a random wait between zero and a growing cap), and give up after a set number of tries. GitHub's docs say to wait at least one minute for a secondary limit, and warn that continuing to hammer "may result in the banning of your integration".

Here is the whole policy in a few lines of Python:

import random, time, email.utils, requests

def get(url, tries=6, cap=60):
    for attempt in range(tries):
        r = requests.get(url, timeout=30)
        if r.status_code != 429:
            return r
        ra = r.headers.get("Retry-After")
        if ra and ra.isdigit():
            wait = int(ra)
        elif ra:
            wait = max(0, email.utils.parsedate_to_datetime(ra).timestamp() - time.time())
        elif r.headers.get("x-ratelimit-remaining") == "0":
            wait = max(0, int(r.headers["x-ratelimit-reset"]) - time.time())
        else:
            wait = random.uniform(0, min(cap, 2 ** attempt))
        time.sleep(wait + random.uniform(0, 1))  # jitter so clients spread out
    raise RuntimeError(f"still rate limited after {tries} tries")

What we found when we asked 17 APIs

On October 25, 2026 at 2:10 PM ET we sent one plain GET, with no token, to 17 public APIs and recorded every rate-limit header that came back.

Our header survey, Oct 25 2026, 2:10 PM ET. Full list with the raw headers in the data file on this page.

• GitHub sent x-ratelimit-limit: 60, remaining: 59 and a reset exactly one hour after our first call: a fixed hourly window.
• GitLab used the newer header style without the x- prefix (ratelimit-limit: 500, ratelimit-name: throttle_unauthenticated_api) with a reset at the top of the next minute.
• Docker Hub sent x-ratelimit-limit: 3000, 3000;w=60: 3,000 requests per 60-second window.
• Stack Exchange sent no headers but put quota_max: 300 in the JSON body.
• crates.io, npm, PyPI, Wikipedia, Hacker News, SEC EDGAR, Kalshi, Open-Meteo and CoinGecko sent nothing about limits. Some publish a policy in their docs instead (SEC EDGAR's is a maximum of 10 requests a second), so the limit lives in a web page your code never reads.
• Reddit answered our scripted request with a 403 and retry-after: 0; Anthropic and OpenAI answered 401 without a key, as expected.

Ten of the 14 that served us gave no machine-readable hint at all. The provider knows your budget to the request; you find out by being rejected.

Why retrying harder backfires

In our exponential backoff test we fired 100 LLM-style calls at once at a token bucket that allows a burst of 20 and refills 10 a second. Every retry policy eventually got through, but each one paid for it in rejections: 210 to 308 429s for 100 answers, two to three rejections for every success. Honoring Retry-After finished all 100 in 11.8 seconds. A client-side limiter that simply sent requests at the refill rate finished in 8.0 seconds and drew zero 429s.

Which errors to retry, from Anthropic's errors and rate-limit docs; the 429-without-retry-after rule rechecked Oct 25 2026. From our backoff article, Oct 18 2026.

The lesson generalizes: if you know the limit, pace to it. Retries are for the surprises.

Common misconceptions

What this means for you

Treat rate limits as a budget you manage, not an error you catch. Read the provider's published limits, put a limiter in front of your own requests at that pace, honor Retry-After and reset headers, and cap your retries. For LLM apps, the backoff deep dive has the full test and the circuit breaker results, and the LLM proxy benchmark covers what sits between your app and the provider. Before you ship an AI feature, our $14 AI App Ship Kit prices your API bill per request across 26 models and runs an 18-point deploy risk check; we keep fixing it at no extra cost until it does what it promises.

Related

• Exponential backoff with jitter: 64 of 100 LLM calls failed: the parent test.
• What is prompt caching?: the other lever on the LLM bill.
• Claude Code vs Codex outages.
• Unix timestamp converter and LLM API cost calculator.

FAQ

What does 429 Too Many Requests mean?

It is the HTTP status code a server sends when you have made too many requests in a given amount of time, which is called rate limiting. It was defined in RFC 6585 in April 2012. The server may add a Retry-After header saying how long to wait. Nothing is broken on your side except the pace.

How long should I wait after a 429?

If the response has a Retry-After header, wait at least that long: it is either a number of seconds or an HTTP date. If it has a reset header instead (x-ratelimit-reset on GitHub, a Unix time in seconds), wait until that time. If it has neither, back off exponentially with random jitter; GitHub's docs say to wait at least one minute for its secondary limits.

Is a 429 error my fault?

It means you sent requests faster than the server allows for your key, account or IP address. Sometimes the cause is other traffic sharing your IP or key. Retrying immediately makes it worse: in our test, aggressive retries drew up to 308 rejections to finish 100 calls, while pacing requests on the client drew 0.

What is the difference between 429 and 503?

A 429 says you are over your own limit. A 503 says the server is unavailable for everyone. Both can carry Retry-After. Some APIs use their own codes: Anthropic returns 529 overloaded_error when the whole API is busy.

Should I retry every 429?

No. Some 429s are not temporary. Anthropic returns a 429 with no retry-after header when an organization hits its monthly spend limit, and retrying fails until access resumes. Read the error body before retrying, and cap the number of attempts.

Sources

All checked October 25, 2026.

Standards

• IETF, RFC 6585: Additional HTTP Status Codes, section 4, by Mark Nottingham and Roy T. Fielding, April 2012: the 429 definition, the optional Retry-After header, no caching, and that the RFC does not define how servers identify users or count requests.
• IETF, RFC 9110: HTTP Semantics, section 10.2.3, June 2022: Retry-After as an HTTP date or delay-seconds.
• MDN, 429 Too Many Requests.

Provider docs

• GitHub, Rate limits for the REST API: 60 requests an hour unauthenticated, 5,000 with a token, 100 concurrent requests, 403 or 429 on a limit, retry-after then x-ratelimit-reset then at least one minute, the banning warning.
• Anthropic, Rate limits and Errors: token bucket, retry-after and anthropic-ratelimit headers, the spend-cap 429 with no retry-after and error_code enforced_spend_limit_reached, 529 overloaded_error.
• OpenAI, Rate limits: x-ratelimit headers, treat Retry-After as a minimum and add a small random delay.
• Discord, Rate limits: retry_after in the body, 50 requests a second global limit, 10,000 invalid requests per 10 minutes.
• SEC, Accessing EDGAR data: maximum 10 requests a second.

Our data

• Header survey: one unauthenticated GET to each of 17 public APIs (GitHub, Reddit, crates.io, npm, PyPI, Hacker News Firebase, HN Algolia, Wikipedia REST, Stack Exchange, GitLab, Docker Hub auth, Open-Meteo, CoinGecko, Kalshi, SEC EDGAR, Anthropic, OpenAI) on October 25, 2026 at 2:10 PM ET with a descriptive User-Agent, recording status and every rate-limit header. Raw results in data.csv on this page.
• Retry test: herd.cpp from Exponential backoff with jitter, 100 calls against a token bucket with burst 20 and 10 per second, 3 runs per policy, October 18, 2026 7:14 to 7:17 PM ET.

Images

• Charts by Tensorust from the data above; the what-to-retry table is from the backoff article (Oct 18 2026).