Hanad KubatVisit Website →
← Back to blog

OpenAI Rate Limits: How to Check, Handle, and Raise Them

August 22, 2026
OpenAI Rate Limits: How to Check, Handle, and Raise Them

OpenAI enforces rate limits on both requests and tokens, applied at the project, organization, and model level. When you hit one, you get a 429 response: read the Retry-After header, stop firing duplicate retries, and back off with jitter before you touch anything else.

Do these three things first:

  • Read the headers. Check retry-after and the x-ratelimit-* fields on the failed response before you assume anything is broken.
  • Stop the retry loop. If your code or the SDK is already retrying, don't stack a second retry layer on top. That's how a minor throttle turns into a request storm.
  • Confirm it's actually a rate limit. An insufficient_quota error looks similar but means a billing problem, not a temporary limit.

Roughly 80% of OpenAI's revenue comes from ChatGPT subscriptions rather than API traffic, but API demand has grown fast enough that shared capacity is exactly why these limits exist in the first place.

Key Takeaways

Rate limits on requests and tokens are a fixed constraint of the OpenAI API, and the fix is almost always architecture, not a support ticket.

PointDetails
Tokens matter more than requestsTPM is often the real bottleneck, especially for RAG and long-context workloads.
Headers tell you everything livex-ratelimit-remaining-tokens and Retry-After show your real-time state on every response.
Don't stack retriesCheck whether the SDK already retries before adding your own backoff logic on top.
Batch what isn't urgentThe Batch API tracks queued tokens separately, keeping bulk jobs off your synchronous limit.
Tiers rise with spendUsage tiers increase automatically as cumulative spend grows, raising RPM/TPM/RPD ceilings.

Table of Contents

Rate Limits OpenAI Applies: RPM, TPM, RPD, and Shared Pools

OpenAI measures usage across four dimensions: requests per minute (RPM), tokens per minute (TPM), requests per day (RPD), and model-specific ceilings that sit on top of all three. Both tokens and requests count separately, and you can hit either one first depending on your workload.

A few things trip people up here. Chatty, high-volume, low-token endpoints tend to hit RPM first. Long prompts, big context windows, or RAG pipelines pulling in large chunks of retrieved text usually hit TPM first, often well before RPM becomes a problem. In fact, TPM is commonly the actual bottleneck in production systems, which is why token-aware monitoring matters more than raw request counting.

Some limits are shared, not per-model:

  • Model families in the same tier can draw from a shared TPM pool, so a spike on one model reduces headroom on a related one.
  • Long-context models carry their own special limits, separate from standard chat models.
  • The Batch API has its own queue limits, tracked by queued tokens rather than live TPM.
  • Vector store ingestion has a documented cap of 300 requests per minute per vector store ID, which matters if you're bulk-loading embeddings.

Where to Check Your OpenAI Usage Limits

You have two reliable ways to see your current limits: the dashboard, or the response headers on every API call.

  1. Open the Limits page in your OpenAI dashboard. It shows your current usage tier, and the RPM/TPM/RPD ceilings tied to that tier for each model, split by project.
  2. Confirm whether you're looking at project or organization scope. Limits are enforced per project, and a busy sibling project can eat into shared organization capacity without your endpoint ever showing a spike.
  3. Parse the response headers programmatically instead of guessing. OpenAI returns fields like x-ratelimit-limit-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, and x-ratelimit-reset-tokens on every response, not just on errors.
  4. Check whether your SDK already handles Retry-After. The official Python and Node SDKs read this header and back off automatically on a 429, so manual retry logic on top of that can double the wait unnecessarily.

Pro Tip: Log the x-ratelimit-remaining-tokens header on every successful call, not just failures. By the time you see a 429, you've already lost visibility into how close you were running to the edge.

Diagnosing a 429 or RateLimitError

A RateLimitError in the SDK, or a raw 429 status code, means you exceeded a limit on requests, tokens, or both within the current window. The response body usually names which limit tripped, and a Retry-After header may tell you the minimum wait, though OpenAI's error-codes documentation treats that value as a floor, not a fixed delay.

Close-up of inactive network hardware in dark workspace

The error that confuses people most is insufficient_quota. It also returns a 429-style status in some client libraries, but it's a billing problem, not a temporary throttle. No amount of backoff fixes it; you need to add a payment method or raise your spending cap.

A few organizational causes are easy to miss:

  • A shared API key used across multiple services, each unaware of the others' traffic.
  • Multiple projects under one organization quietly competing for the same pooled limit.
  • A deploy or cron job firing a burst of near-simultaneous requests, sometimes called a request storm, that looks like sustained traffic to the API even though it's really one bad loop.

The Help Center's own guidance points at the same recurring culprits: missing payment methods, shared org usage nobody is tracking, and retry logic that doesn't account for what the SDK is already doing.

Fixing It: Retries, Queuing, Batching, and Monitoring

