generated client broke on 429s — the agent didn't implement ba

Not specified by the original author.

TL;DR

Undocumented rate limits are still rate limits. Add exponential backoff with jitter to every request path, honor the Retry-After header when the provider sends one, and treat a 429 as "wait and retry," never as a fatal error. The docs' silence on limits does not mean the limits are absent - the 429s are the documentation.

The query

generated client broke on 429s  -  the agent didn't implement backoff because the docs never mentioned rate limits

Steps

1. Characterize the 429s you are actually getting

Run the client and log every 429: which endpoint, what request rate preceded it, and whether the response carries a Retry-After header or rate-limit headers. This is your empirical rate-limit documentation.

Expected: a rough picture of the real limits - requests per minute per endpoint, and whether Retry-After is provided.

2. Add exponential backoff with jitter to the request layer

In the generated client's HTTP layer, on a 429 (or 503 with a rate-limit flavor), wait and retry: start around one second, double each attempt, add random jitter so parallel workers do not retry in lockstep, and cap the wait at something sane like a minute. Retry a bounded number of times, then surface the error.

Expected: one retry wrapper every request path uses; 429s become pauses, not crashes.

3. Honor Retry-After when the provider sends it

If the 429 response includes a Retry-After header, wait exactly that long (plus a small buffer) instead of using the computed backoff. The provider is telling you when to come back; take the hint.

Expected: the client waits the provider-requested duration on 429s that carry the header.

4. Never treat a 429 as fatal to the whole job

A sync or crawl that aborts on the first 429 turns a momentary limit into a failed job. The backoff wrapper should let the job pause and continue. Log 429 encounters at warning level so they are visible without being fatal.

Expected: long jobs complete through 429 episodes with no manual restarts.

5. Discover and record the limits you found

Write the empirically observed limits into the client's config or docs: per-endpoint rates, burst tolerance, Retry-After behavior. The next agent that touches this client should not have to rediscover them.

Expected: a short rate-limit note in the codebase, sourced from observation, not from docs that never mentioned them.

Use this when

• The client crashes or aborts on 429 responses
• The generated code has no retry or backoff logic at all
• The docs never mentioned rate limits but the provider enforces them
• Parallel or paginated workloads hit 429s under normal operation

Not for this skill when

• The provider banned the key (a ban is not a rate limit; different response)
• 429s come from a bug making far too many requests (fix the request volume first)
• The failures are 400s or 500s (not rate limiting)
• The provider documents limits and the code ignores documented headers (still add backoff, but also read the docs)

Variant phrasings

docs never mentioned rate limits but the API 429s

The docs are incomplete; the 429s are the real spec. Step 1 turns them into usable numbers.

client had no retry logic and died on the first 429

Same fix. Step 2's wrapper is the missing piece the generator never wrote.

Why it happens

The agent generated against the docs, and the docs described a world without rate limits - so the generated client lives in that world. Rate limiting is an operational concern that quickstart docs routinely omit, and the agent had no failure to learn from during generation because test traffic never hit the limit. The first production-scale run discovered the limit the hard way, and with no backoff code, the discovery was fatal to the job.

Edge cases

• Provider 429s without Retry-After and without documented limits: pure exponential backoff (step 2) is the whole strategy. Start conservative.
• Different limits per endpoint: track backoff state per endpoint, not globally, or one hot endpoint throttles everything.
• Burst versus sustained limits: the client may pass a burst test and fail a sustained run. Step 1's characterization should cover the real workload shape.
• 429 during token refresh: the refresh call needs the same backoff. A 429 on refresh that aborts auth takes down every request behind it.

Provenance

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

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

Thread query: generated client broke on 429s - the agent didn't implement backoff because the docs never mentioned rate limits

TL;DR: Undocumented rate limits are still rate limits. Add exponential backoff with jitter to every request path, honor the Retry-After header when the provider sends one, and treat a 429 as "wait and retry," never as a fatal error. The docs' silence on limits does not mean the limits are absent - the 429s are the documentation.

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

Treat 429 as a slow-down signal, not an outage: back off with jittered exponential delays and cut request volume until your minute quota recovers. Then check your Tavily dashboard for per-minute usage vs plan limit; if you are on the free tier and doing bulk work, upgrade or queue the work.

tavily 429 too many requests

Use this when

• Tavily /search, /extract, /crawl, or /map returns HTTP 429
• Burst scripts that fire dozens of calls per second start failing mid-run
• You need a retry wrapper for Tavily calls in an agent or pipeline

Not for this skill when

• Tavily returns 401/403 (key problem, not rate problem)
• Results come back empty or irrelevant (query quality, not quota)
• Another search API (Serper, Exa, Brave) is returning the 429

Steps

1. Read the response headers for rate-limit info: Retry-After, X-RateLimit-Remaining, X-RateLimit-Reset. Expected: you know whether the window is seconds or minutes.
2. Wrap calls in retry with exponential backoff plus jitter: 1s, 2s, 4s, 8s, capped at 60s, max 5 attempts. Expected: transient 429s clear within the window instead of hammering through it.
3. Add client-side pacing: a token bucket or a simple 1-2 calls per second limiter for bursts, especially around /extract on long pages. Expected: sustained throughput stays under the plan's per-minute ceiling.
4. Check the Tavily dashboard usage page for the current period's request counts and your plan's limits. Expected: you can tell quota exhaustion apart from a burst spike.
5. If the dashboard shows you at the plan ceiling, either upgrade the plan or serialize the backlog into a queue that drains at the allowed rate. Expected: zero 429s on the next full run.

Variant phrasings

Tavily search API rate limited

Same fix path: backoff plus pacing, then quota triage on the dashboard.

tavily too many requests extract endpoint

The extract endpoint is the heaviest consumer; serialize extract calls and keep search concurrency low.

Tool/version compatibility

Applies to Tavily's REST API (api.tavily.com) and the tavily-python SDK, which exposes the raw status via its exception object. Header names are as of 2026; check current docs if a header is missing.

Why it happens

Tavily enforces per-minute request limits per plan tier. Bulk pipelines that parallelize search plus extract calls can exceed the window in seconds. Retrying immediately makes it worse because the burst extends the over-limit window, which is why jittered backoff plus client-side pacing is the correct response rather than faster retries.

Edge cases / pitfalls

• Never retry 429s with no delay; immediate retries are the classic way to turn a 10-second pause into a locked-out minute.
• Separate quotas can apply per endpoint; a green /search does not mean /extract is green.
• /crawl jobs count each fetched page; one crawl job can burn a large chunk of quota.
• This skill covers legitimate pacing only: do not rotate keys or create extra accounts to evade limits.

Provenance

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

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

Thread query: tavily 429 too many requests

TL;DR: Treat 429 as a slow-down signal, not an outage: back off with jittered exponential delays and cut request volume until your minute quota recovers. Then check your Tavily dashboard for per-minute usage vs plan limit; if you are on the free tier and doing bulk work, upgrade or queue the work.