OpenAI rate limits: what the 429s mean and how to catch them in your logs

Failure facts checked on the vendor’s docs on Nov 8, 2026.

An OpenAI 429 is a family of errors, not one error. The status code is the same for a burst of requests, a ramp that was too steep and a spend cap that stopped your account. The fix for each is different, so your logs need to tell them apart.

What OpenAI limits

OpenAI's rate limit guide lists five measures: requests per minute (RPM), requests per day (RPD), tokens per minute (TPM), tokens per day (TPD) and images per minute (IPM). You hit a limit when the first of them runs out. Twenty tiny requests can use up an RPM limit of 20 while you are nowhere near your token limit.

Limits belong to your organization and your project, not to a user or an API key. They differ by model, and some model families share one limit that you can see in the console's limits page. Your tier moves up automatically as total credit purchases reach each threshold (Build at $5, Launch at $100, Grow at $500). Batch API jobs have their own queue limit, counted in queued input tokens.

One detail catches teams out: the token estimate for a request uses the larger of max_tokens and an estimate from the request's character count. A large max_tokens on a small prompt spends limit you never use.

The three kinds of 429

Model overload is a separate 503 with code server_is_overloaded. OpenAI notes that slow_down used to come back as a 503 on some endpoints and now returns 429, so an error handler written before that change may classify it wrong.

Headers worth logging

Each response can carry x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests and the same three for tokens. The reset values are durations such as 1s or 6m0s. When a project-scoped token limit applies you also get x-ratelimit-*-project-tokens. A temporary 429 can include Retry-After, which OpenAI describes as the minimum wait.

Log the remaining values on every call, not only on failures. A remaining-tokens value that trends toward zero tells you about a 429 before it happens.

// Log one structured line per attempt, with rate limit headers.
async function errorCode(res: Response) {
  // Gateways can answer with HTML or an empty body; keep the log line either way.
  try {
    return (await res.clone().json()).error?.code ?? null
  } catch {
    return null
  }
}

async function callOpenAI(body: unknown, attempt: number) {
  const started = Date.now()
  const res = await fetch('https://api.openai.com/v1/responses', {
    method: 'POST',
    headers: { Authorization: `Bearer ${process.env.OPENAI_API_KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  })
  const h = res.headers
  console.log(
    JSON.stringify({
      msg: 'vendor call',
      vendor: 'openai',
      status: res.status,
      attempt,
      duration_ms: Date.now() - started,
      remaining_requests: h.get('x-ratelimit-remaining-requests'),
      remaining_tokens: h.get('x-ratelimit-remaining-tokens'),
      reset_tokens: h.get('x-ratelimit-reset-tokens'),
      retry_after: h.get('retry-after'),
      request_id: h.get('x-request-id'),
      error_code: res.ok ? null : await errorCode(res),
    })
  )
  return res
}

What to alert on

• The share of calls answered 429 per model over five minutes. A handful of 429s that clear on retry is normal for a busy account. A share well above the model's usual level, held for several minutes, is not.
• error_code counts. slow_down after a deploy or a batch job start points at your ramp. A spend or credit code is an account problem that needs a person.
• Remaining tokens under 10% of the limit for a sustained period.
• Attempts per successful call. Retries that pile up mean your backoff is not working.

Your bug or their limit

If only one model or one project 429s, the limit is yours: look at what changed in that code path. If many models fail with 503 and server_is_overloaded, that is OpenAI capacity, not your quota, and retrying with delay is the documented response. Check that SDK retries and your own retries are not both active. OpenAI warns that nested loops multiply requests, and its examples set max_retries=0 before adding their own wrapper.

Example: a ramp that was too steep

This is an example, not output from a real project. A nightly job at a made-up service called summarizer-worker raises its concurrency from 4 to 40 at 02

02:00:03Z msg="vendor call" vendor=openai model=gpt-example status=200 attempt=1 remaining_tokens=412000 retry_after=
02:00:41Z msg="vendor call" vendor=openai model=gpt-example status=429 attempt=1 error_code=slow_down remaining_tokens=388000 retry_after=3
02:00:44Z msg="vendor call" vendor=openai model=gpt-example status=429 attempt=2 error_code=slow_down remaining_tokens=391000 retry_after=3
02:00:49Z msg="vendor call" vendor=openai model=gpt-example status=200 attempt=3 remaining_tokens=402000 retry_after=

Remaining tokens are healthy the whole time, which rules out a TPM limit. The slow_down code and the 02

Checklist

1. Log status, error_code, remaining requests and tokens, and retry_after on every attempt.
2. Cap attempts and total retry time, and honor Retry-After plus jitter.
3. Ramp new traffic in steps instead of starting at full rate.
4. Set max_tokens close to the output you expect.
5. Send work that can wait to the Batch API.
6. Treat spend and credit codes as non-retryable.

For the general approach, see monitoring third-party dependencies and vendor degradation. If you track the cost side of model calls, LLM spend spikes covers it. Structured fields like these are easiest to query when your logs are structured. If these lines already reach Sazabi, the agent can watch the 429 share for you.