SparkProxy vs PacketStream: Cost per Successful Fetch

A gigabyte that fails half the time is not cheap. On a metered network you pay for bytes that moved, not pages you kept, so the figure that governs your bill is cost per successful fetch:

cost per successful unit = list rate x billed bytes per success

billed bytes per success = kept + ((1 - p) / p) x discarded

  kept      = bytes a successful attempt moves and you keep
  discarded = bytes a failed attempt moves and you throw away
  p         = per-attempt success rate against YOUR target

Three of those four inputs are yours to measure. Only the list rate is published.

One question comes before any of that, because it can end the comparison outright. The two vendors sell different goods, not two prices for the same good. PacketStream sells peer-sourced household residential exits, and says so plainly: "Traffic exits through consumer ISPs rather than data-center networks." SparkProxy sells the other side of that sentence, "1M+ datacenter IPs across 80+ Countries" plus "50,000+ premium US datacenter IPs" and a managed Scraping API, and runs no peer-sourced household network at all. Our primer on P2P proxy networks covers why peer-sourced pools behave differently from operator-run ones.

Before the sums, the caveat that outranks all of them: a datacenter range and a household residential range are not interchangeable inputs. Plenty of targets pass both. Some pass only residential traffic, and against those the right-hand column below is unavailable to you at any price, because a cheaper plan your target rejects costs infinity per useful page. So the first thing to test is acceptance, not cost: run a few hundred of your real URLs through a datacenter pool and count how many come back with the field you came for. Everything after this assumes that test passed.

Then take the easy case, p = 1.0, nothing fails. PacketStream costs $1.00 per useful GB. SparkProxy Starter is $75 a month for 100 concurrent threads with unlimited bandwidth. They cross at 75 GB a month, and neither pricing page mentions it.

Both PacketStream columns assume p = 0.70, an illustrative figure and not a measurement. They differ only in what a failure throws away, and that alone moves the crossover from 73.6 GB to 52.5 GB, a 29% swing in your break-even from one unmeasured input.

Two PacketStream terms push the low-volume rows further in its favour. The standard customer minimum purchase is $50, so a 10 GB month costs one $50 top-up rather than $10. But balance "does not expire merely because time passes" (Terms section 4), and the pricing page puts it as "Nothing renews, nothing expires". That $50 is a floor on the purchase, not on the month: spread over six quiet quarters it's still $50, while a subscription bills through every one of them. For the general shape of this trade, see per-IP vs per-GB proxy pricing and residential proxy pricing explained.

Nobody buys gigabytes. You buy pages, records or completed sessions, and the conversion rate between those and gigabytes belongs to your targets, not to the proxy. A 40 KB JSON endpoint and a 2.4 MB retail product page differ by sixty times on the same price list.

Measure it with curl before modelling anything. One line per attempt, status first so you can split successes from failures:

# $PROXY holds the gateway under test, in curl's -x form.
while read -r url; do
  curl -s -o /dev/null -x "$PROXY" \
    -w "%{http_code} %{size_download} %{size_upload} %{time_total}\n" \
    --max-time 45 "$url"
done < urls.txt | tee attempts.log

# Per-attempt success rate.
awk '{t++} $1==200 {s++} END {printf "attempts=%d ok=%d p=%.3f\n", t, s, s/t}' attempts.log

# Bytes you keep on success vs bytes you throw away on failure.
awk '$1==200 {k+=$2+$3; kn++} $1!=200 {d+=$2+$3; dn++}
     END {if (kn) printf "kept_avg=%.0f B over %d\n", k/kn, kn
          if (dn) printf "discarded_avg=%.0f B over %d\n", d/dn, dn}' attempts.log

Two caveats. size_download counts the body, not TLS handshakes, headers or transport retries, so the gateway's meter reads higher than curl's: treat the result as a floor and pad it. And a 200 is not always a success. Soft blocks return 200 with a challenge in the body, and those are the expensive failures because the full payload already crossed the meter. Add a body marker check or your measured p will be flattering and wrong. Forecasting proxy bandwidth turns a sample like this into a monthly figure.

Here is the retry tax at p = 0.70, sorted by how much work a failure destroys. Page weights are assumed so the mechanism is visible; substitute your own.

