How many proxies per task: the arithmetic behind the number people repeat

2026-10-20 · Bazyl

After this post you can work out your own proxies-per-task number instead of repeating one from a group chat. The thing most people get wrong is the unit. They count proxies as things you buy, and on this pool a proxy is a string. Strings are free. Gigabytes cost.

A proxy here is a string, not a purchase

Your account has one credential pair: a user and a password. Every targeting token rides the username, and the password never changes. Add a session token and you have a session; change the eight characters and you have another. Two strings, one pair, nothing bought:

us-residential2.basilproxies.com:4243:USER-country-us-session-k4mz61pq-lifetime-60:PASS
us-residential2.basilproxies.com:4243:USER-country-us-session-p7w3nq2d-lifetime-60:PASS

The dashboard's generator writes up to 100,000 lines per generation, each with its own session id. The account API's /proxies builds up to 1,000 at a call from the credentials you already hold, and creates nothing and spends nothing doing it. So "how many proxies" is a question about how many identities a task needs, not about a bill.

One sticky session per checkout task

A checkout remembers where you connected from. Two tasks on one session id are one person to the store, and a task whose IP changes mid-checkout is a different person from the one who added the item. So the arithmetic for sticky strings is the shortest in this post: tasks equals strings.

Fifty tasks, fifty strings, each on port 4243 with its own session id and a lifetime sized to the task. For a checkout that takes a few minutes, -lifetime-60 leaves room to spare; the token takes any value from 1 to 1440. This prints them:

#!/usr/bin/env python3
# gen.py: one sticky string per task, each with its own 8-character session id.
# python3 gen.py 50 us 60   ->  50 strings, US exit, held for 60 minutes
import secrets, string, sys

n, country, lifetime = int(sys.argv[1]), sys.argv[2], int(sys.argv[3])
assert 1 <= lifetime <= 1440, "lifetime is 1 to 1440 minutes"
alphabet = string.ascii_lowercase + string.digits
ids = set()
while len(ids) < n:
    ids.add("".join(secrets.choice(alphabet) for _ in range(8)))
for sid in ids:
    print(f"us-residential2.basilproxies.com:4243:USER-country-{country}-session-{sid}-lifetime-{lifetime}:PASS")

Run python3 gen.py 50 us 60 and paste the output into the bot. Nothing has been spent. Which task gets which port is the subject of the sticky versus rotating post.

Monitors rotate on 4242 and need no count at all

A monitor wants a fresh look at a product page on every request, and port 4242 gives a new IP on every request from one string. There is nothing to count. One rotating string serves every monitor you run, and the only number it adds to your bill is the bytes it pulls.

us-residential2.basilproxies.com:4242:USER-country-us:PASS

That is why "proxies per task" only ever counts checkout tasks. The monitors were never in the number.

Strings are free. Gigabytes are the bill.

Pay as you go, in US dollars, as of September 2026: 1 GB is $4.20 a gigabyte, 5 to 14 GB is $3.60, and 100 to 199 GB is $1.20.

The whole ladder, subscriptions included, is on the pricing page. Notice what isn't on it: a price per proxy. The fifty strings above cost nothing until a request moves through one, and then the cost is bytes, at your tier.

How many bytes a checkout takes depends on the site and on the bot, and we don't publish a gigabytes-per-checkout number. It would be our bot on our day, and you'd size a purchase on it.

Fill in the one unknown from your own run

The arithmetic has one unknown, and only your own drop can fill it in. Strings are the number of checkout tasks plus one for the monitors. Cost is gigabytes used times your per-gigabyte price. Gigabytes used is the blank.

So buy small, run one drop, and open the statistics page the morning after. It shows bandwidth and requests from 24 hours to 30 days, a success rate, latency and a per-domain table of your top targets. Take the bytes on the store's domain, divide by the tasks you ran, and you have a per-task figure that is yours. Size the next purchase from that, and the tier it lands in tells you the price.

Pay as you go never expires, so the small first purchase isn't wasted if the drop is cancelled. It waits.

What we don't publish, and where the count is different

We don't publish gigabytes per checkout, and we don't promise an outcome on any store. We answer for the proxy being live and reachable from the country you asked for; what the site does with the request is the site's.

The count is only different on ISP proxies, where the unit is an IP: one user per IP, dedicated, from 25 IPs a month, in Europe and Australia. There the question "how many" has a bill attached, and the answer is still the number of tasks that need an address of their own. On residential it never was.

Start from the monitor and checkout strings on the sneakers and retail page, and let the first drop set the second purchase.

Common questions

How many proxies do I need per task?
One sticky string per checkout task, each with its own session id, and one rotating string for all the monitors. On the Basil residential pool a proxy is a string built from one credential pair, so the count costs nothing. The gigabytes the tasks use are what you pay for.
Do proxies cost money on the residential pool?
Strings don't. One credential pair makes as many identities as there are session ids, and the dashboard generates up to 100,000 lines at a time. Gigabytes cost, priced per GB by the size of the purchase, from $4.20 at 1 GB down to $0.96 at 1,000 GB and up, as of September 2026.
How many gigabytes does a checkout use?
We don't publish a number, because it depends on the site and the bot. Buy small, run one drop, and read the per-domain table on the statistics page. Divide the bytes on the store's domain by the tasks you ran and you have your own figure.
Do monitors need their own proxies?
They need one string on port 4242, which hands out a new IP on every request. A monitor polling a product page never leans on one address, so there is nothing to count. Keep the sticky strings for checkout tasks.