Once you've confirmed it's a genuine rate limit and not a billing issue, the fix is mostly engineering discipline, not a support ticket.

  1. Back off with jitter, not a fixed delay. OpenAI's Cookbook recommends exponential backoff with randomized jitter, using libraries like Tenacity in Python or the backoff package, so that many clients retrying at once don't all land on the same instant.
  2. Respect Retry-After when it's present, and check whether your SDK already retries. Layering your own retry loop on top of the SDK's built in behavior is one of the most common ways teams accidentally double their load during an outage.
  3. Add concurrency limits and a queue. Cap how many in-flight requests your service allows at once, and separate real-time user-facing calls from background jobs so a batch process can't starve a live chat interface.
  4. Batch and trim tokens where you can. Combine multiple small prompts into fewer calls, lower max_tokens when you don't need a long response, and cache repeated context (a system prompt, a RAG chunk, a tool schema) instead of resending it every time.
  5. Move non-realtime workloads to the Batch API. Bulk jobs, overnight processing, and anything that doesn't need a response in seconds should go through batch endpoints, which track queued tokens separately from your synchronous TPM limit.
  6. Instrument everything. Log tokens per request, track a rolling TPM figure, and set an alert well before you approach your ceiling, not after the first 429 shows up in your error tracker.

Pro Tip: Design for tokens first, not calls. A single large retrieval-augmented prompt can burn through your TPM budget faster than a hundred small chat completions, so tune max_tokens and cache embeddings before you worry about request counts.

For workloads under real load, having a fallback path to another provider for time-sensitive traffic is worth building once, even if you rarely need it. It's cheaper than a scramble the first time your primary limit gets hit during a launch.

Workshop bench with hardware and cables for monitoring

How Usage Tiers Work and What a Limit Increase Request Needs

Your organization's usage tier rises automatically as your cumulative spend increases, and each tier maps to higher RPM, TPM, and RPD ceilings. You can see your current tier and its thresholds on the dashboard's Limits page, so check there before assuming you need to file anything manually.

If your usage genuinely outpaces what your tier allows, prepare a specific request rather than a vague one:

  • Your peak RPM and TPM over a representative window, not just an average.
  • A rough token profile: are you sending short chat turns, or large RAG payloads with long context windows?
  • The percentage of requests that reuse cached or repeated context, since that changes how much headroom you actually need.
  • A short business case: what breaks for users if the limit isn't raised, and on what timeline.

While you wait on a decision, the mitigations above (queuing, batching, token trimming) are what buy you room, not a support ticket sitting in a queue.

A Checklist for Staying Ahead of OpenAI's API Throttling

Run through this before you ship anything that calls the API at scale:

  1. Instrument token and request counts per endpoint, and alert at 70 to 80% of your known ceiling.
  2. Implement backoff with jitter, cap total retry attempts, and confirm whether your SDK is already retrying before adding your own layer.
  3. Route bulk or non-urgent work through the Batch API instead of synchronous calls.
  4. Throttle background jobs so they never compete with real-time, user-facing traffic for the same pool.
  5. Before requesting a limit increase, gather a week of traffic samples: peak RPM, peak TPM, and your cached-context ratio.

Patterns I Use in Fixed-Price MVP Builds

Most rate-limit problems I see in early-stage products aren't OpenAI's fault. They're the result of no concurrency cap, no retry discipline, and max_tokens left at whatever the tutorial used. On a fixed-price, fixed-scope build, I don't have room to debug a request storm after handover, so I set conservative defaults from day one: low concurrency, tight token ceilings, and background workers for anything that isn't a live user request.

I only reach for a manual limit increase after I've exhausted the cheaper fix: better batching, caching repeated context, or moving a job off the real-time path. Requesting more headroom is easy. Rebuilding a fragile architecture under pressure later is not.

The prototype is the spec. If it worked in testing but falls over under real traffic, that's not a rate-limit problem, it's an architecture problem wearing a 429 error as a disguise.

Sources

FAQ

Does OpenAI Have a Rate Limit?

Yes. Every OpenAI API account has limits on requests per minute, tokens per minute, and requests per day, scoped to your project and usage tier.

How Do I Increase My OpenAI Rate Limits?

Usage tiers rise automatically as your cumulative spend increases, and each tier unlocks higher RPM/TPM/RPD ceilings; check your current tier on the dashboard's Limits page before requesting a manual increase.

How Do I Handle an OpenAI Rate Limit Error?

Read the Retry-After header, back off with exponential delay and jitter, confirm your SDK isn't already retrying, and check whether the error is actually insufficient_quota rather than a temporary rate limit.

Does OpenAI Allow Adult Content Now?

That's a content policy question, not a rate-limit issue, and it falls outside what this article covers; check OpenAI's usage policies directly for the current rules.

If a prototype built on Bolt, Lovable, or similar tools is hitting these limits because the architecture was never designed for real traffic, that's usually a sign the underlying build needs to be rebuilt, not just throttled. I take the prototype as the spec and rebuild it as real, working code, fixed price, fixed scope, and you own it from the first commit. You can see how that works at Hanadkubat.