DEV Community: Michael Guy

When Pay-Per-GB Proxy Pricing Stops Making Sense

Michael Guy — Sun, 01 Nov 2026 20:05:02 +0000

High-volume data collection creates a simple but expensive pricing problem: when a crawler transfers more data, a pay-per-GB bill rises at exactly the same time.

That model can be perfectly reasonable for small or irregular workloads. It becomes harder to forecast when collection runs continuously, retries increase, or several workers operate in parallel.

The two pricing models

1. Pay per GB

The cost is directly tied to transferred traffic:

traffic cost = transferred GB × price per GB

This is easy to understand and often economical for short tests. The drawback is that every retry, duplicate response, large asset, and failed extraction still consumes metered traffic.

2. Throughput-based, unmetered access

A throughput-based plan uses a fixed speed and a fixed duration. The bill is based on the selected capacity and period rather than the number of gigabytes transferred.

“Unmetered” means there is no data cap during the purchased duration. It does not mean infinite instantaneous transfer. The selected throughput remains the capacity constraint.

That distinction matters because a plan should be sized around both traffic volume and the rate at which the application must move it.

A simple break-even calculation

For a fixed-price plan, the traffic level at which it becomes cheaper than pay-per-GB is:

break-even GB = fixed plan price ÷ pay-per-GB rate

Suppose a team currently pays $3 per GB. A workload transferring 100 TB in decimal units is approximately 100,000 GB:

100,000 GB × $3/GB = $300,000

That is an illustrative comparison, not a universal market price. Real rates, taxes, discounts, and billing units vary. The useful part is the formula: replace the assumptions with your own numbers before making a decision.

Check whether the throughput can carry the workload

Cost is only half of the comparison. A fixed-throughput plan must be able to deliver the required volume inside the selected period.

For example, 400 Mbps running continuously for 30 days has a theoretical transfer ceiling of roughly 129.6 TB in decimal units:

400,000,000 bits/s ÷ 8 × 2,592,000 seconds
≈ 129.6 TB

Actual application throughput will be lower. Protocol overhead, target response times, connection setup, retries, geography, and the success rate of each request all reduce the amount of useful data collected.

This is why the best plan is not automatically the fastest one. It is the smallest throughput tier that can complete the real workload with reasonable headroom.

What to include in the comparison

Before changing pricing models, measure:

Useful traffic, not only total traffic.
Peak and average throughput across workers.
Retry volume caused by timeouts, blocks, or invalid responses.
Session behavior, including rotating and sticky sessions.
Protocol requirements, such as HTTP, SOCKS5, or UDP over SOCKS5.
Location availability for the countries or regions being targeted.
Duration, because a one-day burst and a continuous 30-day pipeline need different capacity.
Acceptable-use requirements, especially for automated collection and ad-related workflows.

For residential proxy workloads, the available IP pool also matters. A plan can provide access to more than 4 million rotating or sticky residential IPs without charging per individual proxy, while the commercial variable remains throughput and duration.

Use a calculator with editable assumptions

I built a residential proxy cost calculator to make the comparison easier. It lets you change the traffic assumption and compare it against available throughput and duration combinations.

The calculator is most useful as a planning tool:

Enter a realistic monthly traffic estimate.
Use the actual per-GB rate from your current bill.
Select a throughput tier that can carry the workload.
Add headroom for retries and slower targets.
Compare the total cost over the same period.

Takeaway

Pay-per-GB pricing is often the simplest choice for experiments and low-volume jobs. Unmetered throughput becomes more attractive when traffic is large, continuous, or difficult to predict.

The right comparison is not “unlimited versus metered” in isolation. It is:

total cost + required throughput + successful data delivered

Once those three numbers are measured, the decision becomes much less subjective.

How to Rotate Proxies in Python with Requests (2026 Guide)

Michael Guy — Mon, 28 Sep 2026 21:29:40 +0000

Originally published on UnlimitedResidentialProxy.

Websites may apply rate limits or access controls to automated requests. For permitted data collection, residential proxy rotation can be one useful configuration alongside careful pacing, retries, and error handling.

Only automate requests that you are authorized to make. Respect the target website's terms, robots directives, rate limits, and applicable law.

Why rotate residential proxies?

Sending every request through one static exit can make a long-running collection job fragile. Rotating residential sessions distributes authorized requests across available exits. It does not make automation undetectable, guarantee access, or replace responsible request pacing.

Install Requests

python -m pip install requests

Configure the proxy gateway

Rotation is handled by the gateway, so your Python code does not need to maintain and validate a large list of proxy IPs.

import requests

PROXY_HOST = "<YOUR_GATEWAY_HOST>"
PROXY_PORT = "7777"
PROXY_USER = "USERNAME"
PROXY_PASS = "PASSWORD"

proxy_url = (
    f"http://{PROXY_USER}:{PROXY_PASS}@"
    f"{PROXY_HOST}:{PROXY_PORT}"
)

proxies = {
    "http": proxy_url,
    "https": proxy_url,
}

target_url = "https://httpbin.org/ip"

for attempt in range(5):
    try:
        response = requests.get(
            target_url,
            proxies=proxies,
            timeout=10,
        )
        response.raise_for_status()

        exit_ip = response.json().get("origin", "unknown")
        print(f"Request {attempt + 1}: IP is {exit_ip}")

    except requests.exceptions.RequestException as error:
        print(f"Request {attempt + 1} failed: {error}")

The timeout prevents a request from waiting indefinitely. raise_for_status() turns unsuccessful HTTP responses into exceptions, while .get("origin", "unknown") avoids a KeyError if the response shape changes.

Use SOCKS5 when needed

Install Requests with SOCKS support:

python -m pip install 'requests[socks]'

Then change the proxy URL scheme:

proxy_url = (
    f"socks5h://{PROXY_USER}:{PROXY_PASS}@"
    f"{PROXY_HOST}:{PROXY_PORT}"
)

Using socks5h:// sends DNS resolution through the proxy. The rest of the request and error-handling structure stays the same.

Rotation, sticky sessions, and targeting

The unlimited plans provide access to a shared rotating residential pool advertised at 4M+ IPs. Rotation and sticky-session behavior depend on your session configuration and live exit availability, so a new or unique IP is not guaranteed for every request.

For country targeting, the gateway username can include a country parameter such as -country-us. Use the exact syntax supplied in your dashboard and verify availability for the location you need.

Practical troubleshooting

Confirm the gateway host, port, username, and password.
URL-encode special characters in credentials when necessary.
Keep timeouts enabled and add bounded retries with backoff.
Test through an IP-check endpoint before running a larger job.
Reduce concurrency when the target begins returning rate-limit responses.
Do not assume that every request must return a different exit IP.

Choosing bandwidth for larger workloads

Unlimited plans are priced by aggregate throughput and duration rather than by traffic volume. If you are comparing throughput tiers, use the residential proxy cost calculator or review the unlimited residential proxy plans.

For the maintained version of this tutorial, see the original Python proxy rotation guide.