Whether a scraping API beats raw proxies comes down to page weight

Per-GB and per-request prices cannot be compared until you convert one into the other, and the conversion is a single number: your average response size. Priced off one vendor that sells both models, the two meet between 194 KB and 442 KB per request. Here is the arithmetic and where real pages land.

The conversion, in one line

A proxy bills the bytes you move. A scraping API bills the requests you make. To compare them, divide the API's price per request by the proxy's price per GB. The answer is the response size at which the two cost the same.

break-even size (GB) = API price per request ÷ proxy price per GB
break-even size (KB) = that, times 1,000,000

Above that size the API is cheaper, because one flat fee per request covers any number of bytes. Below it the proxy is cheaper, because the meter stops sooner than the fee does. Every argument about which model wins is really an argument about that one number, and almost nobody writing about it says so.

Geonode sells both, which holds everything else still

Most comparisons of these two models are written by a party selling one of them. Geonode sells both, so pricing them against each other removes the vendor, the network and the date as variables. Both ladders were read on 15 August 2026.

Its per-request ladder runs from $0.35 per 1,000 (read 15 Aug 2026) at 10K requests down to $0.13 per 1,000 (read 15 Aug 2026) at 1M. Its residential ladder runs from $0.792/GB at 10 GB down to $0.27/GB at 100 TB. Crossing them:

Matched by volume, because the corners of a grid are not purchasable. An API tier of 10,000 requests is about $3.50 a month; Geonode's $0.27/GB rung is its 100 TB commitment. Nobody buys both, so crossing every API tier against every proxy rate produces cells that describe no real buyer. Each row below instead solves for the proxy rung that the same monthly work would actually land on:

Read a row as: at this API tier, the equivalent proxy spend buys this rung, and a response of this size costs the same either way.

The spread is far narrower than the ladders suggest: 194 KB to 442 KB, not the 160 KB to 1.3 MB an unmatched grid implies. The reason is that the deep proxy discounts are unreachable at these volumes. A million requests a month at the break-even size is 194 GB of traffic, which buys the 100 GB rung at $0.648, not the 100 TB rung at $0.27. A rough rule for real buyers is 300 KB.

The market has converged on the request price, too. ZenRows charges $0.000356 per credit on its entry plan against Geonode's $0.000350 per request, and $0.000091 at the top of its ladder against Geonode's $0.000126. Those are different companies with different networks arriving at the same number.

The multiplier that moves the answer by sixty times

Here is the part the per-credit headline hides. A credit is a billing unit, and one request does not always cost one credit. Scrapfly's own estimator prints the rate card:

credits per scrape · click to adjust 1 HTTP · datacenter 5 + ASP / browser 25 + residential 60 screenshot

Its plans price a credit directly, so the multipliers can be costed without leaving the vendor. Read 27 August 2026: $0.15 per 1,000 credits on Discovery at $30 a month, $0.10 on both Pro and Startup, $0.09 on Enterprise at $500. Taking the $0.10 rung, which covers the two middle plans:

Both halves of that comparison are one vendor's own published numbers: Scrapfly's credit price against Scrapfly's own multipliers, set beside Geonode's cheapest residential rate.

At 25 credits a scrape you would need a 9.3 MB response before raw proxies lost on price, and almost nothing is 9.3 MB. So the option you tick matters more than the vendor you pick, and a comparison that comes out even at 1 credit comes out lopsided at 25.

This is the same shape as the second meter on unlimited plans: the advertised unit is not the unit you are billed in.

The method

We fetched twelve vendor pricing and policy pages on the night of 15 August 2026, which is ordinary work for this site rather than a benchmark. Their HTML averaged 397 KB, with a median of 253 KB. The largest was 1.57 MB and the smallest 54 KB.

That figure is uncompressed, and a proxy does not bill uncompressed bytes. Re-fetching five of those vendor pricing pages on 27 August, once with Accept-Encoding: identity and once with the compression every HTTP client asks for by default, the raw HTML averaged 215 KB and the same pages crossed the wire at 35 KB. That is 6.1x, and it is the figure the meter reads:

$ curl -sA "$UA" -H 'Accept-Encoding: identity' -o /dev/null -w '%{size_download}' <url>
$ curl -sA "$UA" --compressed              -o /dev/null -w '%{size_download}' <url>

                        raw KB    wire KB    ratio
iproyal.com                189         35     5.43x
webshare.io                233         27     8.55x
oxylabs.io                 388         70     5.51x
geonode.com                264         45     5.91x
nodemaven.com              ---        ---     no response
decodo.com                 ---        ---     no response

Apply that ratio and the 397 KB average is roughly 65 KB billed, which is not on the crossover at all. It is well below the whole grid, and for fetching documents like these the proxy is the cheaper model by a wide margin rather than a close one.

Two things pull the other way and both are real. 397 KB is the HTML document alone, so a headless browser that does not block subresources puts the images, CSS, fonts and scripts across the meter too, and the rendered figure is often several times the document. And two of the six pages returned nothing to a plain curl, which is itself the reason people reach for a scraping API.

The rule that survives all of it: measure at the proxy, not at the parser, and not at the file size. Your provider's own usage counter is the only number that matches your invoice.

Working out your own number

Three steps, and the first is the one people skip:

1. Measure your average response, at the proxy. Sum the bytes your proxy account actually reports over a real run, and divide by requests. Do not use the HTML size, and do not use a figure from an article. With no run to measure yet, the bandwidth estimator starts you from page weights we measured ourselves.
2. Take both prices at the volume you will really buy. Entry-tier rates on either side are the worst case for both. Our cost calculator will give you the per-GB side across every metered plan we track.
3. Divide, and check the multiplier. API price per request over proxy price per GB, times a million, gives your break-even in KB. If the API charges more than one credit for the mode you need, multiply the API side first.

We are not declaring a winner between the two models, here or anywhere else on this site, because the answer changes with page weight and with which unblocking you need. What we can do is give you the arithmetic and both sets of real numbers with the date attached. How we check covers where the proxy side of these figures comes from.

This article prices two ways of fetching a page. If the layer you are choosing is one higher up, request-response API versus a hosted browser session you operate yourself, that is a product decision before it is a cost one, and what each one sells takes that layer.