SparkProxy vs Shifter: The Port Model Is Gone

Search for Shifter and most of what you'll read describes a product that is no longer on sale. The familiar pitch, a handful of "special ports" at a flat fee with unlimited bandwidth, is now documented by Shifter as the legacy port model, in a docs page whose opening line reads: "This page only applies if your dashboard shows per-port configuration and a fixed port count."

Here is what actually changed, in Shifter's own words from that page.

Shifter says existing ports "keep working indefinitely" and publishes no sunset date, so a grandfathered account is not in danger. It also publishes no port-plan price list we could find. If you are quoting a port price from a third-party review, you are quoting a product you cannot order.

The port spec still matters for two reasons: it is the only version of Shifter that was ever directly comparable to a thread plan, and if you hold one you should know what you're holding.

Shifter's documented legacy port had its own hostname and port number, a rotation interval you set yourself anywhere from 5 to 60 minutes, up to 50 concurrent threads, no bandwidth metering, and country-level targeting. Plans came with "a fixed number of ports (typically 10-minimum tiers)."

Run the arithmetic and a port was a bundle of 50 threads with a rotation timer attached. A 10-port plan was a 500-thread plan that rotated on a clock, which maps cleanly onto SparkProxy's ladder: 500 concurrent threads is the Boost plan at $240 a month, with unlimited bandwidth, 1M+ datacenter IPs and the two rotation modes sparkproxy.io publishes, Random Rotation and Auto 5-min Rotation. The two caveats are Shifter's own. Port plans were country-level only, and per its migration notes they "rotate only on the configured interval," so there was no way to get a fresh IP mid-session. If your work needs an IP per request, the legacy port never gave you one.

What a saturated port did is not documented. This is the one spec question we could not answer from Shifter's pages. The legacy doc states the 50-thread ceiling and stops there: it never says whether request 51 queues, gets refused, returns a status code, or just slows the other 50 down. The gateway error table next door is specific about other failures (502 Bad Gateway when a strict-true filter matches nothing, 509 Bandwidth Limit Exceeded when plan bandwidth is exhausted with Extra Traffic disabled, and a bare "Connection refused" if you point at the retired port host), and it carries no entry for exceeding a port's thread cap. If you hold a port plan and you run anywhere near 50 threads, that is a question for Shifter support in writing, next to the SLA and trial questions further down. On the traffic model the question dissolves, because Shifter's docs FAQ answers "How many concurrent connections can I open?" with "Unlimited on every plan. The new traffic model retired per-port thread caps."

Threads are not throughput, and the conversion is two multiplications. A thread count tells you how many requests are in flight, not how many finish. Convert it:

requests/sec   = threads / seconds per request
bytes/hour     = requests/sec x mean on-wire bytes x 3600

Put the legacy 10-port plan through that. 500 threads at a round 1.5 seconds per request is 333 requests a second, and at a 250 KB mean response that is about 286 GB an hour on the wire. Two numbers fall out of it. On Shifter's current Full Geo pool at its best published rate of $0.75/GB, a plan saturated like that costs about $215 an hour, and it would eat the entire 10 TB Max tier, the largest traffic plan Shifter publishes at $7,499, in roughly 35 hours. That is the real consequence of the unit change for anyone who was actually using their ports rather than owning them. On SparkProxy's side the same 500 threads is Boost at $240 a month with no byte meter, and the ceiling moves to the published 1 Gbps port speed, which is about 419 GB an hour. Our 286 GB an hour sits at roughly 68% of that, so a flat plan is not infinite either; its limit is just a pipe instead of a wallet. Swap your own measured seconds-per-request and mean response size into those two lines before you trust either figure.

The traffic model collapses the port list into one endpoint. Shifter documents host p.shifter.io, port 443, HTTP(S) and SOCKS5, and says: "Use the same host and port regardless of location, protocol, or session mode. Targeting and session options are encoded in the username, not in a different endpoint." Eight named regional entry points exist (fra, ams, lon, nyc, tor, sgp, blr and syd, all on port 443), with no automatic failover if you pin a regional host.

