The usual way this decision gets framed is free against paid. Puppeteer is open source, a solver API bills per call, so the browser wins on price and the only question is whether you can keep it working. That framing quietly drops a line item, and on defended targets it is the largest one: a headless browser behind a residential proxy is spending money on every request, because residential bandwidth is metered by the gigabyte and a browser downloads the entire page.
We run the proxy side of that bill, so the gigabytes are the part we see. On 6 August 2026 we took the benchmark Hyper Solutions publishes for their own solver API, held it against what a gigabyte of residential bandwidth costs on our network, and worked out what the two approaches actually cost to move the same data.
The short version
Hyper Solutions measured a protected flow both ways: 281 network requests and 6.54 MB through browser automation, 6 requests and 340 KB through their API. That is 19 times the bandwidth for the same page. At 100,000 protected fetches it is the difference between 654 GB and 34 GB, and on a per-gigabyte residential plan the gap is real money that no headless-versus-API comparison we have read bothers to count.
The measurement
Hyper Solutions builds bypass APIs for Akamai, DataDome, Incapsula and Kasada, which means they had to instrument both approaches against the same protected target to know whether their own product was worth building. They frame the comparison fairly, which is partly why we are willing to build on their numbers:
Puppeteer and Playwright are good general tools. They are not built for the volume and freshness antibot work demands. We measured the gap so you do not have to.
They publish the result on their homepage and again on the Akamai product page, measured on a real airline award-availability flow.
One protected flow, measured two ways
| Metric | Solver API | Puppeteer / Playwright |
|---|---|---|
| Network requests | 6 | 281 |
| Response time | 0.3 s | 5.46 s |
| Bandwidth moved | 340 KB | 6.54 MB |
hypersolutions.co, their own real-world testing on airline award availability
The number that matters for a proxy bill is the third row. Everything else is latency and machine time, which you feel in throughput. The 6.54 MB is the one that arrives as an invoice.
What that is in gigabytes
Bandwidth arithmetic is the useful kind, because gigabytes do not move when anyone reprices anything. Below is the same flow at three volumes, with the difference stated in gigabytes first.
Bandwidth moved per volume of protected page fetches
| Protected fetches | Browser automation GB | Solver API GB | Difference GB |
|---|---|---|---|
| 10,000 | 65.4 | 3.4 | 62.0 |
| 100,000 | 654 | 34 | 620 |
| 1,000,000 | 6,540 | 340 | 6,200 |
6.54 MB and 340 KB per flow, multiplied out. Decimal gigabytes, the unit proxy networks bill in.
At our residential rate of $0.50/GB with no volume commitment, 100,000 protected fetches through a headless browser is roughly 327 dollars of bandwidth. The same work through a solver API moves 34 GB, about 17 dollars. At a million fetches the browser column crosses our 2,000 GB+ volume floor and drops to $0.44/GB, which still leaves it near 2,880 dollars against 170.
Why the browser moves so much more
A headless browser is expensive on a proxy for exactly the reason it works: it behaves like a browser. It parses the document, then goes and gets the stylesheets, the web fonts, the hero imagery, the analytics tags, the consent manager, and the anti-bot vendor's own sensor script, then runs the JavaScript that requests more. Two hundred and eighty-one requests is not waste in any sense the browser understands. That is a page load.
The awkward part is the ratio inside it. The anti-bot payload you actually needed is a few kilobytes of sensor script and a cookie. Everything else is the page it was hiding behind, and on a metered residential connection you buy all of it at the same price per gigabyte. You are paying retail for a product photograph in order to obtain a cookie.
A solver API inverts that. You fetch the document, hand the challenge context to the API over your own connection, get a payload back, post it, and continue on a trusted session. The images never come down because nothing ever asked for them.
The part that is not bandwidth
Bandwidth is the line item we can price precisely, and it is not the whole comparison. Three other costs sit on the browser side, and none of them appear on a proxy invoice.
Compute. A headless Chrome is a few hundred megabytes of RAM and a real CPU share while it runs. Hyper Solutions puts throughput at 1 to 2 requests per second per worker for browser automation against 240 or more for API calls, which is the same statement expressed as machines you have to rent.
Latency. 5.46 seconds against 0.3 on their measured flow. On a price-monitoring sweep that is a scheduling problem. On a drop or a fare that moves, it is the whole job.
Maintenance. When Akamai rotates a script or Kasada changes its proof of work, a self-hosted browser stack is your incident, at whatever hour it happens. This is the cost teams underestimate most, because it does not bill monthly. It bills on the worst day of the quarter. Hyper Solutions sells against precisely this, and their framing is the honest one:
The whole point of buying instead of building: vendor patches, fingerprint rotations, and new challenge variants stop being your 2am incident.
Their Akamai page publishes a second benchmark, measured per solve rather than per flow, which sharpens the same picture:
The same comparison, measured per solve
| Metric | Solver API | Puppeteer / Playwright |
|---|---|---|
| Requests per second per worker | 240+ | 1 to 2 |
| p95 latency to solve | under 10 ms | 5.8 s |
| Bandwidth per solve | about 8 KB | 3 to 12 MB |
| Who owns the patch | the vendor | your incident |
hypersolutions.co/products/akamai, their own testing
The first row is the one to translate into money. A hundred-fold difference in requests per second per worker is a statement about how many machines you rent to hit a given throughput, and it compounds with the bandwidth gap rather than overlapping it.
Where each approach actually spends
| Feature | Self-hosted headless browser | Solver API + your own proxy |
|---|---|---|
| Proxy bandwidth per 100k fetches | 654 GB | 34 GB |
| Throughput per worker | 1-2 req/s | 240+ req/s |
| Time to first byte on a protected page | 5.46 s | 0.3 s |
| Per-solve fee | no | yes |
| Browser farm to run and scale | yes | no |
| Vendor patch is your incident | yes | no |
| You keep your own proxies and cookie jar | yes | yes |
The solver API charges a fee the browser does not, and the bandwidth it saves at 100,000 fetches is in the same order of magnitude as that fee. What actually decides it is whether you want to own a browser farm and the patch cycle that comes with it.
Bandwidth and throughput figures from Hyper Solutions' published benchmarks; bandwidth cost computed at our residential rates
The honest accounting
Setting the two bills side by side at 100,000 protected fetches: the browser approach spends about 654 GB of residential bandwidth and no vendor fee. The API approach spends about 34 GB and a per-solve fee, which on Hyper Solutions' published pricing is 3 euros per thousand solves self-serve, falling to roughly 1.40 on a monthly plan.
Two things stop that from being a clean subtraction, and both are worth stating rather than hiding.
The first is currency. Our bandwidth is priced in dollars and their solves in euros, so the totals below are the same order of magnitude rather than a like-for-like sum, and we have not invented an exchange rate to pretend otherwise.
The second matters more. A fetch is not a solve. Once a session is trusted you reuse that cookie across many requests, so the number of solves you buy is the number of sessions you open, not the number of pages you read. A job that reads thirty pages per trusted session buys thirty times fewer solves than the table above implies, while the browser column keeps paying full page weight on every one of those thirty. The gap widens with session reuse, and it widens in the API's favour.
So the defensible conclusion is narrower than a headline and more useful: the residential bandwidth a solver API saves is roughly the same size as what a solver API costs. The fee is close to paid for before you count the browser farm, the RAM, the orchestration, and the 2am patch. Anyone comparing free Puppeteer against a paid API without metering the proxy has left out the largest variable cost on the free side.
When the browser is still the right tool
None of the above makes headless browsers a mistake. They are the correct choice in several situations, and a solver API cannot help with any of them.
- Your target is not one of the four. Solver APIs cover specific vendors. Hyper Solutions handles Akamai, DataDome, Incapsula and Kasada. Anything outside that list is a browser problem again.
- You genuinely need rendering. If the data only exists after client-side JavaScript builds it, something has to run that JavaScript, and no sensor payload substitutes for a rendering engine.
- Volume is low. At a few thousand fetches a month the gigabytes are noise and the simplest stack wins.
- The work is interactive. Filling forms, driving a checkout, or anything with real UI state is a browser job.
The case for a solver API is narrower than its marketing and stronger than its price tag: when the target runs one of those four vendors and you are reading a lot of pages, the browser is doing a very expensive impression of an HTTP client.
Method
Bandwidth and throughput figures are Hyper Solutions' published benchmarks, taken from their homepage and Akamai product page on 6 August 2026, and labelled by them as real-world testing on airline award-availability scraping with full page loads on the browser side. They are a vendor's numbers for a vendor's product, and we have neither reproduced nor audited them. We reproduce them here because they are specific, they are consistent across two of their pages, and the ratio matches what we see in aggregate on our own network when customers move a workload off browser automation.
Gigabyte totals are those per-flow weights multiplied out, in decimal gigabytes, which is the unit proxy networks bill in. Dollar figures use our published residential rates on 6 August 2026: $0.50/GB flat, falling to $0.44/GB above 2,000 GB+. Both columns are priced at the tier their own volume earns, so the browser column takes the volume discount at a million fetches and the API column does not. Repricing at either end moves the dollars and leaves the gigabytes exactly where they are, which is why the gigabytes lead.
Sources
- Hyper Solutions: the published browser-versus-API benchmark, 281 requests and 6.54 MB against 6 requests and 340 KB, plus per-solve pricing.
- Hyper Solutions: Akamai Bypass API: per-solve bandwidth of about 8 KB against 3 to 12 MB for browser automation, and throughput of 240 or more requests per second per worker against 1 to 2.
- Our own residential pricing, the rates used for every dollar figure above.