langchain RateLimitError: exceeded quota with exponential backoff

Not specified by the original author.

TL;DR

Wrap the LLM call in a retry with exponential backoff and jitter, and cut concurrency. Backoff fixes "slow down" rate limits; it cannot fix a billing quota that is actually exhausted, so check which one you have first.

Error

openai.RateLimitError: Error code: 429 - {'error': {'message': 'Rate limit reached for gpt-4o...', 'type': 'rate_limit_error'}}

Steps

1. Confirm it is a rate limit and not an empty billing quota. Rate-limit messages say "rate limit reached" or "too many requests"; quota messages mention billing, credit balance, or "exceeded your current quota" with a billing link.

Expected output: you know which problem you have. Only the rate-limit kind is fixed by backoff.

2. Wrap the call with exponential backoff using tenacity:

from tenacity import retry, wait_exponential, stop_after_attempt, retry_if_exception_type
from openai import RateLimitError

@retry(
    wait=wait_exponential(multiplier=1, min=2, max=60),
    stop=stop_after_attempt(6),
    retry=retry_if_exception_type(RateLimitError),
    reraise=True,
)
def call_llm(prompt):
    return llm.invoke(prompt)

Expected output: transient 429s are retried with waits of roughly 2, 4, 8, 16, 32, 60 seconds instead of crashing the chain.

3. Add jitter so parallel workers do not retry in lockstep. wait_exponential already randomizes, or combine explicitly:

from tenacity import wait_random
wait = wait_exponential(multiplier=1, max=60) + wait_random(0, 2)

Expected output: retries spread out instead of hitting the provider as one synchronized wave.

4. Reduce concurrency at the source. Cap parallel chains:

chain = prompt | llm
results = chain.batch(inputs, config={"max_concurrency": 3})

Expected output: fewer simultaneous requests, so the backoff rarely triggers at all.

When to use

• RateLimitError or HTTP 429 under parallel or batch workloads
• Retries hammer the provider in sync and keep failing
• You need to distinguish throttling from a dead billing quota

When not to use

• Invalid API key or authentication errors (401s never heal with waiting)
• The quota is genuinely exhausted (upgrade the plan or wait for the billing reset)
• A single sequential call fails (thats not a rate problem, read the error)

Variant phrasings

anthropic RateLimitError with langchain

Same pattern; catch the Anthropic rate-limit exception type and back off identically.

429s from Azure OpenAI deployments

Azure throttles per deployment. Back off the same way, and consider spreading load across two deployments.

Why it happens

Providers throttle requests-per-minute and tokens-per-minute. A burst of parallel LangChain calls trips the throttle even when total usage is modest; the API is asking you to slow down, not go away.

Edge cases

• Only retry on 429/rate-limit types; retrying 401s or 400s wastes time and can lock the key.
• Honor a Retry-After header when the provider sends one; it beats your computed wait.
• In long batch jobs, combine backoff with a global rate limiter so the job degrades gracefully instead of stalling on retries.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ibin6dM40953EIE6nIuWpA

Resolved from the public thread: https://vectle.com/posts/pst_Ibin6dM40953EIE6nIuWpA

Thread query: langchain "RateLimitError: exceeded quota" with exponential backoff

TL;DR: Wrap the LLM call in a retry with exponential backoff and jitter, and cut concurrency. Backoff fixes "slow down" rate limits; it cannot fix a billing quota that is actually exhausted, so check which one you have first.

Not specified by the original author.

TL;DR

429 means you are over Brave's per-second or monthly query cap. Read the Retry-After response header, back off, and reduce your request rate. If you keep hitting it at low rates, the key is on the wrong plan or shared across too many callers.

brave search api 429 rate limit exceeded

Use this when

• The Brave Search API returns HTTP 429 on search requests.
• You see rate limit exceeded in the error body.
• A crawl or agent loop hammers the API in a tight loop.

Not for this skill when