Targeting moves into dash-delimited username flags, per request: country as an ISO 3166-1 alpha-2 code, plus region, city and asn on the Full Geo pool. One flag is worth knowing before you build anything on top of it. By default a filter that matches nothing falls back silently to a broader pool, so you can believe you're in Los Angeles on Comcast and quietly be somewhere else. Shifter's fix is explicit: "Add strict-true to opt out of the fallback and receive HTTP 502 instead." Set it in any job where a wrong location corrupts the dataset.

Rotation is now two-mode. Per-request is the default: "By default, every request rotates to a new IP." Sticky sessions come from a sid- flag, with an optional ttl- whose documented default is 120 seconds and documented minimum is 1. Shifter publishes no maximum TTL, and its marketing FAQ separately claims sticky sessions hold for "1 to 30 minutes," which the docs do not support. Confirm the ceiling with support rather than from either page. Sessions also end early if the upstream residential IP drops, which is normal for residential and worth building retries around. Our write-ups on concurrent connections in proxies and sticky session proxies cover how both behave under load.

One more inconsistency: Shifter's residential pricing page still carries port-era marketing copy, describing rotation and targeting as configured "per port" and listing SOCKS4 support. The docs for the same product say there are no ports and that protocols are "HTTP(S) and SOCKS5." Treat SOCKS4 and any per-port control as unconfirmed. SparkProxy publishes HTTP, HTTPS and SOCKS5 with IP whitelist or user:pass auth.

Shifter splits residential into three pools, and the pool decides both the targeting you get and the rate you pay. Headline rates on its pricing page on 9 October 2026: Full Geo "205M+ IPs, Country, state, city & ASN, from $0.75/GB"; Country Geo "31M+ IPs, Country only, from $0.48/GB"; Non-Geo "31M+ IPs, None (worldwide mix), from $0.10/GB". Those IP counts are Shifter's own claims with no published measurement method and no split between live-at-once and cumulative addresses, which is the usual caveat on any proxy pool size claim.

Full Geo ladder, promotional prices from the structured data embedded in Shifter's own pricing page, with the per-GB rate as our arithmetic:

The cheaper pools, same source, same date:

Those two columns measure different things, which is why the Country Geo row looks odd at first glance: the biggest cheque is not the cheapest unit rate. Max is the most expensive plan and still $0.48/GB, while the actual rate floor is a tier below it. Two things fall out of the arithmetic. The advertised "from $0.48/GB" on Country Geo is beaten by its own Scale tier at $749 for 1,600 GB, which works out at $0.47. And the famous $0.10/GB is reachable on exactly one plan, Non-Geo Growth at $2,499 a month for 25 TB, a pool with no geo-targeting at all. Shifter's bandwidth-and-billing docs are candid that tier size buys rate, not quality: "higher tiers get cheaper per-GB rates, not better IPs."

Now the discrepancy to know about before quoting any Shifter price. Its docs publish a residential table uniformly higher than its live pricing page, tier for tier under the same twelve names: Spark 5 GB at $25, Launch 10 GB at $50, Boost 20 GB at $80, Surge 32 GB at $128, Starter 50 GB at $175 ($3.50/GB), Basic 100 GB at $300, Business 200 GB at $500, Growth 400 GB at $800, up to Max 10 TB at $10,000 ($1.00/GB). Those are exactly the struck-through "was" prices on the live cards, which are flagged 71%, 67%, 70% and 63% OFF. So the docs are list price and the live page is a promotion, and the docs themselves link out with "See live pricing." No expiry is published for the discount, so any number you plan around, ours included, needs re-checking on the day you buy. Our breakdown of residential proxy pricing per GB explains why promo-anchored per-GB rates move around so much.

This is the part of a metered product that spreadsheets miss. Shifter documents exactly what the meter counts:

