Rate limit is exceeded Try again in 10 seconds azure openai

Not specified by the original author.

Rate limit is exceeded. Try again in 10 seconds. (Azure OpenAI 429)

TL;DR

Your deployment blew through its tokens-per-minute quota. Honor the retry hint, back off, and if it keeps happening, request a quota increase for the model in the Azure portal. Retrying faster just extends the pain.

The error

Rate limit is exceeded. Try again in 10 seconds.

(HTTP 429 from the Azure OpenAI endpoint.)

Fix it

1. Read the number in the message and wait at least that long before retrying. Expected: the next attempt has a chance instead of a guaranteed 429.
2. Add exponential backoff with jitter to the calling code. Expected: bursts smooth out and the error rate drops.
3. Check current usage: Azure portal, your OpenAI resource, Quotas. Expected: you see the TPM limit and how close you are.
4. If you consistently hit the ceiling, request a quota increase: portal, Quotas, select the model and region, request more TPM. Expected: the increase is approved and the errors stop.
5. Split load across regions or deployments if one quota pool is too small. Expected: per-deployment TPM stays under the limit.

When to use this

• An agent sees "Rate limit is exceeded. Try again in N seconds." from Azure OpenAI.
• Embedding or chat workloads that run fine at low volume and 429 under load.

When NOT to use this

• 400 context-length errors. Those never succeed on retry; this one does.
• 401 or 403 errors. Those are keys and access, not quota.

Compatibility

• Azure OpenAI Service, all models. Quotas are per model, per region, per subscription.

Variant phrasings

• "Rate limit is exceeded. Try again in 20 seconds."
• "429 Too Many Requests" on the Azure OpenAI endpoint
• "You exceeded your current quota"

Root cause

Azure OpenAI throttles per deployment on tokens per minute and requests per minute. The message names the wait because the throttle is time-based: the bucket refills and the next attempt succeeds. Chronic 429s mean the quota is simply too small for the workload, which is why the Microsoft Q&A thread's accepted resolution was a quota increase.

Edge cases

• Batch embedding jobs can 429 one minute and pass the next. That is normal; backoff handles it.
• Different models have separate quotas. Raising GPT-4o quota does nothing for your embedding model's 429s.

Microsoft Q&A thread 1867144 ("An error occurred when calling Azure OpenAI server", resolved): the caller hit "Rate limit is exceeded. Try again in 10 seconds." on Azure OpenAI. The accepted resolution was requesting more quota: increasing the TPM and rate limit for the deployment fixed the issue. This confirms the error is quota exhaustion on tokens per minute, and the durable fix for recurring hits is a quota increase in the Azure portal, not code changes.

Not specified by the original author.

TL;DR

If absent, use exponential backoff with jitter and cap total attempts and total time. Check the x-ratelimit-remaining-* headers to see whether you are bound on requests or tokens, and pace the bottleneck.

Steps

1. The error: HTTP 429, type ratelimiterror. Meaning: too many requests or tokens in the window. RPM, TPM, RPD, TPD, and IPM can each trigger it; whichever fills first wins.
2. What the agent should do:
3. If Retry-After is present, wait at least that long before retrying. If absent, use exponential backoff with jitter and cap total attempts and total time.
4. Reduce concurrency and batch size. Unsuccessful requests count against the per-minute limit, so hammering a 429 makes it worse.
5. Check the x-ratelimit-remaining-* headers to see whether you are bound on requests or tokens, and pace the bottleneck.
6. Remember limits are per organization and per project, not per user or per key. Adding keys or teammates does not raise the ceiling; check what else in the org is consuming quota.
7. The trap: retrying immediately in a tight loop, or spreading load across multiple keys thinking each gets its own limit. Both keep you throttled. Also never retry billing/quota 429s; those need credits or limit changes, not pacing.
8. Evidence: https://platform.openai.com/docs/guides/rate-limits https://platform.openai.com/docs/guides/error-codes

When to use

You are seeing this: The error: HTTP 429, type ratelimiterror. Use this skill when you run into "OpenAI 429 rate limit: honor Retry-After, limits are per org not per key".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Remember limits are per organization and per project, not per user or per key.
• Also never retry billing/quota 429s; those need credits or limit changes, not pacing.

Sources

• https://platform.openai.com/docs/guides/rate-limits
• https://platform.openai.com/docs/guides/error-codes

Verified against official OpenAI docs 2026-09-26.

Not specified by the original author.

TL;DR

Fixed-interval retries from many workers synchronize into thundering herds; jitter spreads the load.

When to use

You are seeing this: Read the headers on every response: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests, and the token equivalents. Use this skill when you run into "Survive OpenAI rate limits: read the headers, honor Retry-After, back off with jitter".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Rate limits as a protocol

The steps

1. Read the headers on every response: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests, and the token equivalents. These tell you exactly where you stand; guessing from error counts is worse.
2. Honor Retry-After when it is present. It is the minimum seconds to wait before retrying. Ignoring it and retrying anyway is how a 60-second slowdown becomes a ban-shaped problem.
3. Back off exponentially with jitter on 429s. Fixed-interval retries from many workers synchronize into thundering herds; jitter spreads the load.
4. Cap retries and fail visibly. A request that has retried five times should surface an error to the caller, not spin forever. Infinite retry loops are how one slow dependency takes down your whole app.
5. Separate bulk work from interactive work. Anything that can wait 24 hours belongs in the Batch API, which has its own higher rate limit pool and half the cost. Do not burn interactive quota on backfills.
6. Plan tier headroom before launch. Know your usage tier's limits, and load-test at 2x expected traffic. Finding the limit in production is the expensive way to learn it.

The trap

Retrying aggressively on 429 without reading Retry-After, or treating rate limits as someone else's problem. The headers are a contract; code that ignores them gets throttled harder.

Checklist

• Headers parsed on every response, remaining counts tracked.
• Retry-After honored whenever present.
• Exponential backoff with jitter, retries capped.
• Bulk work routed to Batch, not the interactive pool.
• Tier limits known and load-tested before launch.

OpenAI's rate limits guide documents the Retry-After and x-ratelimit-* headers and their meanings. Verified live at https://developers.openai.com/api/docs/guides/rate-limits.