The Cheapest Proxy Per Request Is Not a Price

Which proxy is cheapest per request depends on your volume and payload, not the headline rate. Here is the arithmetic, and where each model stops winning.

No proxy provider is cheapest per request in general. It is decided by two numbers you already have: how many requests you send in a month, and how many kilobytes come back on an average one. No advertised rate survives contact with those two.

Two honest answers up front. If you send a modest number of requests against ordinary pages and you do not want to run any infrastructure, a per-request scraping API is usually cheaper and always simpler, and we do not sell one, which is a genuine reason to buy from a different provider. If your volume is sustained or your responses are large, a metered or per-proxy model costs less per request, and that is what we sell.

This is about the per-request axis specifically. If you are choosing between paying per address and paying per gigabyte, pay per IP or pay per GB is the article for that decision and this one will not repeat it.

What "per request" actually bills

Per-request providers, usually scraping APIs rather than proxy services, charge for each call rather than for capacity or traffic. You send a URL, you get HTML back, and the pool, the rotation and the retry logic stay invisible.

The headline rate is rarely the rate you pay, because most of these plans price in credits and a request can cost more than one. Rendering a page in a headless browser costs more than fetching its HTML. A target with serious bot defense costs more than an ordinary page. Search results and social platforms cost more again. None of that is dishonest, it is priced by difficulty, but it means the advertised per-request figure describes your easiest request rather than your average one.

So the first correction to make when comparing is to work out your blended credit cost: the mix of easy and hard targets you actually hit, weighted by how often you hit them. A rate that looks like a fraction of a cent can land several times higher once the mix is real.

The second correction is failures. Some providers bill only successful fetches, some bill every attempt, and the difference moves your true cost per usable page more than most rate differences do. If you retry a blocked page three times before it succeeds, one policy charges you once and the other charges you four times for the same row of data.

What a proxy provider bills instead of requests

Capacity or traffic, never the call. Three shapes, and we use all three:

Per proxy, per month. Dedicated datacenter proxies rent an address for a flat monthly fee with no bandwidth meter on it. Requests through that address are free at the margin: the ten-thousandth costs the same as the first, which is to say nothing.

Per gigabyte. Residential proxies and the Premium and Shared rotating tiers meter traffic. You pay for bytes moved, and the rate falls as volume rises.

Per concurrent connection. Rotating Unmetered has no byte meter at all and prices by how many connections you hold open at once. What that inversion does to a data-heavy job is worked through separately.

One correction worth making because it is easy to get wrong: shared datacenter proxies are not unmetered. They are billed per proxy like the dedicated tier, but they carry an allowance of 3 GB per proxy, pooled across your order so a busy address is covered by a quiet one. Only the dedicated tier is genuinely without a bandwidth meter.

The arithmetic

Cost per request is the only number that compares these models, and it is easy to compute for each.

Per gigabyte:

cost per request = price per GB x average response size in GB

A 50 KB response is 0.00005 GB, so at any per-GB rate the per-request cost is that rate divided by twenty thousand. This is why payload size dominates the comparison: a page that returns 500 KB costs ten times as much to fetch as one that returns 50 KB, on exactly the same plan.

Per proxy with no meter:

cost per request = monthly cost of the proxy / requests sent through it that month

There is no floor here, which is the whole point. Push more requests through the same address and the per-request cost keeps falling until the target's tolerance, not your bill, becomes the limit. How many proxies a workload actually needs is the constraint that replaces cost.

Per concurrent connection:

cost per request = monthly cost of your connection tier / total requests that month

Same shape as per-proxy: fixed numerator, and your throughput decides the denominator. What you are sizing is the burst, not the total, and how concurrency is actually sold covers what enforces that number and what changes it mid-month.

Per request, for comparison:

cost per request = blended credit cost x price per credit

Note what is missing from that last one: response size appears nowhere. Under a per-request plan a 5 KB response and a 5 MB response cost the same, which is a genuine advantage on heavy pages and a genuine waste on light ones.