• "Every byte sent or received through the gateway counts, including HTTP headers"
• "HTTPS tunnels count full encrypted traffic"
• "Failed requests (4xx, 5xx) count if bytes were transferred before the error"
• "The initial CONNECT handshake is not counted."

So a block page costs you money. A 403 with a body costs you money. A retry storm on a target that started rate-limiting at 2 a.m. costs you money while returning nothing. That isn't unique to Shifter, it's how per-GB billing works everywhere, but the consequences here are documented unusually plainly.

Overage is automatic and not optional. "Overage is billed at the same per-GB rate as your plan tier (no markup)," which is fair, and "Wallet deductions run every 5 minutes against the bandwidth used since the last deduction," which is fast. Then the line that decides whether this product suits your finance process: "There is no way to disable Extra Traffic, it is always on when wallet funds exist."

What you see when both the allocation and the wallet are empty is worth separating out, because Shifter's two pages don't line up and we are not going to merge them for tidiness. Its bandwidth-and-billing page describes the state plainly and names no status code: "If your wallet balance hits zero and your plan allocation is exhausted, requests return an error until you top up the wallet or the next billing cycle starts." Its gateway docs do print a code, 509 Bandwidth Limit Exceeded, but file it against a different cause: "Plan bandwidth exhausted with Extra Traffic disabled," which is the state the billing page says you cannot be in. So the operational fact is confirmed by Shifter twice over, that requests stop until you top up or the cycle rolls, while the code you would actually get is unconfirmed. Treat the error as "something non-2xx that is not your target's fault" and alert on it rather than pattern-matching one number.

Two operating models follow. On Shifter you either keep the wallet funded and accept a variable bill, or let it run dry and accept a hard stop mid-crawl. On SparkProxy bandwidth is unlimited on every plan at 1 Gbps port speed, so retries, block pages and oversized rendered DOMs cost you time and nothing else. Whether that's worth paying for depends on your volume, which is the point of the next two sections. We've argued both sides of it in are unlimited bandwidth proxies worth it.

Four numbers decide this, and all four come from your own traffic rather than from either vendor's page.

1. On-wire bytes per request. Not page weight. Bytes in both directions, including headers and TLS payload, because that's what Shifter meters. Sample your real URLs, not a homepage:

import os, statistics, requests

PROXY = "http://{}:{}@gateway.sparkproxy.io:11000".format(
    os.environ["SPARK_USER"], os.environ["SPARK_PASS"])

urls = [l.strip() for l in open("sample_urls.txt") if l.strip()]
sizes = []

for url in urls:
    r = requests.get(url, proxies={"http": PROXY, "https": PROXY}, timeout=30)
    resp_headers = sum(len(k) + len(v) + 4 for k, v in r.headers.items())
    sizes.append(len(r.content) + resp_headers)

sizes.sort()
print("n=%d  mean=%.1f KB  p95=%.1f KB" % (
    len(sizes), statistics.mean(sizes) / 1024, sizes[int(len(sizes) * 0.95)] / 1024))

That measures the response side. Add roughly 1 to 2 KB per request for your own request headers and TLS overhead, then multiply by a retry factor from your logs. If you don't know your retry factor, 1.25 is conservative for a well-behaved target and badly optimistic for a hard one.

2. Requests per month. Straight from your scheduler, counting the retries once.

3. Peak concurrency. Requests in flight at the busiest minute, which is what SparkProxy bills. If your runner is a fixed worker pool, it's the pool size. If it's async with a semaphore, it's the semaphore value. If it's neither, log in-flight count once a second for a day and take the p99.

4. Seconds per request. Wall-clock time from dispatch to last byte, measured through a proxy rather than from your laptop. This is the one that turns a thread count into throughput, and it swings hardest: a plain fetch of a static page and a rendered listing page with a scroll trigger can differ by a factor of ten. Take the median from the same sample run you used for bytes.

Then price it. This is the whole comparison in under forty lines:

GB = 1024 ** 3

