Budgeting proxies and devices per account as your fleet grows

Most people running more than a handful of accounts track one number: total monthly spend. That number tells you almost nothing useful. What tells you whether your operation is sustainable is multi account cost per account, and it changes shape as you scale in ways that surprise people who haven’t run a large fleet before.

I run proxy infrastructure and cloud phones out of Singapore for account fleets, and the question I get asked most isn’t “what proxy should I use.” It’s “why did my cost per account go up when I added more accounts.” The answer is almost always the same: something in the stack was priced for 20 accounts and nobody re-checked it at 200.

Why cost per account, not total spend

Total spend is a vanity number. It goes up whether you’re being efficient or not. Cost per account forces you to ask whether each unit of your fleet is pulling its weight, and it’s the number that actually predicts whether scaling from 50 to 500 accounts makes sense or breaks your economics.

The reason this matters specifically for account fleets is that the cost structure isn’t linear. A single account might need a dedicated residential IP, a stable device fingerprint, and weeks of warm-up before it’s useful. Add a second account and you can sometimes share infrastructure. Add the two hundredth account and you’re often forced back into one-to-one allocation because platforms correlate accounts that share too much. Cost per account can go down, then flatten, then creep back up depending on how aggressively you’re isolating.

What actually makes up the cost of one account

Break it into four buckets: the proxy, the device or browser profile, the warm-up time, and the labor to manage it. People usually only budget for the first one.

The proxy is the most visible line item. Residential and mobile IPs cost more than datacenter IPs because they route through real ISP or carrier infrastructure and carry a real device’s reputation with them. That reputation is the entire point. A datacenter IP is trivially flagged by ASN lookups that most platforms run as a first-pass filter. A residential or mobile IP looks, at the network level, like a normal person’s home or phone connection, which is why it’s priced higher and why it’s the right tool for anything that needs to survive scrutiny.

The device or browser profile is the second cost, and it’s the one people underbudget. An antidetect browser profile needs to present a consistent, internally coherent fingerprint: canvas rendering, WebGL output, font list, timezone, screen resolution, hardware concurrency, all of it lining up with each other and with the IP’s geography. A cloud phone goes further and gives you an actual mobile OS environment, which matters for platforms that fingerprint at the OS and sensor level, not just the browser level. Neither is free to run at scale, because each profile or phone instance needs to stay assigned to the same account consistently. Rotating a fingerprint under an account that’s already established is often more damaging than a slightly worse fingerprint that never changes.

Warm-up is the cost people forget to count at all. A brand new account behind a brand new IP and a brand new device profile has no history. Platforms weight new, unverified signals heavily. The account needs a period of low-intensity, human-paced activity before it can be trusted with the volume of action you actually want from it. That warm-up period isn’t idle time, it’s infrastructure you’re paying for that isn’t producing yet.

Labor is the fourth bucket, and it scales worse than people expect. Someone has to notice when a proxy goes stale, when a session gets logged out, when a device profile needs to be retired because the account tied to it got flagged. At 10 accounts this is a spreadsheet. At 500 it’s a job.

Proxy tiers don’t scale the same way

A mistake I see constantly: buying one large pool of rotating residential proxies and assuming it covers the whole fleet. Rotating pools are fine for anything session-independent, like one-off scraping or checking prices. They’re a liability for account management, because most platforms expect an account to log in from a consistent, or at least plausibly consistent, location and IP over time. If the IP jumps between cities on every session, that inconsistency is itself a signal, sometimes a stronger one than a slightly worse-reputation IP that stays put.

Sticky sessions cost more per account because you’re paying to hold an IP allocation for that account specifically instead of sharing it across your whole pool. Mobile proxies carry their own cost logic on top of that: carrier-grade NAT means your IP is shared with other real mobile users on the same tower, which is actually a feature for blending in, but it also means mobile IP inventory is more constrained and priced accordingly.

The budgeting question isn’t “which proxy type is cheapest.” It’s “which proxy type matches what this account needs to look like,” and then costing the fleet against that requirement rather than against the cheapest available pool.

Devices: cloud phones versus antidetect browser profiles

Cloud phones and antidetect browser profiles solve overlapping but different problems, and conflating them is a common budgeting error. A browser profile is enough when the platform’s detection surface is mostly browser-side: fingerprinting JS, cookies, storage, headers. A cloud phone is closer to necessary when the platform expects a real mobile app environment, checks device attestation, or behaves differently across app and web in ways that a spoofed browser fingerprint can’t replicate.

Cloud phones cost more per unit because you’re running an actual isolated OS instance, not a lightweight browser container. The tradeoff is that for app-first platforms, a cloud phone gives you signals a browser simply can’t fake convincingly: real sensor data, real app install history, a real device ID that isn’t obviously synthetic. Budget for cloud phones where the platform’s own architecture forces the question, not as a default for every account.

Where fleets bleed money without anyone noticing

Three leaks show up again and again once a fleet crosses a few hundred accounts.

Idle allocation is the biggest one. Proxies and device slots get provisioned for accounts that got banned, paused, or abandoned, and nobody deprovisions them. You’re paying full price for infrastructure attached to nothing.

Over-isolation is the second. Not every account needs its own dedicated everything. Accounts with low risk tolerance for correlation, or accounts on platforms with weaker cross-account detection, can sometimes share infrastructure tiers safely. Treating every account like it needs the maximum isolation tier inflates cost per account without a matching reduction in risk.

Under-isolation is the opposite failure and it’s more expensive in the long run, because it shows up as bans, not as a line item. Accounts that share an IP, a device fingerprint, or even login timing patterns too closely can get correlated and taken down together. When that happens you’re not just losing the flagged account, you’re losing everything warmed up alongside it. That’s why cost per account has to include an estimate of expected account lifespan, not just monthly infrastructure spend. A cheaper stack that produces accounts with a shorter average lifespan can easily cost more per surviving account than a more expensive one that doesn’t.

A simple way to model it

Take your monthly proxy spend, device or cloud phone spend, and rough labor hours, add them up, and divide by the number of accounts currently active and useful, not the number you’ve ever created. Then track that number monthly. If it’s climbing as your fleet grows, something is either under-shared that could be pooled, or under-isolated in a way that’s shortening account lifespan and forcing you to replace accounts faster than you’d like. If it’s flat or falling as you scale, your infrastructure tiering is matched to what each account actually needs.

We build and test this stack ourselves against real Singapore proxy and cloud-phone infrastructure, and we cover the tradeoffs in detail on the channel. If you want to see how we actually structure proxy tiers, device profiles, and warm-up schedules for growing fleets, start at Multi Account Ops.

Get new guides and videos first — join the Telegram channel.