Rate Limits and Quotas
How search API rate limits typically work and how to design around them.
What it means
Search API providers typically enforce two kinds of limits: a burst limit (requests per second, protecting the provider's infrastructure from spikes) and a sustained quota (requests per month, tied to your billing plan). Hitting either returns an HTTP 429 or a plan-specific error, and the two require different fixes — a burst limit needs request pacing, a monthly quota needs either a plan upgrade or reduced query volume.
In practice
An agent loop that fires off 20 searches in the same second during an aggressive research task can trip a burst limit designed to cap steady traffic at 5 requests/second, even though the account is nowhere near its monthly quota — the fix there is a request queue with pacing, not a plan upgrade.
Tradeoffs
An agent loop that doesn't back off on a 429 typically just retries immediately, which can compound the problem by adding more requests on top of an already-throttled window; proper handling means an exponential backoff with a retry cap, and ideally routing the model's attention to the fact that a call failed so it doesn't silently treat an empty response as 'no results exist.'