# (included GB, USD/month) Shifter Full Geo promo ladder, shifter.io, 2026-10-09
FULL_GEO = [(5, 10), (10, 20), (20, 30), (32, 40), (50, 50), (100, 100),
            (200, 149), (400, 299), (800, 599), (2000, 1499),
            (6000, 4499), (10000, 7499)]

# (threads, USD/month) SparkProxy plans, sparkproxy.io, 2026-10-09
SPARK = [(100, 75), (250, 140), (500, 240), (1000, 440)]

def monthly_gb(reqs, mean_kb, overhead_kb=2.0, retry_factor=1.25):
    return reqs * (mean_kb + overhead_kb) * retry_factor * 1024 / GB

def shifter(gb):
    for quota, price in FULL_GEO:
        if gb <= quota:
            return price, "%d GB tier" % quota
    quota, price = FULL_GEO[-1]
    rate = price / quota                      # overage at the plan's own rate
    return price + (gb - quota) * rate, "Max tier plus overage"

def sparkproxy(peak_threads):
    for threads, price in SPARK:
        if peak_threads <= threads:
            return price, "%d threads" % threads
    return None, "above published plans, request a quote"

def throughput(peak_threads, secs_per_request, mean_kb):
    rps = peak_threads / secs_per_request
    return rps, rps * mean_kb * 1024 * 3600 / GB   # requests/sec, GB/hour

PORT_CEILING_GB_H = 1e9 / 8 * 3600 / GB           # 1 Gbps, sparkproxy.io

reqs, mean_kb, peak, secs = 1_200_000, 250.0, 150, 1.5
gb = monthly_gb(reqs, mean_kb)
rps, gb_h = throughput(peak, secs, mean_kb)
print("estimated %.0f GB/month" % gb)
print("peak %.0f req/s, %.0f GB/hour (%.0f%% of a 1 Gbps port)" % (
    rps, gb_h, 100 * gb_h / PORT_CEILING_GB_H))
print("Shifter Full Geo: $%.0f (%s)" % shifter(gb))
print("SparkProxy:       $%s (%s)" % sparkproxy(peak))

Run it with your four numbers before you read anyone's verdict, including ours. If you want a more careful treatment of the forecasting step, we wrote one up in how to forecast proxy bandwidth needs, and the general shape of the trade-off is covered in per-IP vs per-GB proxy pricing.

Three real shapes of job, run through the calculator above. The port-era question was how many ports each one needed, so the throughput column answers that first, at a round 1.5 seconds per request; substitute your own median and the numbers move. Then the same job is priced on the unit actually on sale. Shifter column is Full Geo promo pricing as of 9 October 2026. SparkProxy column is the smallest plan that covers peak concurrency.

These rows set Shifter residential against SparkProxy datacenter, because that is what each vendor publishes. The price only applies where datacenter IPs work on your target, and the next section says plainly when they don't.

The port column is a sizing figure, not a shopping list: Shifter's own doc says port plans came in "typically 10-minimum tiers," so every one of these jobs would have bought ten ports and left most of them idle, which is exactly the inefficiency the traffic model was built to remove. The throughput column is the part the port model used to make obvious and the meter hides. Row three moves a quarter of a terabyte an hour at peak, about 60% of SparkProxy's published 1 Gbps ceiling and, at $0.75/GB, about $190 an hour on Shifter while it runs. Row one moves 8 GB an hour, which means its entire monthly allocation clears in about an hour of wall-clock time: peak concurrency is simply not the binding constraint on a job that size.

The first row is the one most comparisons bury. At under 9 GB a month, Shifter costs $20 and SparkProxy's unlimited bandwidth is bandwidth nobody uses. There is no honest way to argue a $75 plan into that job.

