Scraping is the second most-called category on our router after search, and it has a pricing quirk worth understanding before you pick a vendor: two of the three main providers cost exactly the same, and the third costs about five times more. That is not a rip-off. It is a quality tier, and whether you need it depends entirely on what kind of pages your agent reads.
Here are the three providers we route scrape traffic across, with prices from our catalog. Routed prices are provider list plus 20%; divide by 1.2 for what you would pay going direct.
| Provider | Routed price per 1k pages | Quality score | JS rendering |
|---|---|---|---|
| Jina Reader | $0.36 | 70 | No |
| Spider | $0.36 | 72 | Yes |
| Firecrawl | $1.92 | 85 | Yes |
(Browserbase is in our catalog and coming soon; it is a headless browser platform rather than a fetch-and-convert API, which is its own post.)
1. Jina Reader: the budget default for static pages
Jina Reader does one thing: give it a URL, get back clean markdown. At $0.36 per thousand pages routed ($0.30 list) it ties for the cheapest scrape in our catalog, and for static content it is hard to argue with. Documentation pages, blog posts, news articles, anything that arrives as server-rendered HTML comes back as tidy, LLM-ready text.
The limitation is right there in the design: no JavaScript rendering. If the page builds its content client-side, Jina sees the empty shell, and you get back a page skeleton instead of an article. In my experience that failure is the sneaky kind, because the request succeeds with a 200 and plausible-looking markdown. Whatever scraper you use, check for suspiciously short bodies. We score Jina 70: excellent at its job, but its job has a boundary.
2. Spider: same price, with a JS engine
Spider is the interesting middle option because it costs the same $0.36 per thousand routed as Jina but includes JavaScript rendering. On paper that makes Jina look dominated, and for JS-heavy targets Spider is clearly the better pick at the price. We score it 72, a nudge above Jina, mostly on the strength of that rendering support.
Why not just always use Spider, then? Output polish. Jina’s markdown conversion is the more consistently clean of the two on ordinary article pages, in my experience, and if your pipeline feeds scraped text straight into a context window, cleanliness is worth something. But the honest summary is that Jina and Spider are close substitutes at an identical price, which is exactly the situation where failover between them is free. One fails or returns an empty body, the other catches it, and your cost basis does not move.
3. Firecrawl: the quality tier
Firecrawl is the premium option at $1.92 per thousand pages routed ($1.60 list), and it earns the highest scrape score in our catalog at 85. It renders JavaScript, handles the awkward pages that defeat the budget tier more often, and its markdown output is consistently the best structured of the three. It also has a search endpoint that can return full page content with results, which blurs usefully into the search category (I compare that side of it in the search API roundup).
The question is whether the roughly 5x price gap over Jina and Spider is worth it, and the answer is workload-shaped. If you scrape ten thousand pages a month, the gap between Firecrawl and Spider is about $15.60 routed, which is nothing next to an engineer-hour of debugging half-scraped pages. If you scrape ten million pages a month, it is a $15,600 difference and you will care a great deal about sending only the hard pages to the expensive tier.
How I would route it
The structure of this category practically begs for tiered routing:
- Cheapest-first with failover is the sane default: try the $0.36 tier, fall back when a scrape fails or comes back empty. Our router treats an empty body as a failure, not a success, which matters more in scraping than any other category.
- Quality-first for known-hard targets. If a specific domain always needs rendering and clean structure, pin it to Firecrawl. Saved routing preferences make that a config change rather than a code change.
- Mixed pipelines win on math. Most corpora are mostly easy pages. Paying the Firecrawl premium only on the pages that need it is where the real savings hide, and it is the pattern I see working across traffic on route.tools.
One more note on failure modes: scraping is the flakiest category we route. Sites block, rate-limit, and serve JS walls unpredictably, and the provider that fails on one domain sails through the next. That is why our failover tries up to three providers and why the circuit breaker exists (providers above a 30% error rate over five minutes get skipped). Whatever you build, do not let a single scraper be a single point of failure.
Full side-by-side pricing, generated from the same open catalog the router reads, is on the scraping API comparison page.