Bandwidth pricing is the hidden variable that decides most proxy purchases, and most people don't realise it's the deciding variable until they've already chosen wrong. Two proxy products can look similar on every specification sheet — same protocols, similar pool sizes, comparable geographic coverage — and differ by an order of magnitude in what they cost to run a given workload, purely because one meters data and the other doesn't.
Unlimited bandwidth proxies remove the meter. You pay for addresses or for throughput, and the volume of data you move through them doesn't affect the bill. That single property changes what you can afford to build, what your engineering team optimises for, and which workloads are viable at all.
This guide covers what unlimited actually means in practice, where the fine print hides, how to work out whether metered or unmetered wins for your specific workload, which jobs are transformed by removing the meter, and how to make full use of capacity you've already paid for.
What Unlimited Bandwidth Actually Means
The phrase is marketing, so precision matters.
What's genuinely unlimited: total data transferred. No gigabyte allowance, no overage charges, no meter to watch. You can move a hundred gigabytes or a hundred terabytes and the invoice doesn't change.
What's still limited, in nearly every case:
- Throughput. How fast you can move data, whether stated explicitly as a rate cap or imposed implicitly by the infrastructure.
- Concurrent connections. Often generous or unlimited, but worth confirming.
- Request rate, in some products, separately from data volume.
- Fair use. Some providers reserve the right to throttle or intervene on sustained extreme usage, even on plans marketed as unlimited.
So "unlimited" means unmetered on volume, with the constraint relocated somewhere else. That's still a genuinely different economic shape, and the relocation is usually to a place that suits high-volume work far better.
Where you find it
Unmetered bandwidth is standard in some product categories and rare in others, and the pattern reflects underlying cost structures rather than vendor generosity.
- Datacenter proxies are almost universally unmetered. Datacenter bandwidth is cheap enough that metering it isn't worth the billing complexity.
- Dedicated proxies, being datacenter or ISP addresses, usually inherit unmetered bandwidth.
- ISP proxies are typically unmetered, since they run on datacenter infrastructure.
- Residential proxies are almost always metered per gigabyte, because the provider is compensating node operators for consumer bandwidth that genuinely costs money.
- Unlimited residential exists as a distinct product, priced by throughput rather than volume, for people who need residential classification without the meter.
- Mobile proxies are usually metered, because cellular data is expensive and the provider is paying a real carrier bill.
The pattern: bandwidth is metered where it costs the provider real money, and unmetered where it doesn't. Datacenter bandwidth is close to free at scale; consumer and cellular bandwidth isn't.
Why Bandwidth Costs What It Does
A short explanation of the supply side, because it makes the pricing patterns predictable rather than arbitrary.
Datacenter bandwidth is bought wholesale in enormous quantities. A provider with racks in a major facility buys transit measured in gigabits, at prices per gigabit that have fallen steadily for two decades. The marginal cost of one more customer's traffic is close to zero, which is why metering it isn't worth the billing infrastructure. Unmetered datacenter bandwidth isn't generosity; it's the absence of a cost worth tracking.
Residential bandwidth is bought retail, one household at a time. The provider compensates node operators — in cash, credits, or a free service — for the data routed through their connections. That cost is real, it scales linearly with usage, and it's why per-gigabyte billing exists on residential products. A provider offering unmetered residential is absorbing a genuine variable cost, which is why those plans carry high floor prices.
Cellular bandwidth is the most expensive of all. The provider is paying an actual carrier bill on an actual SIM, on consumer or business plans that were never designed for sustained commercial throughput. Mobile metering reflects a cost that's both high and inflexible.
Throughput pricing splits the difference. By charging for rate rather than volume, a provider caps their own exposure — they know the maximum data any customer can move — while letting the customer stop counting. It's a sensible arrangement for both sides at high volume and a poor one at low volume, which is exactly what the floor price reflects.
The practical takeaway: bandwidth policy is a reliable signal about what kind of network you're buying. Unmetered means datacenter infrastructure somewhere in the stack. Metered means someone is paying a real per-byte cost on your behalf. When a provider's pricing model doesn't match the product they claim to be selling, that discrepancy is worth asking about.
Why the Meter Distorts Engineering
This is the part that's hard to appreciate until you've worked both ways.
On a per-gigabyte plan, every byte has a price, and that price propagates into every technical decision your team makes. You start blocking images in headless browsers. You avoid full page loads. You skip retries that might have succeeded. You parse in the request path rather than storing raw responses. You sample instead of crawling exhaustively. You reject project proposals because the bandwidth estimate is uncomfortable.
Some of that discipline is good engineering regardless. Much of it is optimisation for a constraint that produces worse data and more fragile pipelines:
- Stripping page loads down to bare HTML makes your traffic look more automated, not less, and often lowers your success rate on protected targets.
- Not storing raw responses means a parser bug requires re-crawling, which costs days you'd have saved with cheap disk.
- Conservative retry policies leave recoverable failures unrecovered, which lowers data completeness.
- Sampling instead of crawling produces datasets with coverage gaps you'll discover later.
Removing the meter doesn't just save money on the same work. It changes what work is sensible. That's the argument for unmetered products that specification comparisons never capture.
> Tip: If your team spends meaningful time discussing how to reduce bytes rather than how to improve coverage or accuracy, the meter is costing you more than the line item suggests.
Which Workloads the Meter Punishes Most
Some jobs are barely affected by per-gigabyte pricing. Others are transformed by it. Knowing which you have decides the purchase.
Headless browser automation. The worst case by a wide margin. A browser loads the document, stylesheets, scripts, fonts, images, tracking pixels, and often video. A page that's 40KB of HTML can be 3MB fully rendered. That's a 75x multiplier on a metered plan, and effectively zero on an unmetered one.
Media and document collection. Images, PDFs, video, audio, datasets. Per-gigabyte billing charges you for payload size rather than collection difficulty, which means the easiest content to obtain is often the most expensive to pay for.
Full-site crawling. Fetching every page of a large site rather than sampling. Page counts run high and payloads are full documents.
Link checking at volume. Millions of requests. Individually small, collectively substantial, and with no per-request value to justify a meter.
Continuous monitoring. Re-fetching the same pages on a schedule indefinitely. The same bytes, over and over, charged every time.
Training data and corpus construction. Enormous volumes of raw content, collected continuously, with deduplication happening after collection rather than before.
High retry-rate workloads. Every retry is billable traffic on a metered plan, so a low success rate multiplies your bill as well as reducing your output.
By contrast, workloads the meter barely touches:
- API consumption, where responses are small JSON payloads
- Targeted extraction of specific fields from a modest number of pages
- Low-volume monitoring of a small tracked set
- Anything where request count is low and payloads are tiny
For that second group, per-gigabyte residential is often cheaper than an unmetered plan's floor price, and the meter is genuinely the right choice.
The Calculation That Decides It
Run this before every proxy purchase. It takes ten minutes and routinely changes the answer.
Step one: estimate real consumption
Two things people get wrong here:
- The success rate divisor. You pay for the bandwidth of a failed request exactly as for a successful one. At a 50% success rate, you're funding twice the traffic you get usable data from.
- Average response size. Almost everyone guesses low, often by a factor of two or three. Measure it on a sample of a few hundred real requests rather than estimating.
Step two: price both models
Unmetered cost = address count x unit price, or flat throughput tier price
Step three: check the classification requirement
This is the step that most often flips the answer, and it's frequently skipped.
Unmetered datacenter bandwidth costs a small fraction of unmetered residential throughput. So before comparing metered residential against unmetered residential, test whether your target requires residential classification at all. Five hundred requests through datacenter addresses against your real target, with the status distribution recorded, answers it definitively.
If datacenter works, unmetered datacenter is dramatically the cheapest option and the residential comparison is irrelevant. If it doesn't, then you're choosing between metered and unmetered residential, and the volume threshold decides.
The general shape
- Small volumes on protected targets: metered residential wins. Unmetered products have a floor price that dwarfs modest consumption.
- Large volumes on permissive targets: unmetered datacenter wins overwhelmingly, and it isn't close.
- Large volumes on protected targets: unmetered residential throughput, if volume is high and sustained enough to clear the floor.
- Spiky traffic: metered wins, because you pay only for what you use.
- Continuous traffic: unmetered wins, because sustained load is what it rewards.
Worked Examples
Three realistic scenarios, run through the arithmetic, to show how differently they resolve.
A modest price monitoring operation
Five thousand product pages, checked twice daily, average response 180 KB, success rate 80%, target requires residential classification.
Monthly GB = (300,000 / 0.8) x 180 KB = 375,000 x 180 KB = ~64 GB
Sixty-four gigabytes. On metered residential at a mid-tier per-gigabyte rate that's a modest, entirely manageable bill. An unmetered residential throughput plan's floor price would be many times that. Metered wins decisively, and buying unmetered here would be a straightforward mistake.
A large link checking and SEO crawl
Eight million HEAD and GET requests a month across many domains, average response 60 KB, success rate 90%, targets are permissive and datacenter addresses work fine.
Five hundred gigabytes. On metered residential this would be a significant bill for work that doesn't need residential classification at all. On unmetered datacenter it costs the price of the addresses and nothing more. Unmetered datacenter wins overwhelmingly — and note that the deciding factor was testing that datacenter worked, not the volume.
A browser-driven collection pipeline on protected targets
Two hundred thousand fully-rendered page loads a month, average 2.8 MB rendered, success rate 65%, targets require residential classification.
Nearly a terabyte, from what sounds like a small page count, because the browser multiplier dominates. On metered residential this is a serious monthly figure. This is the case where an unmetered residential throughput plan starts to make sense — and it's also the case where the metered plan was actively distorting engineering, because the obvious response to that bill is to strip the browser down, which hurts success rate on exactly the targets that forced residential in the first place.
The pattern across all three: volume alone doesn't decide it. Classification requirement, payload size, and success rate all move the answer, and the only way to know is to measure rather than assume.
Reading the Fine Print
Unlimited plans vary more in their terms than their marketing suggests, and the differences are often worth more than the price gap.
Is throughput capped, and at what rate? An unmetered datacenter plan usually has no explicit cap, with practical limits from infrastructure. A throughput-priced residential plan has an explicit one. Know which you have.
Is there a fair use policy? Some providers reserve the right to throttle sustained extreme usage. This is not necessarily unreasonable, but you want to know the threshold before you build a pipeline that crosses it.
Are concurrent connections limited? An unmetered plan you can't parallelise into is unusable at scale. Confirm the limit or its absence.
Is request rate limited separately? Some products meter requests even where data is unmetered. That's a different constraint with different implications.
What happens if you exceed a limit? Throttling, queuing, and overage billing all exist, and they behave very differently under a crawler that doesn't know it's being limited.
Is bandwidth unmetered on all protocols? Occasionally SOCKS5 or certain endpoints have different terms.
Are there per-address caps within an unmetered plan? Some products are unmetered in aggregate but limited per IP.
None of this is exotic. It's clear in the terms and invisible in the marketing, and it takes five minutes to check.
Measuring Your Actual Bandwidth Consumption
Everything in the purchase decision rests on one number, and almost nobody measures it properly. Estimating from page counts and a guessed average size produces errors of several hundred percent.
Instrument at the transport layer, not the parser. You want bytes actually transferred, including headers, redirects, and failed responses. Counting the size of successfully parsed documents undercounts dramatically.
In Python:
total_bytes = 0
def fetch(url, proxies):
global total_bytes
r = requests.get(url, proxies=proxies, stream=True, timeout=30)
body = r.content
total_bytes += len(body) + sum(len(k) + len(v) for k, v in r.headers.items())
return r
That's approximate — it misses request bytes and TLS overhead — but it's far closer than an estimate.
Count failures separately. Log bytes consumed by requests that returned a block, a challenge, or an error. This is the figure that surprises people, and it's the one the success-rate divisor in the cost formula represents.
Count redirects. Each hop in a chain is billable traffic. A crawl with a high redirect rate consumes considerably more than its final-response sizes suggest.
Measure your headless browser separately. If any part of your pipeline uses a browser, measure that portion on its own. The multiplier relative to plain HTTP fetching is usually between ten and a hundred, and averaging it into a whole-pipeline figure hides where the cost actually is.
Run for long enough to be representative. A one-hour sample during a quiet period tells you little. A full day covering your normal request mix tells you a lot.
Track bytes per useful record extracted. This single derived metric is the most useful efficiency number available, and it makes optimisation measurable rather than theoretical. It also lets you compare pipelines directly.
Once you have real numbers, the metered-versus-unmetered arithmetic becomes a five-minute exercise with a defensible answer, instead of a guess dressed up as a decision.
Use Cases Transformed by Removing the Meter
Headless browser automation at any real scale. The single largest beneficiary. Full page rendering with all assets is between ten and a hundred times the bandwidth of an HTML fetch. On a meter this forces aggressive resource blocking, which makes traffic look more automated and often reduces success rate. Unmetered, you load pages the way a browser actually would.
Exhaustive site crawling and archiving. Fetching every page rather than sampling. Coverage gaps that seemed like a reasonable trade-off under a meter stop being necessary.
Media, image, and document collection. Payload-heavy content where metered billing charges for size rather than difficulty. Product images, PDFs, catalogues, and datasets all fall here.
High-frequency monitoring. Re-fetching the same pages hourly rather than daily. Under a meter, frequency multiplies cost linearly; unmetered, it's free and your data gets substantially fresher.
Link checking and technical SEO auditing at volume. Millions of requests with no per-request value to justify a meter, and an obvious fit for unmetered datacenter addresses.
Training corpus construction. Enormous volumes of raw content, collected continuously, with deduplication after collection rather than before.
Redundant collection for reliability. Fetching the same data more than once, or from more than one path, to guard against transient failures. Sensible engineering that a meter makes uneconomic.
Development and experimentation. Iterating on a crawler without watching a meter. The cost of a mistake during development drops to zero, which measurably speeds up how fast a pipeline reaches production quality.
Saturating What You Bought
Unused capacity is money burned. This applies to any unmetered product but bites hardest on throughput-priced plans, where you're paying for a rate whether or not you use it.
Most operations run at a fraction of their available capacity, and the causes are nearly always in their own client rather than the provider's network.
Remove default connection pool limits. Nearly every HTTP library ships with a conservative cap. requests limits its adapter pool, aiohttp defaults its connector, Node's agent caps sockets, Scrapy's reactor has a threadpool size. These are the single most common invisible bottleneck.
Raise concurrency deliberately. Start where you are, double, measure successful requests per minute, repeat until the number stops improving. Measure successes rather than raw requests — two hundred threads at 30% success does less work than fifty at 95%.
Use keep-alive everywhere. A new TCP connection and TLS handshake per request wastes both time and, on throughput plans, capacity. Connection reuse can substantially raise effective throughput at high request rates.
Decouple fetching from processing. If parsing, deduplication, or database writes run inside the request loop, they become your ceiling and no amount of purchased bandwidth helps. Put a queue between fetch and process.
Parallelise across targets, not within them. Aggregate saturation and per-site politeness aren't in conflict. Cap per-domain concurrency at a respectful level and run many domains simultaneously.
Spread work across the full day. Throughput plans reward steady load. Compressing a job into two hours means paying for twenty-two idle ones.
Monitor utilisation as a first-class metric. Instrument aggregate bytes per second and compare against your purchased capacity. If you're at 25%, you're paying four times what your data costs, and the fix is almost certainly in your own code.
Changing What You Optimise For
The mindset shift is the real value, and it's the thing people forget to make after switching.
Once bandwidth is free, the constraint moves to success rate. Every failed request still consumes capacity and produces nothing, so improving success rate directly increases usable output. That's now your efficiency metric, not bytes per record.
Things that become sensible once the meter is off:
- Load pages fully in headless browsers. Assets and all. This produces a far more realistic traffic profile and frequently improves success rate as a side effect.
- Store raw responses. Parse later, from storage. A parser bug becomes a reprocessing job rather than a re-crawl.
- Retry generously. Recoverable failures get recovered instead of being written off to save bandwidth.
- Crawl exhaustively rather than sampling. Coverage gaps you'd have accepted become unnecessary.
- Fetch redundantly for reliability. Where data quality matters more than efficiency, redundant collection is now free.
- Stop having bandwidth conversations. The engineering attention previously spent on byte reduction goes to coverage, accuracy, and success rate instead.
Architecture Patterns for Unmetered Work
Store raw, parse later. Bandwidth is free, but re-crawling still costs days. Persist the original response and process asynchronously from storage. A parser bug becomes a reprocessing job rather than a re-collection project.
Decouple fetching from everything else. A queue between fetch and process. If parsing, deduplication, enrichment, or database writes run inside the request loop, they become your throughput ceiling and the purchased capacity sits idle.
Per-domain rate budgets alongside aggregate saturation. These aren't in tension. Assign each target a request-rate ceiling and run many targets concurrently. You stay considerate to individual sites while keeping the aggregate pipe full.
Continuous scheduling rather than batch windows. Spreading work across the full day uses capacity you've already bought and hits targets more gently. Compressing into a window wastes capacity and looks worse to the target.
Utilisation monitoring as a first-class metric. Aggregate bytes per second against purchased capacity, tracked continuously with an alert on sustained low utilisation. Low utilisation is money leaking, and without instrumentation nobody notices.
Success rate as the primary efficiency metric. With the byte meter off, this is what converts capacity into data. Failed requests consume throughput and produce nothing, so success rate improvements are now the highest-leverage optimisation available.
Backpressure throughout the pipeline. A fetcher capable of saturating a large connection can overwhelm your own storage, database, or downstream processing. Build the ability to slow down deliberately.
Checkpointing and resumption. Crawls at unmetered volumes run for days. Make requests idempotent, persist progress, and assume the process will be interrupted at some point.
Troubleshooting
Symptoms and their usual causes:
- Throughput far below what you purchased — almost always client-side. Check connection pool limits, concurrency, keep-alive, and synchronous bottlenecks before contacting the provider.
- Throughput plateaus regardless of concurrency — you've hit either the purchased ceiling or a downstream bottleneck. Instrument each pipeline stage separately to find out which.
- Sudden throttling on an unlimited plan — a fair use threshold. Check the terms and contact the provider rather than assuming a fault.
- Unmetered but still slow — bandwidth and latency are different things. Unmetered says nothing about round-trip time, which is determined by the network type and gateway location.
- Rate limited by targets despite unmetered bandwidth — data volume and request rate are separate constraints. Unmetered removes the data cost, not the pacing requirement.
- Costs higher than expected on a throughput plan — you sized the tier wrong or utilisation is low. Recalculate from measured throughput rather than headline capacity.
- Some endpoints metered, others not — check whether the policy differs by protocol or product line.
- Per-address caps hitting on an aggregate-unmetered plan — read the per-IP terms.
Common Mistakes
Buying unmetered residential without testing datacenter first. The most expensive mistake available in this category. Unmetered datacenter costs a fraction as much, and a large share of targets don't check classification at all. Five hundred test requests answers it.
Estimating consumption instead of measuring it. Guessed averages produce errors of several hundred percent, and the error propagates straight into a wrong purchase.
Forgetting the success rate divisor. Failed requests consume bandwidth. At a 50% success rate you're funding twice the traffic you get data from, and that doubles your metered bill.
Averaging browser and non-browser traffic together. The multiplier is large enough that blending them hides where the cost actually is. Measure separately.
Buying unmetered and then not using it. Running at 25% utilisation because of a default connection pool limit means paying four times what your data costs. This is extremely common and almost always fixable in an afternoon.
Assuming unmetered means unconstrained. Request rate, concurrency, and fair use policies still apply. Targets will still rate limit you regardless of what your plan permits.
Continuing to optimise for bytes after switching. The whole value of the switch is redirecting that engineering attention to success rate and coverage. Teams that keep stripping page loads out of habit capture a fraction of the benefit.
Sizing a throughput plan from headline capacity. Real utilisation is typically 40–50%. Sizing at 90% and achieving 35% means buying a plan that can't do the job.
Ignoring latency. Unmetered says nothing about round-trip time. A plan with enormous capacity and distant gateways may deliver less useful throughput than a smaller, closer one.
Evaluating an Unmetered Plan
Criteria that predict real-world value:
- Whether unmetered means unmetered, or unmetered subject to a fair use policy with an undisclosed threshold
- Actual achievable throughput, measured yourself under parallel load during a trial rather than taken from marketing
- Concurrent connection limits, explicit or otherwise
- Whether request rate is separately limited
- Per-address caps within an aggregate-unmetered plan
- Protocol parity — the same terms on HTTP and SOCKS5
- Underlying IP classification, which determines whether the bandwidth is usable on your targets at all
- Gateway locations relative to your targets, since latency limits throughput independently of any cap
- Upgrade and downgrade terms, particularly on throughput-priced plans where sizing errors are common
- Contract length, which is often longer where the provider is reserving capacity
Test with sustained load, not a single request. A plan that connects flawlessly and delivers a third of its advertised throughput under real parallel load is a plan you'll regret, and connectivity tests won't reveal it.
Unmetered Compared Across Products
Bandwidth policy cuts across every proxy category, and the comparison is worth laying out explicitly because it's the axis buyers compare last.
Unmetered datacenter. The cheapest unmetered bandwidth available and the correct default for anything volume-heavy on permissive targets. You pay per address; data is free. The only limitation is classification — hosting-registered addresses are identifiable, and some targets refuse them outright.
Unmetered dedicated. Same bandwidth economics with exclusive reputation control. Costs more per address, and the bandwidth policy is usually inherited unchanged from the shared datacenter product.
Unmetered ISP. Residential classification with datacenter bandwidth economics. This is the quietly strong combination for anything that needs to look residential and moves substantial data — browser automation on protected targets being the obvious case. The constraint is pool size, since ISP inventory is small and heavy volume concentrates on few addresses.
Metered residential. The industry default for rotating residential, priced per gigabyte. Right for modest or spiky volumes on protected targets, and increasingly wrong as volume grows.
Throughput-priced residential. Unmetered on volume, priced by sustained rate. Right for continuous terabyte-scale ingestion, wrong for anything below the floor price or with bursty traffic.
Metered mobile. Almost always metered, at the highest per-gigabyte rates in the market, because the provider is paying real carrier bills. Bandwidth-heavy work through mobile is a bad idea on both cost and performance grounds.
The selection heuristic that follows: classification first, then bandwidth model. Establish the cheapest classification your target accepts by testing, then pick the bandwidth model that fits your volume within that classification tier. Doing it the other way round — choosing a bandwidth model first and then discovering the classification doesn't work — is how people end up paying residential throughput prices for work datacenter would have handled.
Legal and Ethical Considerations
- Unmetered bandwidth removes a natural brake on volume, which makes deliberate self-restraint more important rather than less
- Scale amplifies impact. A pipeline capable of terabyte throughput can degrade a target site without anyone intending it. Per-domain rate limiting is basic conduct, not just self-protection
- Data protection law applies to what you collect regardless of volume or routing
- Public data collection and authentication circumvention remain legally distinct categories
- Large-scale collection attracts more scrutiny than small-scale collection, which is worth factoring into how you document and justify your work
- Respect published crawl directives and rate guidance where they apply to you
Not legal advice, and jurisdictions differ. At the volumes unmetered plans enable, having a lawyer review your specific case is genuinely warranted rather than a formality.
Frequently Asked Questions
Is unlimited bandwidth really unlimited?
Unlimited in data volume, in nearly all cases. Throughput, concurrency, or fair use policies usually impose a practical ceiling elsewhere. Read the terms.
Why do residential proxies meter bandwidth when datacenter proxies don't?
Cost structure. Datacenter bandwidth is close to free at scale. Residential networks compensate node operators for consumer bandwidth that genuinely costs money, and mobile providers pay real carrier bills.
Does unmetered mean I can send unlimited requests?
No. Data volume and request rate are separate constraints. Targets will still rate limit you for requesting too often, regardless of how much data you're allowed to move.
Is unmetered always cheaper?
No. Unmetered products have a floor price. Below roughly a few hundred gigabytes a month on protected targets, metered per-gigabyte billing is usually cheaper.
Why is my throughput lower than advertised?
Almost always client-side configuration — default connection pool limits, insufficient concurrency, no keep-alive, or a synchronous bottleneck downstream of the fetch.
Should I still optimise bandwidth on an unmetered plan?
Not for cost. Do optimise success rate, because failed requests consume capacity and produce nothing. And be considerate to targets regardless of what your plan permits.
What's the difference between unmetered datacenter and unlimited residential?
Price and classification. Unmetered datacenter costs a fraction as much; unlimited residential provides residential classification for targets that check. Test datacenter first — if it works, the decision is made.
Can I run headless browsers on unmetered plans?
That's one of the strongest reasons to have one. Browsers multiply bandwidth by an order of magnitude, which is punishing on a meter and free without one.
Where to Get Unlimited Bandwidth Proxies
If your workload is bandwidth-heavy on targets that don't require residential classification, ProxyScrape's unlimited bandwidth proxies remove the meter entirely on their premium datacenter plans, with unlimited concurrent connections and both HTTP(S) and SOCKS5 support — the configuration that makes headless browser automation, full-site crawling, and high-volume link checking affordable rather than anxious. If testing shows your targets do require residential classification and your volume is genuinely large, their unlimited residential plans price by throughput instead of gigabytes, and for smaller or spikier workloads their metered residential is usually the cheaper answer.
→ Compare unmetered plans against your measured bandwidth consumption
The bandwidth model is the specification that most often decides whether a proxy purchase was a good one, and it's the one people compare last. Measure your real consumption including failed requests, test whether your targets actually require residential classification before assuming they do, and then run the arithmetic both ways. Removing the meter is worth far more than the line item suggests when it stops your engineering team optimising for the wrong constraint — but it's worth nothing at all if you're paying an unmetered floor price to move two hundred gigabytes.