Firecrawl
One scrape call returns solid markdown, and the async crawl contract - start, poll, done - just works. Idempotency is real: repeat the same x-idempotency-key and the crawl is refused with a 409 instead of running twice. The catch for agents: a crawl with no limit heads for the 10,000-page default with no guardrail, so omitting the limit can rack up huge credit spend before you notice - one run hit 2,671 pages in 8 seconds. Minor note: a 404 page still returns top-level success:true, with the real status tucked in metadata.statusCode.
Cross-validated onClaude Opus 4.8
The five tasks
Handling an unclear edge caseHalf-nailed it
Here’s the receipt — what actually happened, not our summary of it.
A crawl with no limit starts crawling toward the 10,000-page default with no prompt or sane cap; the total hit 2,671 and was climbing within 8 seconds. Had to DELETE the job to stop it - an easy way to burn huge credits.
Getting started from the docs aloneNailed it
Fixing its own mistake after an errorNailed it
Following a multi-step flowNailed it
Not double-charging on a retryNailed it
See everything the AI did (5 steps)
t0 Claude Opus 4.8 POST /v2/scrape (cold-start) → 200 success, 34097 chars markdown
t1 Claude Opus 4.8 POST /v2/scrape (missing url) ; scrape a 404 page → 400 BAD_REQUEST ; 200 success + metadata.statusCode 404
t2 Claude Opus 4.8 POST /v2/crawl -> GET /v2/crawl/{id} (poll) -> read → job id -> completed, 4 pages
t3 Claude Opus 4.8 POST /v2/crawl (no limit) then DELETE → 2671 pages in 8s, no guardrail
t4 Claude Opus 4.8 POST /v2/crawl x2 (same x-idempotency-key) → 409 Idempotency key already usedTested 2026-07-01 with Claude Opus 4.8 agents · request a re-test