Agent skill · software engineering · jeremylongshore
firecrawl-rate-limits
Implement bounded Firecrawl throttling and retry behavior using current team RPM, browser concurrency, queue status, timeouts, and Retry-After. Use when handling 429s or producer backpressure. Trigger with "Firecrawl rate limits", "Firecrawl throttling", or "Firecrawl queue".
Why this skill is useful
Adds executable scripts for Firecrawl API rate limiting and queuing that are not available in public documentation.
What it needs
Requires @mendable/firecrawl-js, p-queue installed locally. Requires firecrawl account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Firecrawl Rate, Concurrency, and Queue Control Overview Control request production and page-processing concurrency as different resources. Derive limits from the current team plan and live queue evidence, not copied constants. Prerequisites The target repository or integration path and the requested operator outcome. The source authorization, data classification, and environment policy. Current Firecrawl documentation, credentials only when needed, and an owner for approvals. Current Contract Firecrawl documents per-team request-per-minute limits and concurrent browser limits. All keys on one team share rate counters. Work beyond browser capacity can queue, queue wait counts toward timeout, and excessive queued jobs can return 429. The error catalog says to honor Retry-After when present; batch shares crawl limits. Authentication For authenticated Cloud operations, inject FIRECRAWLAPIKEY from an approved secret manager. REST requests use Authorization: Bearer with the key. Never print, commit, transmit, or place a key in a URL. Keyless access is suitable only where the current documentation explicitly allows it and the workload accepts its limits; production workflows should make identity and team ownership explicit. Instructions 1. Read the current rate-limit documentation and team configuration for the exact operation; record the evidence timestamp without embedding plan numbers in code. 2. Model submission RPM, in-flight browser work, Firecrawl queue, application backlog, target-origin limits, and credit ceiling separately. 3. Use a bounded token bucket or equivalent for submissions and a bounded worker pool for jobs. Keep crawl/batch maxConcurrency within the approved envelope. 4. On 429, inspect error classification and Retry-After. Pause the relevant producer, add jitter, cap attempts and total wait, and preserve idempotency. 5. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/firecrawl-rate-limits