The second row is the break-even made concrete. At Shifter's best Full Geo rate of $0.75/GB, $75 of traffic is 100 GB; at the tier you'd actually sit on at that spend it's closer to 75 GB. Either way, roughly 100 GB a month is where the lines cross for Full Geo. Above it, SparkProxy's price stops moving and Shifter's keeps climbing. Note the same Growth tier is $800 at Shifter's published list price, so the current promotion is doing a lot of work in Shifter's favour in that row.

The third row is really an argument for not using raw proxies at all. 439 GB of rendered pages is the expensive way to collect 200,000 records on either vendor, and both sell a scraping API instead. Which brings us to the one axis where the credit math runs clearly against SparkProxy.

Stated plainly, because a comparison that pretends the products are interchangeable is useless: these are not the same IP class. SparkProxy publishes a rotating datacenter pool: 1M+ addresses, 80+ countries of coverage, and a USA pool of 50,000+ premium datacenter IPs, plus the Scraping API. Shifter publishes residential across three pools, static ISP, a Web Scraping API and a SERP API. If your target blocks datacenter ASNs outright, the price comparison above is academic and you want residential. We keep a neutral explainer on that distinction in residential vs datacenter proxies.

Three capability gaps run in Shifter's favour, on published specs:

Targeting depth. Full Geo advertises country, region, city and ASN selectors across a claimed 205M+ IPs in 195+ countries, set per request, with strict-true to refuse a broadened fallback. SparkProxy publishes 1M+ IPs and 80+ countries with no published city or ASN selector. For "give me a Comcast address in Los Angeles or fail the request," Shifter wins on what each vendor publishes. See ASN-targeted proxies for why that selector matters on some targets.

Static ISP identity. Shifter's ISP proxies hold "Same city and ISP (ASN) for the whole billing period" with unlimited bandwidth, priced from $252 for 200 IPs ($1.26 each) up to $10 for 4 IPs ($2.50 each), across claimed coverage of 120 countries, 1,800+ cities and 900+ ISPs. One mismatch worth knowing before you budget: $1.26 per IP at 200 IPs is the cheapest rate we could derive from the eight monthly tiers published in that page's structured data, but Shifter's own site navigation and the page's meta description both advertise ISP proxies "from $1.00/IP". No published monthly tier reaches $1.00, so that rate presumably attaches to a longer commitment or a volume Shifter doesn't list. Ask which, rather than planning around either figure. Shifter notes the address behind a proxy "can refresh over time, exactly like a home broadband connection," so "static" means stable identity rather than a frozen address. SparkProxy's published product is rotating, with no equivalent SKU. For long-lived logins and account work that's a clear win for Shifter, and our guide to ISP proxies for multi-account management explains the use case.

Parsed SERP output. Shifter sells a SERP API from $44 for 5,000 calls, billed per successful call, returning structured JSON with city-level targeting across Google, Bing and Yandex, plus a documented Amazon endpoint. Per-call rates run $0.0088 at Starter down to $0.0045 at Enterprise ($449 for 100,000 calls). SparkProxy's Scraping API converts content (html, md, mdx, json, screenshot, pdf) but doesn't publish parsed SERP objects, so you'd build and maintain the parser yourself. If ranked results with positions already extracted are the deliverable, Shifter saves you that work. See proxies for SERP scraping at scale for the volume version of the problem.

One gap runs the other way, and it should be stated without drama: we could not locate any published statement from Shifter about how it obtains its residential IPs. We checked sitemap.xml, sitemap-static-en.xml and sitemap-docs.xml, the terms and conditions, the privacy policy, the about page and the product docs. No sourcing, consent, opt-in or peer-network page turned up, and the only compliance signals are three unlinked footer badges repeated site-wide: "SOC 2 Type II", "HIPAA Compliant", "GDPR Ready", with no report, audit date or auditor attached. That's an absence of published information rather than evidence of anything, and the right move is to ask Shifter directly before a procurement review. Our background piece on where residential proxy IPs come from lists the questions worth putting to any residential vendor.

Both vendors sell a managed scraping layer billed in credits. The rules agree in most of the places buyers assume they differ, and diverge hard in one.