The lesson isn't "retries are expensive". A cheap block adds 2% and barely registers. The failures that hurt discard work you already paid to transfer: a soft block found after the body landed, or a multi-step session that dies mid-walk and forces a re-walk. One function prices any target:

def effective_rate(list_rate, p, kept_bytes, discarded_bytes):
    """Cost per USEFUL GB once failed attempts are billed too."""
    if not 0 < p <= 1:
        raise ValueError("p must be a measured success rate in (0, 1]")
    retries_per_success = (1 - p) / p
    billed = kept_bytes + retries_per_success * discarded_bytes
    return list_rate * billed / kept_bytes


for p in (0.95, 0.85, 0.70, 0.50):
    cheap = effective_rate(1.00, p, 900_000, 40_000)
    full = effective_rate(1.00, p, 900_000, 900_000)
    print(f"p={p:.2f}  cheap block ${cheap:.2f}/GB   full payload ${full:.2f}/GB")

# p=0.95  cheap block $1.00/GB   full payload $1.05/GB
# p=0.85  cheap block $1.01/GB   full payload $1.18/GB
# p=0.70  cheap block $1.02/GB   full payload $1.43/GB
# p=0.50  cheap block $1.04/GB   full payload $2.00/GB

To collect p honestly, run one URL list through both vendors on the same afternoon at the same concurrency, and count a fetch as successful only when your parser extracts the field you came for. PacketStream has no self-serve free trial: credit is discretionary and human-reviewed, the trial page says "A real person reads every request", and the FAQ confirms "both approval and the amount of credit are discretionary", so budget a small paid top-up instead. SparkProxy gives a 24-hour trial with no card plus 1,000 Scraping API credits on signup. Rendering bills 5 credits and a plain HTTP fetch bills 1, so that allowance is about 200 rendered pages or 1,000 plain fetches, no more. Batch mode stretches it: a single request can carry a comma-separated list of URLs for one credit, which is how a free account surveys more than a thousand pages. Its one restriction is spelled out further down, where the static-page workloads get priced.

Read the SparkProxy side out of the API envelope rather than inferring it:

import base64, requests

r = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={
        "url": "https://www.sparkproxy.io/pricing",
        "render_js": "false",     # plain HTTP fetch: 1 credit, 3x faster than Chromium
        "json_response": "true",  # envelope, not raw content
    },
    timeout=60,
)

env = r.json()
html = base64.b64decode(env["body"]).decode("utf-8", "replace")
print(env["status_code"], env["duration_ms"], env["credits_used"], len(html))

Only json_response=true gives you that envelope, and it carries job_id, status_code, duration_ms and credits_used, with the page content inside it base64-encoded. Decode body before matching a marker string, or every soft-block check you write will silently pass. format=json is a different parameter that converts content and gives you no envelope. To read the target's status off the HTTP response itself, transparent_status_code=true mirrors it, in plain HTTP mode only.

PacketStream publishes no success rate, no uptime figure and no SLA, and says so rather than leaving you to guess. Terms section 4: "PacketStream does not guarantee a particular exit, country, IP address, response time, success rate, availability, or uninterrupted session." Section 13 adds that the service is "AS IS" and "AS AVAILABLE" and "DOES NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED, SECURE, ERROR-FREE, OR SUITABLE FOR A PARTICULAR DESTINATION OR WORKLOAD." Section 2 is as direct about capacity: "Exit availability changes continuously." That's a clearer disclosure than an unauditable success-rate badge. It also means the second input to the formula has no vendor-supplied value at all.

Five of those rows need a note. PacketStream publishes no IP, peer or device count anywhere on its site, so there's no number to set against SparkProxy's 1M+, and anyone quoting a PacketStream pool size is quoting something the vendor doesn't claim. Their locations page lists 30 countries with setup pages and states no pool-wide total; its entire instruction to the reader is "Pick a country below for its auth-key pattern and code examples", so thirty counts published pages, not stated coverage.

Our own two numbers are exactly the kind of badge that paragraph just criticised, so they earn the same scepticism. "99%+ Success Rate" and "99.9% Uptime" are site-wide claims on sparkproxy.io, not measurements against your targets, which is why the last column reads "Yes, both" on those two rows. And the refund row is the one where our terms are worse than theirs: PacketStream gives you 24 hours against a remaining balance, while SparkProxy's refund policy states that payments "are final and non-refundable" and that "No pro-rata refunds are issued for early cancellation". That is why the free trial exists, and why you should spend it before you spend $75.