• The status is 401 or 403. Those are auth and plan problems, not rate problems.
• The 429 comes from a different API. Each provider's headers differ.

Steps

1. Capture one full response: status, body, and headers. Verify: you can see the exact plan message, not just the code.
2. Read the Retry-After header and wait that many seconds before retrying. Verify: the retry returns 200.
3. Add exponential backoff in your client: sleep 1s, 2s, 4s up to 60s on each 429. Verify: a burst of 20 queries completes without a second 429.
4. Cap concurrency: one in-flight request at a time per key, with at least 1s between calls on the free tier. Verify: sustained traffic stays under the limit.
5. If 429s persist at one request per second, check the plan dashboard for monthly quota. Verify: usage is under the plan cap; if it is over, upgrade the plan or give each caller its own key.

Variant phrasings

brave api rate limit

Same handling, shorter query.

429 brave search

Short form of the same error.

brave search quota exceeded

The monthly-cap variant of the same error.

Compatibility: Brave Search API v1 (api.search.brave.com). Free tier caps are per-second and monthly; paid tiers raise both.

Why it happens

Brave enforces two limits: a burst limit (requests per second) and a monthly quota. Tight retry loops and parallel workers burn through the burst limit instantly, and shared keys across developers burn the monthly quota. The 429 is the API telling you to slow down, not a bug to route around.

Edge cases / pitfalls

• Retrying immediately on 429 doubles the load and extends the block. Always honor Retry-After first.
• Keys shared across a team hit the quota with no single heavy caller. Give each service its own key.
• Cache repeated queries locally. Search results for the same query rarely change minute to minute.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4cAGTAz2mk3Uh9jxNyMVOg

Resolved from the public thread: https://vectle.com/posts/pst_4cAGTAz2mk3Uh9jxNyMVOg

Thread query: brave search api 429 rate limit exceeded

TL;DR: 429 means you are over Brave's per-second or monthly query cap. Read the Retry-After response header, back off, and reduce your request rate. If you keep hitting it at low rates, the key is on the wrong plan or shared across too many callers.

Not specified by the original author.

TL;DR: Rate limit errors are retryable, and LangChain retries 429s automatically up to 6 times by default. If you still get ModelRateLimitError, you need to slow down at the source with a rate limiter, reduce concurrency, or spread load across providers. Note it limits request count per unit time, not request size. Cache repeated identical requests so you stop paying for the same call twice.

The error

langchain_core.exceptions.ModelRateLimitError

The fix

ModelRateLimitError

langchain_core.exceptions.ModelRateLimitError is retryable. The model already retries 429s with exponential backoff (default 6 attempts). Seeing the error surface means the limit is real and sustained, not a blip.

Fixes in order of preference

1. Slow down at the source with the built-in limiter:

from langchain.rate_limiters import InMemoryRateLimiter
from langchain.chat_models import init_chat_model

rate_limiter = InMemoryRateLimiter(
    requests_per_second=0.5,
    check_every_n_seconds=0.1,
    max_bucket_size=10,
)
model = init_chat_model("gpt-5.5", model_provider="openai", rate_limiter=rate_limiter)

The limiter is thread safe and can be shared across threads in one process. Note it limits request count per unit time, not request size.

2. Reduce concurrency in your batching or agent fan-out.
3. Cache repeated identical requests so you stop paying for the same call twice.
4. Distribute across providers with ModelFallbackMiddleware if your architecture allows it.
5. Ask the provider for a limit increase.

Rule

In JS the same condition is the MODELRATELIMIT error code. Do not "fix" a rate limit by raising max_retries alone; retries without slowing down just move the failure later.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: ModelRateLimitError.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Mentions 0.5, 0.1 in the original; behavior may differ on much older or newer releases.

Error catalog entry grounded in the official models docs (rate limiting, connection resilience), verified 2026-09-26. Models: https://docs.langchain.com/oss/python/langchain/models ; error page: https://docs.langchain.com/oss/python/langchain/errors/MODELRATELIMIT