Agent skill · software engineering · jeremylongshore
serpapi-rate-limits
Discover SerpAPI account throughput and allowance dynamically, then enforce admission, concurrency, and retry budgets. Use when preventing 429s or coordinating search workers. Trigger with "configure SerpAPI rate limits".
Why this skill is useful
Provides specific implementation patterns and scripts for managing SerpApi rate limits and credit usage that the AI wouldn't reliably generate on its own.
What it needs
Requires p-queue, serpapi installed locally. Requires serpapi account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
SerpAPI Capacity and Rate-Limit Control Overview Use the account's live contract as the source of truth instead of embedding plan names or numeric limits in code. Prerequisites Workload arrival rate, burst size, latency objective, search budget, and job priority Access to the Account API and ownership of all workers sharing the key Metrics for attempts, successes, cached results, 429s, latency, and searches left Tool Discipline Use Read, Glob, and Grep to inventory producers and retry loops, WebFetch to verify current Account API and status semantics, Write or Edit for admission controls and observability, and Bash(python3:) for an approved capacity check or load simulation. Current Contract Account API returns fields including plansearchesleft, totalsearchesleft, thishoursearches, and accountratelimitperhour. HTTP 429 can mean the hourly throughput limit was exceeded or the account ran out of searches, so the response alone does not identify the remedy. Authentication Use a server-side SERPAPIKEY for Account API and search calls. Centralize capacity across every workload sharing that credential; do not expose account fields or the key through a public health endpoint. Instructions 1. Enumerate every producer, schedule, priority, concurrency setting, retry policy, and credential-sharing boundary. 2. Read current account capacity and renewal facts from Account API; treat configured limits as refreshable state. 3. Reserve headroom for interactive and incident traffic and translate the remaining capacity into per-worker admission budgets. 4. Apply a shared concurrency limiter and queue; reject or defer low-priority work before sending excess requests. 5. On 429, pause new admissions, refresh Account API, then classify throughput exhaustion versus search exhaustion. 6. Retry only when the classification and reset policy justify it; cap attempts and add jitter to avoid synchronized bursts. 7. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/serpapi-rate-limits