Proxy providers price access in two fundamentally different ways: by the gigabyte of bandwidth consumed, or by the number of IP addresses (or ports) you hold. Each model rewards a different type of workload, and choosing the wrong one can result in a bill two or three times higher than necessary. This guide explains both models, works through practical examples, and covers the hidden costs that are easy to miss in a pricing comparison.

The Two Main Proxy Pricing Models

Almost every proxy pricing structure is a variation of one of two underlying models:

Bandwidth-based pricing: you pay per gigabyte of data transferred through the proxy, regardless of how many IPs you use or how many requests you make.
IP-count-based pricing: you pay for a fixed number of IP addresses (or ports, or threads), typically on a monthly subscription, regardless of how much data you transfer through them.

Some providers offer hybrid models that combine elements of both, and a small number price per request rather than per byte. We cover those variations in the sections below.

For context on what you are actually buying under each model, our guide to what a residential proxy is and our comparison of residential vs datacenter proxies explain the underlying infrastructure.

How Bandwidth-Based Pricing Works

Under bandwidth-based pricing, every byte that passes through the proxy gateway is metered. You purchase a pool of gigabytes (say, 10 GB, 50 GB, or 500 GB) and draw it down as you use it. When the pool is exhausted, you either pay for an overage, top up, or stop until the next billing cycle.

Bandwidth-based pricing is the dominant model for residential proxy networks because the underlying cost driver on the provider side is also bandwidth: compensating the device owners whose connections carry traffic is proportional to how much traffic actually flows, not how many IPs sit idle.

What counts toward your bandwidth?

This varies by provider, but the common approaches are:

Egress only: only data sent from the proxy to the target server counts. Response data (downloads) does not count or counts at a lower rate. This model benefits use cases that send large requests but receive small responses.
Total transfer: both upload and download count. This is more common and more predictable. If you request a 500 KB page, 500 KB (plus request overhead) is metered.
Failed requests: some providers count bandwidth on blocked or failed requests; others do not. This can significantly affect cost when your target site has aggressive blocking.

LocalProxies meters total transferred data and does not charge for internally retried requests that fail before reaching the target. Starting at $2.10/GB, the rate steps down as volume increases; see the setup tutorial for plan details or the FAQ for billing specifics.

How IP-Count-Based Pricing Works

Under IP-count-based pricing, you pay a flat monthly fee for access to a defined number of IP addresses or concurrent connection ports. Transfer through those IPs is either unlimited or subject to a very high soft cap.

This model is common for datacenter proxies and ISP proxies (hosted static residential IPs) because the provider’s underlying cost is fixed infrastructure (server slots, IP block leases) rather than variable traffic. A datacenter IP sitting idle costs the provider almost the same as one under heavy load.

Variants of IP-count pricing

Per-IP subscription: you pay $X/month per dedicated IP. Common for static residential and ISP proxies where each IP is exclusively yours.
Per-port (thread) subscription: you pay for a number of concurrent connection slots into a shared IP pool. Each port can open one connection at a time; holding 10 ports means 10 simultaneous requests. This is the typical model for shared datacenter proxy plans.
Per-subnet: you lease an entire IP block (e.g., a /24 with 256 addresses) at a fixed monthly rate. Used primarily for large-scale operations that need IP diversity within a single autonomous system.

Which Model Costs Less for Your Use Case?

The answer depends on two variables: how much data each request transfers, and how intensively you use each IP.

Worked examples

Example A: Light scraping with large page sizes (e-commerce catalog). You scrape 50,000 product pages per month. Each page response averages 300 KB. Total data: 50,000 × 300 KB = 15 GB/month.

Under bandwidth pricing at $2.10/GB, this costs approximately $31.50/month for the data volume alone. Under IP-count pricing, if you need only 5 concurrent threads and the plan costs $8/port/month, the total is $40/month: slightly more, and your throughput is constrained by 5 simultaneous connections.

In this scenario, bandwidth pricing wins if data transfer rates are competitive and you don’t need high concurrency on a fixed IP set.

Example B: High-frequency, low-payload monitoring (price checks). You check 500,000 product prices per month. Each response is 8 KB (a structured JSON endpoint, not a full HTML page). Total data: 500,000 × 8 KB = 4 GB/month.

Under bandwidth pricing at $2.10/GB: approximately $8.40/month. Under IP-count pricing with 20 ports at $8/port/month: $160/month, dramatically more expensive for the same task. Bandwidth pricing is clearly better here.

Example C: Account management requiring static IPs. You manage 50 accounts on a platform, each needing a consistent IP to avoid triggering security alerts. You make modest traffic (perhaps 1 GB total per month across all accounts).