PacketStream describes its sourcing plainly: "PacketStream is a peer-to-peer residential proxy network. Real users around the globe ("Packeters") run the desktop app, and businesses route traffic through those household connections with country targeting." Peers earn $0.10 per GB routed. PacketStream's own first-party traffic runs through the same peers at the same rate, disclosed in the Terms. That architecture produces failure modes they document, and others that follow from it, and each one maps onto a term in the formula.

A sticky session dies with its peer. Their docs: "A sticky session depends on the Packeter providing its exit. If that Packeter disconnects, the session fails. PacketStream does not silently switch the session to a different identity." That's the expensive row in the table above, because the multi-step state you built goes with it.

A household uplink is a shared uplink. Their own description of the architecture sets this one up: traffic "exits through consumer ISPs rather than data-center networks" and every exit is "a real user running the PacketStream desktop app and choosing to share bandwidth". Whatever capacity that connection has left while its owner is streaming is the capacity your request gets, which shows up as slow first bytes, stalls part-way through a body, and connections that drop after the transfer started. That lands on the discarded term rather than on p alone: an attempt that moves 600 KB of a 900 KB page and then dies has already crossed the meter and left you nothing to parse. Set client timeouts from a measured distribution instead of a guess, and count partial bodies as failures when you compute p, because the gateway counted their bytes.

Rotation promises selection, not uniqueness. A new proxy connection triggers a new exit selection, but "the selected IP is not guaranteed to be different from the previous one" and "The contract is exit selection for each new connection, not uniqueness across a sample." A retry handler that assumes a fresh connection means a fresh IP will retry into the same blocked address and bill you for it, so you need your own IP scoring and eviction keyed on the exit you observed.

Sticky lifetime beats the marketing number, in one direction. Marketing says "up to 60 minutes"; the docs define a rolling inactivity timeout, where "Each time PacketStream assigns the session to a new proxy connection, the timeout restarts", so a chatty session can outlive an hour. Sixty minutes of silence still ends it, which matters if your walk has a long think-time gap. Our explainer on sticky session proxies covers shaping a walk around that.

No proxy-side concurrency figure is published. The rotation docs put it on you: "The application remains responsible for its own concurrency, timeouts, retries, and connection-pool configuration." An absence of a stated cap is not a stated absence of a cap, and the 4-request limit in their docs belongs to the separate Fetch API. Ramp parallelism on a trial and watch error rates. Concurrent connections in proxies explains why that ceiling usually binds before pool size does.

Targeting stops at the country boundary, by design rather than omission: "Country is the supported targeting boundary. City, region, postal code, and coordinates reported by IP databases are approximate diagnostic data, not targeting guarantees." Syntax is an auth-key suffix, AUTH_KEY_country-US, and no city, state, ASN or carrier selector exists, so a brief needing sub-country precision can't be served at any price.

The exit's ASN is picked for you. Country is the whole selector, so whichever household ISP range you land in, you inherit that range's reputation at your target. Consumer ranges do not all carry the same block-rate prior, and no part of the auth key lets you prefer one over another. That makes the ASN an input to p you can neither choose nor hold constant, which is the real reason a success rate has to be measured per target instead of quoted: a figure sampled on one afternoon's exits is a sample, not a property of the network.

Reading every failure as a defect would be wrong, and PacketStream earns credit here. Their docs commit to failing rather than guessing: "If a recognized country has no available exits, PacketStream fails the request. It does not silently substitute another country." The sticky-session rule has the same shape. A failed request is a visible problem; a request that quietly exits in the wrong country returns plausible data from the wrong market, and you may not notice for a quarter.

For geo-pricing audits, fare research, ad verification or localisation QA, that's the behaviour you want. Their docs also warn against the obvious anti-pattern: don't strip the country constraint in a generic retry handler, because doing so "can turn a visible availability failure into plausible data from the wrong market". Write retries so a country failure retries the same country or escalates, never widens.

One asterisk from the same page: fail-closed applies to recognised ISO codes. "PacketStream ignores a code it does not recognize, and the request then exits in any country." Validate codes before they reach the auth key, because a typo doesn't fail, it silently globalises.

On a metered network the customer absorbs failure, so the retry layer isn't optional engineering. A minimum version has five parts:

