Web scraping API credits: why the number on your plan isn't your capacity

A web scraping API sells you credits, then tells you how many land in your account each month. The number looks like capacity. It isn't. A credit is a variable-rate unit. On most platforms a plain page costs one credit, and the same page rendered in a browser behind a stealth proxy can cost twenty-five. What you actually spend is the per-credit price times your workload's blended multiplier, not the figure printed on the plan.

For a fixed scraping job you can model that gap on a napkin. For an agent that decides at runtime how hard each fetch has to work, you can't, and that is where the budgeting breaks.

What a credit actually buys

The cleanest place to watch this is a vendor that publishes its whole rate card. Firecrawl repriced on September 4, 2026, and the new plans read like capacity: Free gives 1,000 credits a month, Hobby is $16 for 5,000, Standard $83 for 100,000, Growth $333 for 500,000, Scale $599 for a million.

Then you read the consumption side of the same page and the tidy numbers come apart. A scrape, a crawl page, and a map page each cost one credit. Search costs two credits per ten results. Browser interaction is billed by time, at two credits per browser minute. A recurring monitor check is one credit per page per run, so a job that watches a thousand URLs hourly spends a thousand credits an hour whether or not anything changed. Ask for structured JSON, a highlight, or an answer to a question about the page, and Firecrawl adds four credits per page on top of the scrape. The Agent mode, still in preview, gives five free runs a day and then charges "dynamic" pricing, which is the vendor saying plainly that it cannot quote a fixed number either.

So one million credits is one million plain pages, or 200,000 pages if every one needs a JSON extraction, or some figure in between that depends entirely on what your code asked for. The plan size is real. The capacity it implies is not.

The multiplier is the real price

ZenRows states the same idea more bluntly, because its whole model is multipliers. One credit buys a plain successful page. JavaScript rendering costs five. A premium proxy costs ten. Turn both on to get through a protected site, which is exactly when you need both, and the request costs twenty-five credits.

Run that through a real plan. ZenRows sells its Launch tier at $99. That covers 500,000 plain pages, or 20,000 pages at the 25x rate. Same plan, same dollar figure, same 500,000 credits, and a factor of twenty-five between the easy version of the job and the hard one. If the sites you care about are the ones with anti-bot walls, and they usually are, the sticker capacity is off by more than an order of magnitude before you write a line of code.

None of this is a gotcha or a hidden fee. Rendering a page in a real browser and routing it through a residential proxy genuinely costs the vendor more, and charging for it is fair. The problem is narrower. The unit you budget in, the credit, floats against the work you are actually doing, and the plan page quotes the unit, not the work.

Why agents make this worse

A traditional scraper has a fixed recipe. You know before you run it whether it renders JavaScript, whether it needs premium proxies, roughly how many pages it will hit. You can compute the blended multiplier once and trust it for the life of the job.

An agent decides those things while it runs. Say you point one at fifty supplier sites to pull a price and a lead time from each. On the plain sites it fetches raw HTML at one credit. On the three sites behind a bot wall it retries with rendering, then escalates to a stealthier proxy, and now those requests cost twenty-five each. Because the task asked for two structured fields, every page also runs through an extraction step. You budgeted for fifty credits and spent several hundred, and every step that got you there was a reasonable decision the agent made on its own. The blended multiplier stopped being an input you chose and became an output of the run, one you only saw after the bill.

That is the same shape as the problem I wrote about in agentic search pricing, where one agent task quietly fans out into twenty search calls. Here it is not the number of calls that moves, it is the unit cost of each one. Both leave you with a bill you cannot forecast from the price list, which is the property that actually matters when you are the person signing off on the number.

The consumption table moves under you

Even the multipliers are not stable. Firecrawl's changelog shows the extraction rate moving twice: an earlier cut took a structured extract from 50 credits to 5, and on August 17, 2026 the Enhanced extraction mode dropped from 5 credits to 1, with the automatic escalated retries folded in rather than billed on the side.

Those were cuts, so nobody complained. That is the point. A vendor can reprice any line in the consumption table at any time, in either direction, and the change lands inside the plan you already bought. Your monthly credit count did not move. What a credit buys did. Anyone who modeled their cost once, at signup, is now carrying a number that quietly went stale, and it went stale without a plan change, an email, or anything else that would prompt a second look.

How to price a workload in credits

The fix is not a spreadsheet of per-credit prices across vendors. It is to price your own workload, in credits, on the sites you actually hit.

The arithmetic is simple once you stop anchoring on the base rate. Say a third of your target pages sit behind a bot wall and need the full 25x treatment, and the rest are plain fetches at one credit. Your blended multiplier is 0.67 times 1 plus 0.33 times 25, which is about 8.9. That turns a 500,000-credit plan into roughly 56,000 real pages, not 500,000. Change the mix to half hard pages and the same plan buys about 38,000. The plan number never moved; the only thing that set your true capacity was the share of pages that fight back.

• Start from the request you really send, not the base rate. Write down whether each fetch renders JavaScript, needs a premium or residential proxy, and calls an extraction step. That combination, not the headline price, sets what the request costs.
• Compute a blended multiplier from a real sample. Run a few hundred of your actual target URLs, count the credits spent, and divide by the pages you got back. That average is your true unit, and it will not match the base rate on the plan page.
• Charge failures into the model. Most vendors, ZenRows and Firecrawl included, still bill a 404 or a 410 as a successful credit-spending request. On a large crawl the dead links are not free.
• Convert to cost per useful result, not cost per request. A page you rendered, proxied, and extracted from might cost twenty-five times a plain fetch, but if it is the only page that produced the field you needed, that is the number that belongs in your unit economics. The cost-per-answer guide walks through that conversion.

Do this once a quarter, not once at signup, because the table underneath you moves.

What to watch

Two things worth tracking. The first is whether agentic extraction modes keep hiding behind "dynamic" pricing. When the most agent-native feature on the page is the one the vendor won't quote a fixed rate for, that is a signal about how predictable your bill will be, and it is worth weighing before you route a production workload through it.

The second is whether anyone standardizes the consumption table the way plans got standardized years ago. Right now every vendor names its multipliers differently, and comparing two of them means rebuilding both models in the same units by hand. I wrote a general version of that exercise in web data pricing in 2026. The credit-level version is messier, because the number you are handed at signup is the one figure in the whole transaction that tells you the least about what you are going to pay.