Under bandwidth pricing at $2.10/GB: approximately $2.10/month, but you cannot guarantee IP persistence across sessions. Under IP-count pricing, 50 dedicated static IPs at $5/IP/month: $250/month; expensive, but you get guaranteed IP consistency.

Here, the technical requirement (static IPs) makes IP-count pricing necessary regardless of cost. The question becomes whether static residential or datacenter IPs are needed. For AI agent workflows that maintain persistent sessions, see our guide to AI agent proxy use cases.

Example D: Large-scale web scraping (news aggregation, market research). You process 2 million pages per month with an average response size of 120 KB. Total: 2,000,000 × 120 KB = 240 GB/month.

Under bandwidth pricing at $2.10/GB with volume discounts (assuming $1.50/GB at this scale): approximately $360/month. Under IP-count pricing with 200 ports at $8/port/month: $1,600/month. Bandwidth pricing wins significantly at scale for high-volume scraping. See our scraping use case guide for more context: web scraping proxies.

Hidden Costs: Overages, Minimums, and Session Fees

The headline rate is rarely the full picture. These are the most common additional costs to factor in:

Bandwidth overages

Many bandwidth plans include a base pool and charge a higher per-GB rate for usage beyond it. Overage rates are often 1.5–3x the base rate. If your workload is unpredictable, this can make bandwidth plans expensive. Check whether the provider allows you to cap usage (and refuse requests once the cap is hit) rather than silently accumulating overages.

Minimum commitments

Both model types frequently have monthly minimums: either a minimum data purchase (e.g., 10 GB minimum regardless of use) or a minimum number of ports/IPs. For small or early-stage operations, minimums can make a plan structurally expensive even if the per-unit rate is low.

Session and rotation fees

Some bandwidth-based providers charge an additional fee per session opened, per IP rotation event, or per sticky session maintained beyond a base time. If you open millions of short sessions, these can exceed the bandwidth cost itself. Ask explicitly whether session management has separate pricing.

Failed request billing

If a provider counts bandwidth on blocked or errored requests, your effective cost per successful request is higher than the headline rate implies, especially on targets with aggressive bot detection. This is most relevant for large-scale scraping workflows.

Setup and API fees

Some providers charge for dashboard API calls, sub-user creation, or advanced features like ISP-level targeting. These are rarely listed prominently.

How to Estimate Your Monthly Proxy Spend

A reliable estimate requires three numbers:

Request volume: total requests per month.
Average response size: sample 50 to 100 real responses from your target and measure the average payload size in KB. Do not use the HTML source size. Include images, scripts, and other assets if your scraper loads them, or use only the HTML size if you are making targeted API-style requests.
Success rate: if 15% of requests fail and you are billed for failed bandwidth, your effective cost per successful request is ~18% higher than the headline rate implies.

Calculation formula for bandwidth-based pricing:

Monthly cost = (requests × avg_response_KB / 1,000,000) × GB_rate × (1 / success_rate)

For IP-count pricing:

Monthly cost = concurrent_threads_needed × port_rate + (any overage GB × overage_rate)

The number of concurrent threads needed is determined by your target throughput and the latency per request. If each request takes 2 seconds and you need to process 3,600 requests per hour (1 per second), you need at minimum 2 concurrent threads, but in practice, you want headroom, so 5 to 10 threads for that workload.

For a more detailed treatment of how many IPs different workload sizes actually require, see our guide on how many IPs you need for web scraping.

How LocalProxies Approaches Pricing Transparency

LocalProxies uses bandwidth-based pricing for its residential proxy network, starting at $2.10/GB with volume discounts at higher tiers. The decision reflects how the underlying network works: costs on the provider side scale with data consumed, not with IPs held idle, and passing that structure through to customers aligns incentives.

A few specifics worth knowing:

Bandwidth is metered on total data transfer (upload and download combined). There is no separate session fee or rotation fee; you can open as many sessions and rotate as frequently as your workload requires without additional per-event charges.
Failed requests that return an error before any data is transferred do not count against your bandwidth pool. If a target returns a connection refused before sending any bytes, it is not billed.
There is no overage surcharge; if you exceed your purchased pool, you are notified and can top up rather than receiving an automatic charge at a higher rate.
Sub-user and per-agent quota isolation is available at no additional cost, which matters for agentic workflows where multiple AI agents share a single account but need independent spend tracking. See our AI agent use case guide for more on that pattern.

If you are trying to estimate cost for a specific workload, the setup tutorial includes a bandwidth estimator, and the FAQ covers billing mechanics in detail. You can also request a trial to measure actual bandwidth consumption on your target before committing to a plan.

The right pricing model is the one that matches your workload structure, not the one with the lowest headline number. Running the calculation above against your actual request volume and response sizes will give you a reliable basis for comparison across any provider’s pricing page.