1. Attempt accounting recording status, bytes in and out, exit IP and outcome, so p is a measurement rather than a feeling.
2. A success test that reads the body, not just the status, because soft blocks return 200 after the payload is billed.
3. IP scoring and eviction keyed on the observed exit, since a new connection may hand you the same address.
4. Session re-walk logic with a cap, so one unlucky peer can't eat a day's budget.
5. Self-imposed concurrency control and a byte-budget alarm, because prepaid balance is a hard ceiling that stops the job rather than raising an invoice.

Budget a few engineer-days for a first version you then own permanently. The honest comparison isn't that a flat plan lets you skip this, because attempt accounting and IP scoring earn their keep on any network. It's that the consequences differ: on unlimited bandwidth a retry costs wall-clock time and a thread slot, while on a meter it costs money, which makes the retry budget a finance decision. Reducing proxy bandwidth costs covers byte-level tactics that pay off on a meter and are merely nice on a plan.

Assumptions are stated per brief, not measured. Swap in your own p and page weights.

Quarterly competitor price check. 8 GB of useful data a quarter, static HTML, cheap blocks. PacketStream: about $8.15 of effective spend per quarter against one $50 top-up that covers roughly six quarters and never expires. SparkProxy: $225 a quarter whether the job runs or not. PacketStream wins outright, and not narrowly. Buy the meter.

Seasonal retail monitor. Hard for six weeks, idle the rest of the year, 180 GB useful in the burst, hardened targets where blocks arrive after the full payload. At p = 0.90 that's $200 of credit; at p = 0.70, $257; at p = 0.50, $360. SparkProxy is two months of Starter at $150 if 100 threads cover the schedule, or a higher tier if they don't. Notice which uncertainty is bigger: the unmeasured success rate moves the metered bill by $160, more than the gap between vendors at the midpoint. Measure p before choosing.

Continuous crawl. 900 GB useful a month, mixed failure shapes. PacketStream runs $917 to $1,286 a month on the two columns above, every month. SparkProxy's plan price doesn't move with bytes at all, which is where unlimited bandwidth stops being a marketing word and becomes the whole bill, a case our piece on unlimited bandwidth proxies examines sceptically. The caveat from the top still binds: if the crawl only clears on household residential IPs, the plan column isn't the cheaper option here, it's an unavailable one, and acceptance is the test to run before any of this arithmetic matters.

PacketStream also sells a Fetch API, labelled early beta, at $0.0025 per fetch that returns content, with errors free: "Every error is free, including the site's own errors, timeouts, and rate limits." Read that billing unit closely, because the unit is the fetch and not the page. "A response holds up to 50,000 characters by default, or up to 500,000 with max_length", and "Each part of a long page that you read with start_index is a separate fetch and is billed separately", so a 400,000-character page is several charges unless you raise the cap and take one very large response instead. It returns main content as Markdown, follows up to 5 redirects, and doesn't read or obey robots.txt. A matching Search API charges $0.0025 per successful search, which their docs publish as "$2.50 per 1,000", and bills a search that finds nothing because the search ran.

For static pages needing no browser, a quarter of a cent a fetch with failures unbilled is aggressive pricing, and the per-attempt arithmetic above stops applying because you're no longer paying for failures. Give PacketStream this one. The published constraints are the limit: Fetch "does not run JavaScript" and returns a javascript_required 422 when a page needs one, rate limits are 5 requests per second with bursts of 10 per key, concurrency is "Up to 4 fetch requests per key run at once on each API server" with a 429 beyond that, the server time limit is 25 seconds, and max_length caps responses at 500,000 characters. Both APIs are beta with "Fields, limits, and availability may change during the beta", so re-check before building on the numbers.

Four concurrent requests is the binding constraint, not the price. SparkProxy's Scraping API answers the same job differently: render_js=false is a plain HTTP fetch at 1 credit and about three times faster than a rendered one, and batch mode takes comma-separated URLs and bills 1 credit for the whole batch regardless of URL count, with the documented restriction that batch requires render_js=false. Where a browser is genuinely required, Fetch has no answer; SparkProxy's render_js=true default costs 5 credits, js_scenario adds 5 for up to 50 browser actions, country_code adds 5, and screenshot or PDF output requires rendering.

No hedging in this section. If your workload looks like any of the following, the meter is the right purchase and a plan is the wrong one.

