Short answer
The simultaneous connection limit is the number of devices that can be signed in to the provider and actively connected to a server at the same time, and the working limit is the number of devices that actually run at usable speed on the same server. A plan that advertises 10 simultaneous connections usually delivers 4 to 6 at usable speed on a single server under typical household load, and the working limit drops to 2 to 4 when the household streams 4K video, games online, or runs large downloads in parallel. The reason is that the server's bandwidth and CPU are shared across every active connection, the household's own upstream is shared across every device, and protocol overhead adds another 5% to 20% on top. The cheapest way to find the real working limit on a specific plan is to run a household stress test during the 30 to 45 day money-back window, comparing 2, 4, 6, 8, and 10 device counts against a per-device speed floor, and to switch providers inside the window if the working limit is too low.
What "simultaneous" actually counts
The word simultaneous on a VPN pricing page is the most consistently misread word in the consumer subscription market, and the misreading shows up in three different ways. First, simultaneous means at the same time, not over the lifetime of the plan. A household that rotates 15 devices through the plan over a year still has only the active devices counted at any given moment. Second, simultaneous means signed in, not installed. The plan can be installed on 30 devices; only the ones that are currently signed in and connected to a server count against the cap. Third, simultaneous means per account, not per plan length. A monthly plan and a multi-year plan on the same account share the same device cap, regardless of how much was prepaid.
The clarifications below are worth stating explicitly because they shape the buyer's mental model of the cap.
- Active tunnel vs installed app: the cap counts devices that are currently signed in and connected to a server, not devices that have the app installed but are offline. You can install the app on 30 devices; only the ones actively tunneling count against the cap.
- Per account, not per device class: a phone, a laptop, a smart TV, a streaming stick, and a router each consume one slot regardless of class. The provider does not differentiate between a high-traffic desktop and a low-traffic smart bulb.
- One slot per protocol instance: WireGuard, OpenVPN, and IKEv2 each consume one slot per device. Running two protocols on the same device at the same time counts as two slots, although this configuration is rare.
- Drop-oldest or reject-new: when the cap is reached, providers either reject the new sign-in or drop the oldest active connection, depending on the provider's enforcement policy. The behavior matters because reject-new forces a manual workaround, while drop-oldest can silently cut a device.
- Account-wide, not per server: the cap is enforced across the entire account, not per server. A device on a US server and a device on a UK server still share the same account cap.
These clarifications are not hidden, but they are usually buried in the FAQ or the support knowledge base rather than on the pricing page. The pricing page says "10 devices," and the buyer assumes 10 devices for the life of the subscription, which is rarely what the plan actually delivers.
Why the working limit is lower than the marketed limit
The marketed limit is the cap the provider's account system enforces. The working limit is the cap the network and the server can sustain at usable speed, and the gap between the two is what most buyers underestimate. The marketed limit is the cheap part of the cap, because enforcing a number in an account database costs the provider almost nothing. The working limit is the expensive part of the cap, because every device that joins a server consumes bandwidth, server CPU, and connection slots.
Four constraints stack on top of the marketed limit, and each one shaves the working limit further.
- Server bandwidth: a single VPN server has a finite amount of upstream and downstream bandwidth, and that bandwidth is shared across every active connection. Doubling the devices roughly halves the per-device throughput, before any other constraint applies.
- Server CPU: encryption and decryption are CPU-bound. OpenVPN in particular can saturate a server's CPU before the network is saturated, because the AES-256-GCM cipher takes a meaningful fraction of a modern server core per gigabit of traffic. WireGuard uses about a third of the CPU, so the same hardware sustains roughly 3x more connections on WireGuard than on OpenVPN.
- Household upstream: the household's own internet connection is the final bottleneck. A 100 Mbps connection shared across 5 devices caps each device at 20 Mbps before any VPN overhead. Once the VPN is on, the effective per-device throughput drops to 16 to 19 Mbps on a fast protocol, or 12 to 16 Mbps on a heavy protocol like OpenVPN.
- Activity mix: latency-sensitive activities (gaming, video calls, SSH) suffer more than throughput-sensitive activities (file downloads, video streaming) once contention starts. A household running a 4K stream, a video call, and a large download sees the video call drop frames first, even though the stream and the download are still running.
The cumulative effect of the four constraints is that a 10-device plan typically delivers 4 to 6 devices at usable speed on a single server, and 2 to 4 devices at usable speed when the household is running latency-sensitive activities in parallel. The exact working limit depends on the server, the protocol, the base internet speed, and the activity mix, but the order of magnitude is consistent across most providers.
The line items that make up the real cost of the working limit
The price comparison "10 devices for $4 per month" hides a much longer list of line items that affect what the household actually gets. The table below lines up the line items, what each one typically looks like, and what it is really worth in slots, throughput, or working devices. Numbers are illustrative ranges across common consumer VPN providers; verify the actual simultaneous connection cap, the money-back window, the supported protocols, and the per-server bandwidth on the provider's pricing or support page before signing up.
| Cost line item | Typical behavior | What it is really worth |
|---|---|---|
| Marketed simultaneous connections | 5, 6, 7, or 10 devices on consumer plans; sometimes unlimited on higher tiers | The number on the pricing page; honest about what the account system allows but misleading about what the network can sustain |
| Working simultaneous connections (WireGuard, single server) | 40% to 60% of the marketed cap; 4 to 6 on a 10-device plan | The number of devices that actually run at usable speed on the same server; the real working limit |
| Working simultaneous connections (OpenVPN, single server) | 25% to 45% of the marketed cap; 3 to 5 on a 10-device plan | OpenVPN uses 2x to 3x more CPU than WireGuard, so the same hardware supports fewer connections at usable speed |
| Per-device throughput on a 10-device plan (WireGuard, 100 Mbps base) | 16 to 19 Mbps per device when 5 devices are connected | The realistic throughput per device after VPN overhead, household sharing, and protocol overhead |
| Per-device throughput on a 10-device plan (OpenVPN, 100 Mbps base) | 12 to 16 Mbps per device when 5 devices are connected | OpenVPN adds more overhead than WireGuard, so the per-device throughput is lower at the same device count |
| Server selection impact on working limit | Nearby servers deliver higher per-device throughput than distant servers | A device on a 5,000 km server typically sees 30% to 50% lower throughput than the same device on a 200 km server |
| Router-level connection throughput (WireGuard, 100 Mbps base) | 5 to 10 Mbps per device when 10 LAN devices share one slot | One slot covers every LAN device, but the per-device throughput is the same as a per-device plan divided by the device count |
| Money-back window for stress testing | 30 to 45 days on most consumer plans; 7 to 14 days on monthly plans | The window for running a household stress test to find the real working limit before committing |
| Plan upgrade for more working devices | $2 to $6 per month more for a higher simultaneous cap on the same provider | The cleanest single purchase for a household that is consistently over the working limit; the working limit rises proportionally with the cap |
| Multi-hop or double-VPN cost | Halves the effective working limit because every byte is encrypted twice | Multi-hop is rarely worth the throughput hit unless the threat model requires it; the working limit drops to 2 to 3 devices on a 10-device plan |
| Split tunneling impact on working limit | Routes non-VPN traffic outside the tunnel, freeing bandwidth for VPN traffic | Split tunneling effectively raises the working limit by 30% to 60% on heavy-traffic devices, because non-VPN traffic stops competing for the tunnel |
| Time-of-day server load impact | Working limit drops 20% to 40% during peak hours (8 PM to 11 PM local) | A plan that delivers 6 working devices at 2 PM may deliver only 4 at 9 PM, because the server is shared with more users |
The cheapest way to read this table is to assume the marketed limit covers only the devices that are simultaneously signed in, and that the working limit is a fraction of the marketed limit once protocol overhead, household bandwidth, server load, and activity mix are factored in. The right answer depends on which constraint binds first for the household in question.
Why protocol choice changes the working limit
Protocol choice is the single most underweighted variable in the working-limit conversation, and it is the one most likely to swing the working limit by 30% to 50% without changing the plan or the price. The three protocols most consumer VPN providers support are WireGuard, OpenVPN, and IKEv2, and they differ in CPU cost, throughput, and latency in ways that matter for the working limit.
WireGuard is the most efficient. It uses modern cryptography (ChaCha20 for symmetric encryption, Curve25519 for key exchange) and runs in the kernel on most platforms, which means the encryption and decryption cost is roughly a third of OpenVPN's. On a 10-device plan, WireGuard typically sustains 5 to 7 devices at usable speed on a single server, while OpenVPN sustains 3 to 5. The trade is that WireGuard is newer, has fewer configuration options, and is not supported on every server or every router.
OpenVPN is the most widely supported. It runs in user space, which makes it portable across routers, NAS devices, and embedded platforms, but the user-space execution path adds CPU overhead. AES-256-GCM is the default cipher, and the throughput drop compared to WireGuard is roughly 30% to 50% on the same hardware. OpenVPN is also more configurable, which is why it remains the default on many router apps.
IKEv2 sits between WireGuard and OpenVPN. It is mobile-friendly (it survives network changes like switching from Wi-Fi to cellular without dropping the tunnel), and the CPU cost is closer to WireGuard than to OpenVPN. The downside is that IKEv2 is less widely supported on consumer routers, and the configuration is less well documented.
The protocol choice is not always available on every server, and the router app may default to OpenVPN for compatibility reasons. The cheapest way to get the most working devices from a plan is to set the protocol to WireGuard on every device that supports it, and to verify the setting in the app or the router admin panel. The change is free, and the working limit typically rises by 30% to 50%.
The router-level connection and the inverse working limit
A router-level VPN connection is the single most useful workaround for households that exceed the marketed cap, but it carries an inverse working limit that catches many buyers off guard. The trade is straightforward: one slot covers every device on the LAN, but the throughput is shared across every LAN device. The slot count drops to 1, but the working device count is limited by the per-device throughput, not by the slot count.
The mechanics depend on the router. Some providers publish a router app or a custom firmware image that runs on AsusWRT-Merlin, OpenWrt, DD-WRT, or GL.iNet routers. The app handles the configuration and the kill switch, and the user signs in once on the router. Other providers publish manual configuration files that the user loads into the router's stock firmware, with the trade that some advanced features (kill switch, split tunneling) are not available. A few providers support router-level connections only on specific protocols, and the choice of protocol affects the throughput and the working limit.
The honest assessment of the router workaround has three parts. First, the slot savings are real: a household that would otherwise need 10 to 15 slots gets full LAN coverage on one slot. Second, the throughput cost is real: a 100 Mbps connection shared across 10 LAN devices on a single router-level tunnel delivers roughly 5 to 10 Mbps per device on WireGuard, and 3 to 6 Mbps per device on OpenVPN. The per-device throughput drops further if the household is streaming 4K or running large downloads. Third, the trade-off is coverage breadth: a router-level VPN covers every device on the LAN, including devices that may not need the VPN, and excludes devices that leave the LAN (phones on cellular, laptops on travel Wi-Fi).
For a household that needs LAN coverage and can accept per-device throughput in the 5 to 10 Mbps range, the router workaround is the right answer. For a household that needs high per-device throughput (4K streaming, large downloads, gaming) on every LAN device, the per-device plan is the right answer even at a higher slot count. The choice depends on which constraint binds first.
Three household scenarios and the working limit on each
The example below compares three household working-limit scenarios using the same cost assumptions across each. The numbers are illustrative, but the structure of the trade shows up across most households.
Scenario A: solo user, 3 to 5 devices on a 5-device plan. A single user with one laptop, one phone, one tablet, and a streaming stick is at 3 to 5 devices on a busy day. A 5-device plan covers the entire household on the marketing side. On the working side, WireGuard sustains 3 to 4 devices at usable speed, and OpenVPN sustains 2 to 3. The solo user is well within both limits, and the cheapest answer is the cheapest plan tier that offers the 5-device cap, with no add-on and no router.
Scenario B: two-adult household, 8 to 12 devices on a 10-device plan. Two adults, each with a laptop, a phone, and a tablet (6 devices), plus 2 to 4 streaming devices and 2 smart-home devices that sometimes want VPN coverage (4 to 6 more). The household is at 8 to 12 devices on a busy day. A 10-device plan covers the marketing side most days but hits the cap during travel weeks or holidays. The working limit on WireGuard is 5 to 7 devices, and on OpenVPN is 3 to 5. The cheapest answer depends on the activity mix: a household that streams 4K on three devices at the same time is at 3 to 4 working devices, which is below the household need; a household that browses and emails on most devices can sustain 6 to 8 working devices without breaking a sweat.
Scenario C: family with home office, 15 to 25 devices on a 10-device plan with router. Two adults, two children, a home office with a work laptop and a work phone, plus streaming devices, smart home gear, and guest devices. The household is at 15 to 25 devices on a busy day. A 10-device plan is consistently over the cap, and the manual disconnect pattern is unsustainable. The router workaround brings the slot count to 1, but the per-device throughput on a 100 Mbps connection drops to 5 to 10 Mbps on WireGuard for 10 LAN devices. The working limit is the same as the per-device plan divided by the device count, which means the household accepts lower per-device speed in exchange for full LAN coverage. For a household that needs LAN coverage and can live with 5 to 10 Mbps per device, the router is the right answer; for a household that needs 25 Mbps per device for 4K streaming on multiple TVs, the per-device plan at a higher tier is the right answer.
The pattern across the three scenarios is that the marketed limit overstates the working limit by 40% to 60%, the working limit is constrained first by server bandwidth, then by household upstream, then by protocol choice, and the router workaround changes the slot count but not the throughput-per-device math. The buyer who wants the real working limit needs to test the plan with the household's actual device count, on the household's actual upstream, with the household's actual activity mix, during the money-back window.
Affiliate-aware note: CJ-partner providers and working limits
PriceGap currently does not claim current advertiser approval with any VPN provider, and this article contains no advertiser checkout links. For context, providers that PriceGap tracks as potential CJ advertiser candidates — such as NordVPN — are part of a separate advertiser-application workflow. If a future affiliate link is added to this page, it would be a tracked link to a specific provider's pricing or deal page, and it would be labeled accordingly in the disclosure. The decision about how many devices will actually run at usable speed on a VPN plan should be based on your own household stress test, your own upstream connection, and your own activity mix during the money-back window, not on which provider pays a commission.
Common working-limit mistakes to avoid
The pattern of mistakes below shows up repeatedly in user reports and support tickets. They are listed here because each one is cheap to avoid once you see it.
- Assuming the marketed limit is the working limit. A 10-device plan delivers 4 to 6 devices at usable speed on a single server, not 10. The marketed limit is the cap the account system enforces, not the cap the network can sustain.
- Leaving the protocol on OpenVPN when WireGuard is available. WireGuard is 30% to 50% more efficient on the server, which means the working limit rises by 30% to 50% with no plan change. Check the protocol setting on every device and on the router.
- Forgetting the household upstream bottleneck. A 100 Mbps connection shared across 5 devices caps each device at 20 Mbps before any VPN overhead. Upgrading the plan does not upgrade the household's own internet, and the upstream is often the first constraint to bind.
- Testing the plan with one device and assuming the working limit. A plan that delivers 90 Mbps on one device typically delivers 18 to 22 Mbps per device on 5 devices, and 9 to 12 Mbps on 10 devices. The single-device test does not predict the household's working limit.
- Ignoring peak-hour server load. A plan that delivers 6 working devices at 2 PM may deliver only 4 at 9 PM, because the server is shared with more users during peak hours. Test during the household's busiest hour, not during off-peak.
- Skipping the money-back window stress test. The 30 to 45 day money-back window is the cheapest opportunity to find the real working limit. Buyers who skip the stress test often discover the working limit is too low for the household at the renewal moment, when the refund window has closed.
Buyer checklist: matching the VPN plan to your real working limit
- Run a household stress test inside the provider's 30 to 45 day money-back window. Connect 2, 4, 6, 8, and 10 devices in turn, run a speed test on each, and record the per-device throughput at each count. The lowest count that still meets the household's per-device speed floor (25 Mbps for 4K streaming, 5 to 10 Mbps for video calls, 1 to 3 Mbps for browsing) is the real working limit.
- Set the protocol to WireGuard on every device that supports it. WireGuard uses roughly a third of the CPU of OpenVPN, which raises the working limit by 30% to 50% with no plan change. Verify the setting in the app and on the router, because the router app sometimes defaults to OpenVPN for compatibility reasons.
- Measure the household's actual upstream and downstream speed before signing up. A 100 Mbps connection shared across 5 devices caps each device at 20 Mbps before any VPN overhead; a 50 Mbps connection caps each device at 10 Mbps. The household's own connection is often the first constraint to bind, and upgrading the VPN plan does not upgrade the household's internet.
- Test the plan during the household's busiest hour, not during off-peak. Server load varies by time of day, and a plan that delivers 6 working devices at 2 PM may deliver only 4 at 9 PM. The real working limit is the lowest reading across the household's typical day.
- Identify which devices are latency-sensitive (gaming, video calls, SSH) and which are throughput-sensitive (file downloads, video streaming). Latency-sensitive devices suffer more from contention; a household running a video call and a 4K stream should expect the call to drop frames first, even though the stream and the download are still running.
- Compare a per-device plan against a router-level plan for the household. The router workaround uses one slot but shares the throughput across every LAN device; the per-device plan uses more slots but delivers higher per-device throughput. The right answer depends on whether the household values LAN coverage or per-device speed more.
- If the working limit is consistently below the household need, request a refund inside the money-back window and switch providers. The money-back window is the cheapest moment to discover the working limit, and a buyer who skips the stress test often discovers the limit at the renewal moment, when the refund window has closed.
- Re-test the working limit every six months. Server load shifts, the household adds new devices, and the base upstream may change. The working limit is not a fixed property of the plan; it is a snapshot of the household's traffic, the provider's server fleet, and the time of day. Re-test before the next renewal to confirm the plan still meets the household's working limit.
Affiliate disclosure: PriceGap is an independent buyer-education site. This article contains no advertiser checkout links, does not claim a current sponsor relationship with any VPN provider, and does not quote fixed live simultaneous connection caps, per-device throughput numbers, or money-back window lengths. Simultaneous connection limits, working device counts, per-device throughput, server load patterns, protocol overhead, and money-back window terms change frequently; verify current terms, supported protocols, refund windows, and your own household speed directly with the provider before signing up, upgrading, or setting up a router.