By the fastCRW team · Pricing/credit costs verified 2026-05-18 · Verify independently against live /pricing before buying.
Disclosure: We build fastCRW. This is a vendor-authored explainer, so weight it accordingly — but the goal here is to teach you to read any scraping bill, including ours, with clear eyes, and we point out where a usage-metered model genuinely fits better below.
Credit-based pricing for web scraping, defined
Credit-based pricing for web scraping means you buy a bucket of credits on a plan, and every API operation deducts a fixed number of them. A scrape costs 1 credit, a search costs 1, and a JSON extraction is that 1-credit scrape plus a usage-metered LLM token cost, and so on. You forecast spend by counting operations and multiplying. The plan is the meter ceiling: when the bucket empties, you top up or upgrade. This is the dominant model for AI-data APIs because it maps cleanly onto how agents and pipelines actually call the service — one page, one credit.
Pure usage metering bills the underlying resources instead: bandwidth (per GB), compute time (per second), per-request fees, and proxy egress, often summed into a per-call invoice with no fixed bucket. It is the cloud-infrastructure model — you pay for exactly what you consumed, but you cannot read the price of one scrape off a table without knowing the page size, the renderer, and the proxy route first.
What a credit represents
A credit is an abstraction over "one unit of scraping work." Its value comes from being predictable: you can write pages × credits-per-page on a whiteboard and trust it. The risk is that the abstraction leaks — when a single logical operation silently costs 2x, 5x, or 10x credits depending on how the vendor rendered or routed it, the whiteboard math breaks.
What pure usage metering charges for
Metering charges for measurable resources: residential-proxy GB, headless-browser seconds, CAPTCHA-solve events, and per-request overhead. Done well it is exquisitely fair — a tiny static page costs almost nothing. Done carelessly it is impossible to forecast, because the cost of next month's job depends on which sites you hit and how hard they fight back.
Where credit costs hide
The honest weakness of credit-based pricing is the multiplier. Vendors advertise "1 credit per page" on the marketing page, then quietly bill more when the operation is harder. Three places to check before you trust a credit quote.
JS-render and extraction multipliers
JavaScript-heavy pages need a headless browser, which costs the vendor real compute, so most credit models charge a render multiplier. Structured extraction (running an LLM over the page to emit JSON) is even pricier because it adds model-inference cost. fastCRW is explicit about both: every renderer — http, lightpanda, auto, and chrome — costs a flat 1 credit per scrape, and any request with formats: ["json"] (LLM extraction) is that 1-credit scrape plus the LLM token cost, billed as usage-metered LLM credits (fastCRW credit table, README "Renderer selection", verified 2026-05-18). The web leg is flat and published; the extraction's LLM usage is metered by token cost and scales with page size, not a fixed multiple — but it draws on the same credit wallet, not a runtime proxy surprise.
Proxy and compute-unit stacking
The opaque case is when a single page silently consumes several "compute units" because the vendor escalated through datacenter, then residential, then mobile proxies, charging more at each hop. You only learn the true cost after the invoice. This is where metered-flavored credit models lose the predictability that is the whole point of credits.
Non-rolling credits
Most plan credits reset monthly and do not roll over — unused credits expire. A free tier may grant credits once rather than monthly. fastCRW's free tier, for example, is 500 one-time lifetime credits, not a monthly meter (fastCRW /pricing, verified 2026-05-18). Read the cadence before you budget: "500 credits" that never refill is a very different number from "500 credits per month."
How fastCRW credits map to operations
The point of a flat credit table is that you can price a workload from the table alone, with no per-page surprises. Here is fastCRW's full table.
| Operation | Credits |
|---|---|
scrape (any renderer: auto, http, lightpanda, chrome) | 1 |
crawl | 1 per page (any renderer) |
search | 1 per query |
map | 1 |
extract / any request with formats: ["json"] | 1 + usage-metered LLM token cost |
browse (MCP session) | 1 per session |
Source: fastCRW credit table (README "Renderer selection"), verified 2026-05-18.
1 credit per scrape — any renderer
Every scrape is 1 credit regardless of which renderer handles it. fastCRW's auto renderer escalates chrome → lightpanda → http only when cheaper renderers fail, so you always pay the same 1 credit whether the page needed a full browser or a simple HTTP fetch. There is no JS-rendering surcharge or chrome multiplier.
JSON extraction: 1 scrape credit plus usage-metered LLM cost
The JSON-extraction cost is the single biggest line item to plan around, because LLM extraction is the expensive operation. A structured-extraction request is the 1-credit scrape plus the LLM token cost, billed as usage-metered LLM credits — so if your pipeline extracts structured fields from most pages, model your bill as 1 scrape credit per page plus that metered LLM usage, not a flat 1 credit. How much more than a plain scrape depends on page size and token usage, not a fixed multiple, and underbudgeting it is the most common forecasting mistake. One honest constraint to design around: fastCRW's /v1/extract is single-URL with no multi-URL batch endpoint, so "extract from a thousand pages" is a thousand scrapes with formats: ["json"], each billed as 1 scrape credit plus its LLM token cost (fastCRW API surface).
Search and map credit costs
Search is 1 credit per query and map is 1 credit per call — both cheap and flat, which keeps discovery-heavy and search-augmented agent loops easy to forecast. An MCP browse session is 1 credit per session, so an agent that opens a session and runs several tool calls inside it pays once for the session, not per call.
Forecasting cost at scale
The discipline that makes credit pricing trustworthy is doing the per-1,000 math before you commit, using the heaviest operation in your pipeline as the unit.
Per-1,000-page math
Take 1,000 pages and price them against the table:
- Any scrape (http, lightpanda, or chrome renderer): 1,000 pages × 1 credit = 1,000 credits.
- Structured JSON extraction: 1,000 × 1 scrape credit = 1,000 credits, plus the usage-metered LLM token cost for each of the 1,000 pages (scales with page size).
The same 1,000 pages carry very different costs purely by operation type. Forecast with your actual mix — if 80% are plain scrapes and 20% need JSON extraction, that is (800 × 1) + (200 × 1) = 1,000 scrape credits per 1,000 pages, plus the usage-metered LLM token cost for those 200 extractions. This is also why a flat, published table beats an opaque metered invoice for budgeting the fetch leg: you can run that arithmetic in advance and it holds, and only the extraction's LLM usage is metered on top.
Self-host as the zero-credit escape hatch
Credits only meter the managed cloud. fastCRW's engine is an AGPL-3.0 single static Rust binary you can self-host, and self-hosting has no credit meter at all — the comparison of record is $0 per 1,000 scrapes self-hosted (you pay only for your own server) versus $0.83–5.33 per 1,000 scrapes on Firecrawl's hosted tiers, competitor-prices.lock.md, verified 2026-05-18). At high, steady volume the credit question disappears: the binding cost becomes a fixed VPS bill, not a per-operation meter. This is the structural escape hatch a hosted-only metered model cannot offer.
Which billing model scales
Neither model is universally better; they fail in opposite directions. Credits fail when multipliers are hidden; metering fails when resource usage is spiky and unknowable.
When credits win on predictability
Credits win when your workload is countable — a known number of pages, a known operation mix, a steady monthly cadence. You can read the cost off a table, write it into a budget, and have it hold. For RAG ingestion, scheduled crawls, and enrichment pipelines with a stable shape, a flat credit table is the more forecastable model, and an upgrade path of "buy a bigger bucket" is simpler to reason about than a variable infrastructure invoice.
When metered wins on bursty workloads
Pure usage metering genuinely wins when your traffic is bursty and unpredictable: long-idle periods punctuated by spikes, or a workload dominated by a few enormous pages where paying per-GB is fairer than paying a flat per-page credit. If you scrape rarely and lightly, a metered model can cost less than a plan whose monthly credits you would mostly waste — and credits that do not roll over make that waste real. If your job is heavy on residential-proxy GB against hostile sites, a transparent metered proxy bill can also beat a credit model that buries proxy escalation inside a multiplier. Match the model to your traffic shape, not to the marketing.
Sources
- fastCRW credit table, pricing, and free-tier cadence — /pricing ·
- Firecrawl pricing reference — firecrawl.dev/pricing (verified 2026-05-18)
Related: Firecrawl credits and rate limits · Cost of web scraping at scale · Cheapest web scraping API · Self-host vs managed scraping