Where the crossover falls

There is no universal number, and anyone quoting one is guessing. The crossover moves with your payload, your target mix and your retry rate, and those vary by more than an order of magnitude between workloads.

What you can do is compute it in about five minutes. Take your monthly request count and your average response size from a sample of a few hundred real fetches against your real targets. Multiply out the per-request cost under each model using the formulas above, using your blended credit cost rather than the headline rate. Whichever is lower is your answer, and it will not be the same answer next quarter if either input moves.

Three things push the crossover down, meaning fixed billing wins sooner than you would expect:

Large responses. Full pages with images and script bundles rather than a JSON endpoint or a price field.

Hard targets. Anything that triggers a rendering or difficulty multiplier on a per-request plan is charged at that multiple every single time, while a metered plan charges the same for a hard page as an easy one of the same size.

High retry rates. Under per-gigabyte billing a refused connection transfers no bytes and therefore bills nothing. Under per-proxy billing a retry is free outright. Under per-request billing it depends entirely on the provider's success policy.

And one thing pushes it up, meaning per-request stays cheaper longer: low, spiky volume. A fixed plan bills for capacity whether you use it or not, so a job that runs for one hour a week is paying for the other hundred and sixty-seven.

Which proxy here is cheapest per request

Assuming your volume has already put you on this side of the crossover:

Dedicated datacenter is the cheapest per request of anything we sell, by a distance, for a workload that can concentrate traffic through a few addresses. No meter, so the denominator grows and the numerator does not. It is the right answer for API integrations, internal tooling and anything against targets that accept hosting ranges, and the dedicated datacenter tier is where that pricing lives.

Shared datacenter is cheaper per proxy and carries the pooled 3 GB allowance, so its per-request cost is lowest for light responses and rises as payloads grow.

Rotating Premium or Shared cost more per request than a static address for the same bytes, and buy you address breadth in exchange. If your target rate-limits per IP, that breadth is what makes the requests possible at all, which is a different question from what they cost.

Rotating Unmetered wins whenever your bytes-per-request are high and your concurrency is predictable, because the byte meter disappears entirely and you are sizing threads instead.

Residential is the most expensive per request and is not competing on price. You buy it when a target refuses hosting ranges outright, and the trade in full is worth reading before you assume you need it. Coverage runs to 170+ countries.

The general shape: the cheaper the address, the cheaper the request, and the narrower the set of targets that will accept it. Cost per request and success rate pull against each other, which is why cost per successful request is the number worth optimizing.

Measure it against delivered pages

Every formula above divides by requests. Divide by successful requests instead and the ranking can change.

A plan whose cost per request is a third of another's is not cheaper if two thirds of its fetches come back blocked. That is the failure mode behind most cheap proxy disappointment, and it does not show up in any rate card. Run a bounded, representative slice of your actual workload, count the pages you can use, and divide the bill by that. What the usage numbers do and do not measure covers reading the figures honestly.

Bandwidth is metered in both directions on the per-GB tiers, and a refused connection transfers no bytes and therefore bills nothing, so failures cost you time rather than money there. On your invoice that shows up as consumption below what your request count would suggest.

If per-request is genuinely what you want

Then buy it from someone who sells it. We do not have a per-request API and are not planning one, and pretending otherwise would waste your money and our support time. The honest boundary is this: per-request pricing buys you managed complexity, and that is worth real money when your volume is small enough that the convenience dominates the bill.

What we sell is the infrastructure underneath: dedicated and shared datacenter proxies on blocks we own in the United States, Italy and Spain, residential exits across 170+ countries, and three rotating tiers. If you already have scraping logic, or the engineering time to write it, fixed billing costs less per request at volume and the gap widens as you grow.

If you are not sure which side of the line you are on, the free tier exists to find out without committing anything: it is enough to measure success rate and average payload against your real targets, which is exactly the input the formulas above need. Current rates for every tier are on the pricing page, and choosing the right proxy type for a target covers the half of this decision that is not about money.