Read the second row carefully, because it's the biggest number in this post for anyone doing render-heavy work. For a crawl that must execute JavaScript on every page, Shifter bills one fifth of the credits SparkProxy does. That is the whole of the gap, and it is enough: at Shifter's Growth tier, $134 covers 1,000,000 rendered pages. The failure and retry rows look like a second Shifter advantage and aren't one, because both vendors publish the same behaviour. Shifter doesn't charge for failures or retries, and SparkProxy's docs say credits are deducted up front and refunded on failure, with up to three automatic server-side retries you don't pay for either. One row of difference, five times over, is the honest version. Two notes on the first row as well: those credit figures are the default rotating pool, and the same docs table prices the premium pool at 10 credits without JS and 25 with, so the 1-credit plain fetch is a default-pool rate rather than a floor across every option. We can't put a dollar figure next to that for SparkProxy, because SparkProxy publishes credit costs but not a paid credit price, and inventing one to win a row would make the rest of this page worth less. Ask sales for the rate, then do the division yourself. The general mechanics are covered in scraping API credit pricing explained.

Shifter's tier-gated flags matter too: its error table lists a 403 for "Plan does not allow this feature" with the example "premium_proxy on Starter," so some capabilities only appear higher up the ladder.

What SparkProxy does give you is a cheap path for everything that doesn't need a browser. Plain fetches are 1 credit and roughly 3x faster:

curl -s "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://www.sparkproxy.io/","render_js":false,"format":"md"}'

And batch mode, which only works with render_js=false, bills 1 credit for the entire batch:

curl -s -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARK_API_KEY" \
  --data-urlencode "url=https://www.sparkproxy.io/,https://www.sparkproxy.io/docs/scraping-api/" \
  --data-urlencode "render_js=false"

If you want the billing envelope back rather than just the content, json_response=true is the only parameter that does it, and the body comes back base64-encoded. format=json converts the page content, which is a different thing entirely:

curl -s "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://www.sparkproxy.io/","render_js":false,"json_response":true}' \
| python -c "import sys, json, base64; d = json.load(sys.stdin); \
print(d['job_id'], d['status_code'], d['duration_ms'], 'credits:', d['credits_used']); \
open('page.html','wb').write(base64.b64decode(d['body']))"

Log credits_used from that envelope on every call for a week and you'll have a real cost-per-record figure instead of a plan brochure.

Four of those need a sentence each.

The trial contradiction is not a gotcha, it's a live conflict between two Shifter pages, and neither states a trial length or traffic allowance. The marketing FAQ says only that "Trial length depends on your account." Confirm at signup rather than planning around either answer. Our comparison of proxy free trials and refund policies covers how to evaluate a window this short.

Three days plus a 50% usage condition is tight. It's roughly enough to run one crawl and read the logs, which means your evaluation plan has to be written before you pay, not after.

The X prohibition is specific and easy to miss, and the blocked-destination list is broader than most vendors publish. If your targets include banking portals, government services or anything needing SMTP, read that list before you read the prices. Publishing the list at all is more transparency than many vendors offer, even though the effect is restrictive. Proxy acceptable use policies explained walks through how these clauses usually read.

On reliability figures, Shifter's own pages disagree. Its ISP structured data says "Uptime: 99.99%", a pricing bullet says "99.9% uptime SLA", the residential pricing FAQ attaches a 99.9% SLA to Enterprise tiers only, and the residential service page mentions 99.5%. We're not publishing one number as Shifter's because Shifter doesn't. Ask which SLA attaches to the plan you'd buy, and get it in writing.

Shifter is the better buy, on published figures, for all of these:

