How to fix: 429 rate limit error

How it shows up

The same root cause surfaces in a few different ways. If any of these match, you're in the right place.

• ▸HTTP 429 responses arriving in bursts rather than steadily, often right after a deploy or a batch job starts.
• ▸A retry-after header on the response that client code is ignoring in favour of its own backoff schedule.
• ▸Throughput that plateaus well below the documented limit because retries are consuming the same quota as first attempts.
• ▸One noisy internal job starving a user-facing route, because both share a single API key and therefore a single bucket.

Diagnose it first

Confirm which cause you actually have before changing anything — most wasted time here comes from fixing the wrong one.

Provider-specific behaviour

The error means roughly the same thing everywhere, but each provider signals it differently.

Token limits versus request limits

Most providers enforce both, and long prompts hit the token limit long before the request limit. A workload that sends few but very large requests will be rate-limited while the request-per-minute counter looks comfortable.

Windowing behaviour

Limits are often enforced over a short rolling window rather than a clean calendar minute, so a client that fires its whole allowance at second zero will be throttled for the remainder even though the average is fine. Spreading requests evenly is usually worth more than raising the limit.

What doesn't work

Common fixes for this error that look right and aren't.

• Retrying immediately in a tight loop.

  This adds load exactly when the service is shedding it, extends the throttled window, and on some plans counts against the same quota you are waiting on.

• Using a fixed sleep between retries.

  Every client that hit the limit at the same moment wakes at the same moment, producing a synchronised second wave. Exponential backoff with jitter exists specifically to break that lockstep.

• Asking for a limit increase as the first move.

  It is often the right eventual answer, but a workload that bursts or retries badly will exhaust a higher limit too. Fix the shape of the traffic first, then raise the ceiling against a known profile.

Common variations and related errors

You'll usually hit this same root cause under a few different names. Same fix.

• ▸429 Too Many Requests
• ▸429 rate limit exceeded
• ▸"Rate limit reached"
• ▸"You exceeded your current quota"
• ▸"Requests per minute exceeded"
• ▸"Tokens per minute exceeded" (TPM)
• ▸openai.error.RateLimitError
• ▸anthropic.RateLimitError

Code: drop-in retry helper

A minimal typescript helper that handles the most common version of this error. Copy, paste, adjust the policy to your traffic.

// Drop-in retry helper for 429s with exponential backoff + jitter.
// Use the response's 'retry-after' header when present, fall back to exponential.
export async function callWithRetry<T>(
  fn: () => Promise<Response>,
  parse: (r: Response) => Promise<T>,
  opts: { maxRetries?: number; baseMs?: number; capMs?: number } = {},
): Promise<T> {
  const { maxRetries = 5, baseMs = 500, capMs = 30_000 } = opts;
  let attempt = 0;
  while (true) {
    const res = await fn();
    if (res.status !== 429 && res.status < 500) return parse(res);
    if (attempt >= maxRetries) return parse(res);
    const retryAfter = Number(res.headers.get('retry-after'));
    const backoff = retryAfter > 0
      ? retryAfter * 1000
      : Math.min(capMs, baseMs * 2 ** attempt) * (0.5 + Math.random() * 0.5);
    await new Promise((r) => setTimeout(r, backoff));
    attempt += 1;
  }
}