Under about 75 GB a month, and especially under 50. At 10 GB a month the meter costs roughly a seventh of a flat plan. Far below the crossover the gap isn't close.

Intermittent or quarterly work. Non-expiring balance does the work: pull 10 GB a quarter and you spend $10 against credit with no clock on it, while a subscription bills through every idle month.

Spiky or seasonal demand. A quiet month on a prepaid meter costs zero. A campaign-triggered ad verification job, or a monitor that runs hard for six weeks a year, is exactly the demand shape plan pricing punishes.

Proofs of concept, one-off research and client pilots. Nothing to cancel, a 24-hour refund window on remaining balance, and a hard spend ceiling you can't exceed because the balance is prepaid. Finance teams like that there's no renewal to forget, and a two-week feasibility test carries less commitment risk than any monthly plan. Our side of that comparison is plainly worse, and it belongs here rather than buried: SparkProxy plans are final and non-refundable with no pro-rata refund on cancellation, so a $75 month you abandon on day three is $75 gone. The card-free 24-hour trial is the entire risk-free window on our side, which is an argument for using it properly, not for skipping the comparison.

Cheap, high-volume plain-HTML and SERP pulls through the Fetch and Search APIs at $0.0025 with errors free, inside the beta and concurrency caveats above.

Correctness-critical country work, where wrong-market data costs more than missing data, because fail-closed is documented behaviour rather than an accident.

Small-scale white-label reselling. $500 minimum, $1.00/GB wholesale, "Fully brandable, zero PacketStream mentions", you set retail pricing, and PacketStream supports you while you support the end customer. An agency can sell proxies without building infrastructure.

One category isn't a purchase at all. The Packeter program pays $0.10 per GB routed on Windows, macOS and Linux (via Docker), with a $5 minimum PayPal cashout less a 3% fee, no inbound ports, and sharing ends when you uninstall; mobile sharing "is not currently supported". SparkProxy offers nothing comparable, so if you came looking at PacketStream to earn rather than to buy, that side of their product is the answer and this comparison isn't.

Sustained volume above the crossover. Past 75 GB of useful data a month the meter keeps climbing and a plan price doesn't. At 900 GB the difference is an order of magnitude.

Bytes you can't forecast. Image-heavy pages, inconsistent payloads, targets that change weight without warning. Unlimited bandwidth means a page that triples in size changes your runtime, not your invoice.

Hard targets with low measured p. The retry tax lands on whoever is metered, so per-GB pricing is most expensive per useful page exactly where success rates are lowest, which is the opposite of where scraping budgets get spent.

High parallelism on a schedule. SparkProxy sells concurrency explicitly, 100 threads on Starter and more above, so the ceiling is a number in your plan. PacketStream publishes no proxy-side concurrency figure in either direction, and an unpublished ceiling is hard to plan a nightly window around.

Rendering, screenshots, PDFs and selector-based extraction. render_js is on by default, js_scenario drives up to 50 browser actions, extract_rules returns structured fields by CSS selector instead of a parser you maintain, and format converts content to md, mdx or json. PacketStream's proxy is a transport; the browser layer stays yours.

IP-whitelist authentication, and a plainer transport surface. PacketStream documents username and auth-key authentication only, over HTTPS on port 31111, SOCKS5 on 31113 and a legacy HTTP port 31112, and a scan of their docs on 9 October 2026 found no allowlist option. SparkProxy carries HTTP, HTTPS and SOCKS5 with either IP whitelist or user:pass, which matters if your egress addresses are fixed and you'd rather not ship a credential into every container. Support is a draw worth stating plainly: PacketStream's FAQ says "response times vary and are not guaranteed", and SparkProxy answers by email at support@sparkproxy.io with no published response target either, so neither purchase comes with a promise about answers.

The pattern underneath all of it: metered pricing is cheapest where success rates are high and payloads are small, and a flat plan is cheapest where bytes are large, failures are frequent, or volume is steady. Pick the vendor whose billing unit matches the uncertainty you actually have. If rotation behaviour rather than price is your open question, rotating vs static residential proxies is the better next read, and how much proxies cost puts both list prices in market context. And if you arrived from a cheapest-per-GB ranking, best cheap proxy providers is a list to run this formula against rather than to buy straight off, because ranking vendors by headline rate ranks them on the single input that was never yours to measure.