• Small or occasional jobs. Spark at $10 for 5 GB and Launch at $20 for 10 GB price a small monitoring job at a fraction of a $75 plan. Unlimited bandwidth only starts paying for itself around 100 GB a month, and below that it's a feature you're funding and not using.
• Bursty work that idles. A quarterly research pull leaves a flat plan paying for eleven months of nothing. A meter charges for the bytes and stops.
• City and ASN precision at scale. Full Geo's region, city and ASN selectors plus strict-true are finer control than SparkProxy publishes, and the claimed 195+ country coverage is broader than 80+.
• Long-lived logins and account identity. ISP proxies holding the same city and ASN for a billing period, with unlimited bandwidth, from $1.26 per IP at 200 IPs. SparkProxy has no equivalent published SKU.
• Render-heavy API crawling. 1 credit per rendered page against 5, on the default pool. Both vendors refund or waive failures and automatic retries, so the rendered-page rate is the entire gap and it's a factor of five.
• Sessions that aren't five minutes long. A sid with a ttl in seconds fits a 30-second checkout or a 10-minute multi-step form better than a fixed 5-minute rotation interval. See proxy rotation interval for why that granularity matters.
• Terabyte-scale fetching where location is irrelevant. Non-Geo Growth at $2,499 for 25 TB is $0.10/GB, which is genuinely hard to beat on unit cost for global crawling with no geo requirement.
• Capacity planning before you sign. Shifter prints a numeric scraping-API concurrency cap against each tier on the price card: 20, 50, 100, 500. You can size a worker pool off the pricing page and know which tier you need before you pay. SparkProxy's API also caps concurrency and also returns a 429, carrying limit, active and retry_after_seconds so your client can back off correctly, but you read your number off a response at runtime rather than off a tier. Both are designable; only one is published in advance.

SparkProxy is the better buy when the meter is the problem:

• Sustained volume above roughly 100 GB a month. Past the break-even, Shifter's bill keeps climbing and SparkProxy's doesn't. At 360 GB the gap in our second workload was $299 against $140, and $800 against $140 at Shifter's list price.
• Transfer you can't forecast. Rendered pages, image-heavy targets, PDFs, anything where response size swings by an order of magnitude. A flat plan is indifferent to the swing; a meter is priced by it.
• Retry-heavy or newly hostile targets. When a target starts returning block pages, a meter charges you for every one of them. Shifter documents this directly: failed requests count if bytes moved. Our notes on reducing proxy bandwidth costs apply to any metered plan.
• Work bounded by parallelism, not by bytes. When the binding limit is in-flight request count rather than transfer, buying threads directly is the cleaner unit.
• A fixed invoice. No wallet to keep funded, no deductions every five minutes, and no crawl stopping at 3 a.m. because the balance ran out. For some teams that predictability is worth more than the per-GB arithmetic.
• Targets that accept datacenter IPs. Where datacenter ASNs still work, you're paying residential rates for nothing. Plenty of APIs, price feeds and public datasets don't care.

Two days of measurement beats a month of reading comparison pages, including this one.

Day one. Take the SparkProxy trial, which runs 24 hours at 250 threads with no card, and run the byte-measuring script above against 200 of your real target URLs, not a homepage. Record the mean and p95 response size, your retry rate, the median seconds per request and the p99 in-flight request count from your own scheduler. Those are the four numbers the calculator needs, and the last two are what turn a thread count into a throughput figure you can hold a vendor to.

Day two. Run the calculator. Then put four questions to Shifter support in writing, because its own pages don't answer them consistently: does a free trial exist for your account and what does it include; when does the current promotional pricing expire; does unused GB roll over month to month; and which uptime SLA attaches to the plan you'd buy. If you hold a grandfathered port plan, add two more: what happens to it if you ever change tier, and what a port actually does with request 51 when all 50 threads are busy, since no Shifter page we found says.

Decide on the numbers. If you land under about 100 GB a month of Full Geo traffic, or you need city and ASN selectors, or you need static ISP identity, Shifter is the better purchase and we'd rather say so than lose your trust on the next comparison. If you're running sustained volume, unpredictable response sizes, or concurrency-bound crawling on targets that accept datacenter IPs, the flat plan wins and it isn't close. Our general method for this is written up in how to run a proxy provider trial.