OpenFront Lobby Pools: When a Listed Lobby Sends You to a Sibling

Direct answer

A lobby pool is a group of two to eight identical lobbies that a host creates at once; only the first one appears in the public list. When you join that listed card, the server picks one sibling for you with a deterministic hash and sends a redirect that your client follows automatically. You are routed only as a fresh joiner: reconnecting players, spectators, allowlisted players, and admins keep their lobby. Pools shipped in v0.34.19 (2026-09-25) but only formed reliably from v0.34.20 (2026-09-26). If you land in a sibling without your friend, the redirect already happened once — reload the original listed lobby and try a second entry.

The practical sequence behind that answer is worth spelling out, because it is the part that explains every symptom in this guide. You click the listed card, the client opens a connection to the entry lobby, and before the entry ever answers “open” or “full” the server runs the pool check on your join. If you are a fresh joiner and the hash target is a different sibling, the server sends you a redirect frame naming that sibling’s id; the client then does a full page navigation to the sibling and you load that sibling’s room, not the entry’s. The entry never fills up because of you in that case, and you never see a “this lobby is full” screen for the entry. If the hash target happens to be the entry itself, no redirect is sent and you load the entry directly. The same card, the same mode, the same start countdown — but the room you end up in is one of up to eight, and you do not get to choose which one. That is the entire feature from your side: a transparent, one-way redirect that the client follows without asking you, and a lobby you loaded that is not the one the card named.

Two things are not true, and they are worth stating before anything else. First, the pool never moves a player who is already inside a lobby, so you are never re-routed mid-game or after a reconnect — a disconnect-and-rejoin lands you back in the same sibling you were standing in. Second, the siblings are never shown to you: there is no pool-size badge on the card, no member list, and no way to pick a specific sibling. Everything else in this guide is detail on exactly those two facts — who is exempt from the redirect, which release made working pools real, and how to tell a genuine pool redirect apart from the unrelated failures (bot-check bounces, kicks to the menu) that share the same “I tried to join and got an error” symptom. If you are reading this because a listed card put you in a room you did not expect, the short version is: that is the feature working, not a malfunction, and the rest of the guide tells you how to confirm it and what to do about the cases where it is not the cause.

Why a listed card can be several lobbies

In every release before v0.34.19, a lobby card in the public browser was exactly one lobby: one roster, one start timer, one room. If that room was full or not yet open, the server told you so and you stayed on the browser. From v0.34.19 onward, a host that creates a listed lobby through the admin pool route can mint up to seven more siblings at the same moment, all sharing the entry’s configuration. The public list still shows a single card — the entry — because sibling identifiers are treated as join secrets and the server strips them from every lobby_info frame it sends. What changes is what happens the moment you click join: instead of answering “full” or “open” for one room, the server now asks which member of a small group of rooms should take you.

This design answers a real problem players reported before pools existed. The public lobby list is thin; community threads repeatedly asked for a filterable list or complained that waiting for a listed game took twenty minutes or more. One listed card that absorbs a whole crowd into eight rooms is a capacity fix that does not change the browser at all: the card looks the same, the mode and modifier pills look the same, and the start countdown looks the same, but the effective room size is multiplied. That is the one-sentence purpose of a pool, and it is also why the feature is invisible until you notice that the lobby you loaded is not the one your friend loaded.

The mechanics are deliberately one-way. The server can route a joiner from the entry to a sibling, and it can also route a joiner who arrives directly at a sibling back into the pool for load balancing, but it never moves players who are already inside a lobby, and it never exposes the sibling set to clients. There is no in-game list of pool members, no “pool of 8” badge on the card, and no way to browse the siblings. The only observable effects are where you spawn and which player roster you land in. If you want the surrounding context for what the public card itself promises — mode, host-selected one-to-five-minute start, ten-to-one-hundred player cap, and the subscription gate for hosting — read the public lobby guide. If the card you want to list is behind a plan, the public special lobby guide covers the gate that decides whether you can create a listed lobby at all.

How the server picks your sibling

The routing function is small and fully deterministic: a hash of your persistent identity, mixed with the pool’s own identifier, modulo the number of siblings. Written out, the server computes index = hash(poolId + ":" + yourPersistentId) % siblingCount, then looks up the sibling at that index in the pool’s ordered list. If that index happens to be the lobby you already pointed at, the redirect is skipped entirely and you join the room you clicked — so a pool does not force a redirect on everyone, only on the majority of joiners.

Two properties of that formula matter for how the feature feels. First, the pool identifier is mixed in before the modulo, which means the same player pointed at two different pools of the same size can land on different ordinals: you are not pinned to “always lobby three” across every equally sized pool on the server. Second, the hash is stable per player, so within one pool you will always be sent to the same sibling as long as the pool size does not change. You cannot roll for a different lobby by re-joining, because the input to the hash does not change when you re-enter. What does change the input is the pool size: a host cannot add or remove siblings after creation, but two different pool groups with different sizes will distribute the same player differently.

Because the hash is computed from a stable player identity, the routing is also consistent in a way that matters for team lobbies: the server does not shuffle teammates apart on purpose, and it never breaks up an existing roster, because reconnection is exempt (see the next section). What it does do is spread new joiners. A pool of eight therefore behaves like a single card with eight rosters: the first joiners each land on a different sibling, and after the first round the distribution is whatever the hash says. There is no “fill room one, then room two” ordering — the modulo does not prefer the first empty room, it prefers a deterministic bucket. That is why a pool can have one sibling nearly full and another nearly empty at the same moment, and why you should not read the player count on a sibling as a signal of how full the pool as a whole is.

The redirect itself is a control frame, not a lobby message. The server sends a message of type redirect carrying the target lobby id, and it sends it before any full-or-started answer. In the server code the comment on that ordering is explicit: being routed is not a refusal. That distinction is the single most important fact for interpreting bounces, because it means a “you were sent elsewhere” outcome and a “this lobby is full” outcome are different server decisions, and a player-facing error that follows a redirect attempt has to be diagnosed against the redirect path, not the full-lobby path.

Who gets routed, and who does not

The admission path runs the pool check in a fixed order, and that order defines the exemptions. First, the server checks whether the joining client already exists in the target roster as a player: if it does, the join is a reconnection and the pool logic is skipped. Second, the server checks roles and lists: an admin joining the lobby, a player on the lobby’s allowlist, and a client whose role is spectator all bypass the redirect. Third, for everyone else who is genuinely new to the roster, the server computes the hash target and, if it differs from the lobby you pointed at, issues the redirect.

Practical consequences worth memorizing:

• Reconnection never re-routes. If you disconnect mid-match and come back to the same lobby, you land back where you were. The server identifies you in the existing roster before the pool check, and the pool check is skipped. A “I got kicked back to the menu and re-joined” experience is therefore never a pool redirect; kicks and disconnects are a different failure class, handled outside pool routing.
• Spectators are pinned. Turning on spectator mode in a pool entry refuses the toggle if the hash target is another member: you cannot spectate the lobby you would have been routed into as a player. You spectate exactly the lobby you are pointing at.
• Allowlist beats pool. A player on the entry’s allowlist joins the entry itself, no matter what the hash says. If you and a friend want to be in the same room in a pool environment, the only supported mechanism is the allowlist.
• Admins are pinned. Staff joining a pool entry stay in the entry, which is how operators can watch the entry card without being scattered across the pool.
• Fresh joiners are spread. Everyone else — the normal case — is hashed into one of the siblings.

One more asymmetry: the redirect is only ever into the pool for a new joiner. The server never moves a player from one sibling to another as rosters fill, so there is no “top-up” behaviour that would pull a player out of a lobby they are already standing in. The pool distributes joiners at the door; once you are inside, you are inside.

The practical rule that falls out of that ordering is that the pool check is not a separate gate after admission; it is the first classification of your join. The server has to answer the question “is this client already inside the room I am pointing at?” before anything else, and the answer to that question is what decides whether the pool logic runs at all. If you are already in the roster, you are a reconnector and the pool is skipped entirely — the server will not “re-bucket” you into a different sibling just because you dropped. If you are a new face, the server then checks roles and lists in a fixed order (admin, allowlist, spectator) and only the leftovers — the genuinely fresh joiners — get hashed. This is why the exemptions are not a menu you can opt into or out of: they are properties of your connection state and your role, not settings on the lobby card. The one case that trips people up is a reconnection that looks like a fresh join. If you disconnect mid-match, return to the menu, and click the same listed card again, the server recognizes your persistent identity in the existing roster and treats the join as a reconnection, so you land back in the same sibling you were in before the disconnect. You do not get re-hashed onto a different room. That is what makes “I got kicked to the menu and re-joined” a disconnect symptom, not a pool redirect: the rejoin path and the fresh-join path are different code paths, and only the fresh-join path ever issues a redirect.

The version boundary: v0.34.19 announced it, v0.34.20 made it work

The feature’s history is two releases deep and the boundary matters, because the two releases make different claims. The v0.34.19 release notes (published 2026-09-25) announce the feature: a listed lobby can spread joiners across a pool of sibling lobbies. The v0.34.20 release notes (published 2026-09-26) then say the fix: lobby pools that never formed in production now form, and listed lobbies can actually spread joiners across sibling lobbies. The second bullet exists because the first release shipped code that did not produce working pools in the live environment; between the two release dates, the routing code was present on the server but pools were effectively not being created.

Three consequences follow. First, any community report or stream from the v0.34.19 window that says “pools don’t work” is consistent with the release record, not a bug report against v0.34.20. Second, the live behaviour you are reading about in this guide is the v0.34.20-and-later behaviour; if you read an older guide or watch an older video that describes pool behaviour, check its version line before trusting it. Third, the pool size bound of two-to-eight, the entry-only listing, and the create-time-only configuration all come from the same code revision that v0.34.20 shipped, so every number in this guide is a v0.34.20 number.

The configuration itself is also version-locked in a second, quieter way: the pool block is create-time only. The lobby patch route does not copy a pool field, which means a host cannot add siblings to an existing listed lobby or re-size a pool after creation. If you want a pool, you create the pool at the start; there is no in-game upgrade path from “single listed lobby” to “listed lobby with seven siblings”. This is a design decision, not a missing feature: the shared auto-start deadline and the shared configuration make a pool a single atomic object, and the release record contains no later release that extends the pool block through the patch route as of the version boundary documented here.

What the boundary means for your client. If you are on a client from before v0.34.19, pools do not exist for you at all: every listed lobby is a real, single lobby, and the behavior you see is plain join/full/queue logic. The first client in which a listed card can silently put you in a sibling is the v0.34.19 client (2026-09-25), but on that release the feature was announced with an explicit caveat that pools were not fully formed yet — meaning a card that looked like a pool could behave inconsistently, and the safe assumption on v0.34.19 was that you cannot rely on pool mechanics. From v0.34.20 (2026-09-26) the routing is the stable, documented behavior this guide describes: the hash bucket, the one-way redirect, the shared pool config, and the auto-start deadline all work as specified. If you do not know your own client version, the version is shown in the launcher and in the settings screen, and the check is worth thirty seconds whenever a redirect surprises you: a player on a pre-v0.34.19 client who “got redirected” was almost never redirected by the pool, because the feature cannot run in that client — the cause is a bot-check bounce or a disconnect, not routing. One more boundary that trips people up: the pool is a server-side feature, so the server’s version matters as much as your client’s. On a server that runs an older build, no pool forms no matter how new your client is, and a “pool” lobby on an old server is just a normal lobby. The practical consequence is that version boundaries are checked against both ends: if you and your friend are on matching recent clients but the host’s server is older, you will not see pool behavior, and if the server is new but your client is old, you will not see it either. That is why the version check is part of the decision framework: before you start diagnosing a redirect, confirm that both your client and the server are actually new enough for the feature to be running at all.

Decision framework: what to do before you click join

Apply this ordering to any listed card in the public browser:

1. Decide whether same-room matters. If you are joining to play with a specific friend, the pool is hostile to your goal by default: each of you is hashed independently, and two independent hashes land in the same sibling only by coincidence (probability 1 in N for a pool of size N). The supported workaround is an allowlist on the entry lobby; if the host does not allowlist you, accept that you may be split.
2. Decide whether the exact roster matters. For competitive or ranked-relevant play where your opening team composition is a variable, a pool member’s roster is unknown until you load. If you care about the team you form, treat the pool as a random draw over eight possible rosters and plan for the worst case of a draw; if you do not, the pool is strictly better than a single full room, because the card stays joinable.
3. Check the start timer on the card. The pool shares one start deadline across all members (the entry’s deadline is copied to every sibling at pool creation), so the countdown you see on the card is the countdown for every member. You are never sent into a sibling that starts earlier or later than the card promises; the timer you read is the timer you get.
4. Assume the sibling set is closed. You cannot see the other members, you cannot choose between them, and you cannot see their player counts. Any strategy that needs that information (e.g., “join the emptiest sibling”) is not supported; the only controllable variable is your persistent identity, which is not something you should rotate to game the hash.
5. If you are hosting, decide pool size before creation. Two siblings doubles the effective room; eight makes the card nearly never show “full”. Pick the size for the expected crowd, not for the smallest that works, because you cannot grow the pool later.

The reason the checklist leads with connection stability is that the most common “I got redirected” report is not a pool redirect at all — it is a disconnect-and-rejoin, or a bot-check bounce, that the player mistakes for a routing event. The two failure classes share the visible symptom (you clicked the listed card and did not end up where you expected), but the causes are unrelated and the fixes are different. A pool redirect is deterministic, one-way, and silent: the client follows it without prompting, and you land in a sibling with the same mode and countdown. A bot-check bounce is a rejection, not a redirect: the server tells you to solve a challenge, and if you fail or dismiss it you are bounced back to the list, not moved to a sibling. A disconnect-and-rejoin is neither: you leave the lobby, return to the menu, and click again, and the server (seeing your identity already in the roster) treats the join as a reconnection and puts you back where you were. The checklist is built to separate those three before you start blaming the pool. If your connection was unstable or your bot-check status was unknown, fix those first; the pool is the last hypothesis, not the first. That ordering saves time in the two cases where the pool is genuinely not the cause, which is most of them, because working pools only form from v0.34.20 and not every listed lobby is a pool at all.

Scenario A: you clicked the listed card and landed without your friend

Setup: you and one friend both open the same listed FFA card in a pool of four. You click join, your friend clicks join, and you load into different lobbies. This is the expected outcome, not a bug: your two persistent identities produce two independent hash values, and with four siblings the probability you land together is 1 in 4. Nothing went wrong, and there is no server-side “keep us together” option for fresh joiners.

What to do, in order of preference:

• Ask the host to allowlist both of you. The allowlist exemption fires before the hash, so both of you join the entry directly. This is the only supported same-room mechanism in a pool, and it requires the host, so message the lobby host before the next pool event, not during.
• Re-enter through the entry together. If the host cannot allowlist, re-join the entry lobby (the listed card) rather than the sibling you ended up in. Your hash target is stable, so re-joining will put you back in the same sibling — which means re-joining does not help you find your friend; it only helps your friend if they re-join the entry and their hash happens to hit your sibling (again 1 in 4). Do not expect a reload loop to fix this; the input to the hash does not change on re-entry.
• Accept the split and coordinate in-chat. In FFA the split is often irrelevant; in team modes it changes your team, so if team composition matters to you, treat the pool as a coin flip and pick modes or lobbies where your team does not depend on a pre-arranged duo.

What not to do: do not interpret the split as a kick or a bot-check failure, and do not report it as “bounced from lobby” without the context that a pool was present — support and community threads will otherwise conflate this with the refusal failures covered in the failure section below.

A note on what a second attempt actually does, because the “just reload” advice is worth understanding rather than taking on faith. The hash is a pure function of your player identity and the lobby’s pool configuration, and those do not change between two clicks on the same card a few seconds apart. So what is actually different on a retry? The server’s view of which siblings currently have a slot to give. The redirect logic picks a sibling that still has room at the moment your join is processed; if the sibling it would have chosen a moment ago has since filled, the next hash that maps into it overflows to another sibling in the pool. The function itself is stable per player and per lobby — it does not reshuffle randomly from attempt to attempt — but the set of available targets does change as people fill in. That is the narrow, real mechanism by which a retry can land you somewhere new: not because the hash changed, but because the pool’s occupancy changed. It also means the retry is a gamble, not a guarantee: it can put you in the entry, or it can put you in a different sibling, and you will not know which until the redirect (or the absence of one) resolves. The one reliable case where you will not land in the entry on a retry is when your friend is already standing in the entry and you are hash-targeted to a sibling: re-entering fresh, you are hashed by the same function and will land in a sibling again, not in the entry where your friend is. The fix for that specific case is not “retry” but “make one of you a reconnector” — the host (or your friend) re-enters the lobby through a path that the server treats as a reconnection, which bypasses the hash, and then you are together. That is why the guide recommends the host re-enters fresh together with you when coordination matters: it makes both of you fresh joiners hashed by the same function, which is the only way to reliably end up in the same sibling.

Scenario B: you are hosting a listed lobby and the card fills while your siblings are empty

Setup: you host a listed team lobby in a pool of eight and the public card shows the entry near its player cap, while you know the pool has six other empty siblings. You expect the card to keep absorbing players, but new joiners keep landing on the entry and the card’s number climbs toward full.

Two things are happening at once. First, the hash spreads new joiners across the eight siblings, so the entry does not fill linearly: each new joiner has a 1 in 8 chance of landing on the entry itself. The card’s number is the entry’s roster, not the pool’s total, and the server never shows you the pool total. Second, the card’s “full” state is the entry’s full state: when the entry roster reaches its cap, the server answers “full” for the entry — and the redirect logic runs before the full answer, so a joiner pointed at a full entry can still be routed to a non-full sibling. The card can therefore show a full-looking number while the pool still has room, and that is the feature working as designed, not a stuck lobby.

Your operating procedure as host:

• Do not read the card number as the pool’s health. The only reliable statement you can make from the card is about the entry. If you need pool-level occupancy, the admin tooling is the source, not the public card.
• Size the pool for the peak, then accept the tail. Because the pool is fixed at creation, an undersized pool (two siblings for a crowd of forty) will show the entry filling while the pool still has room only briefly; an oversized pool (eight siblings for a crowd of ten) will leave six siblings nearly empty and scatter your community across lobbies. For a recurring listed event, eight is the safe default; for a casual duo-plus-friend lobby, two.
• Use the allowlist for your own core group. Your regulars can be allowlisted onto the entry so they always share a room with you, while the public crowd spreads across the pool. That keeps your core stable without sacrificing the pool’s capacity benefit.

One more hosting consideration that the scenario above does not cover is what happens to the pool’s auto-start deadline once players are spread across the siblings. The deadline is set at the group level, so it counts down once, not per sibling — which means a pool with eight siblings can start with one of them empty, because the countdown does not wait for every sibling to fill. If you host and care about a full house in each room, the lever you actually have is the sibling count, not the deadline: fewer siblings (two or three) keeps the group tight and makes it likely that every room is full by the deadline, while more siblings (six to eight) spreads players thin and makes empty rooms by the start time more likely. The deadline itself should be short enough that a half-full sibling does not sit idle for minutes, but long enough that a late joiner who is hash-targeted to a still-open sibling has time to land there before the start. The one thing the host cannot do is “pull” a specific player from one sibling into another — the redirect is one-way and there is no admin action that moves a player already seated in a sibling back to the entry. If you need a specific player in a specific room, the only reliable path is to time their entry: have them join fresh at a moment when the sibling you want still has room, or have them reconnect (if they are already in the pool) so the server puts them back where they were. That timing constraint is the host-side version of the player-side rule from Scenario A, and it is why the decision framework’s advice to “make both of you fresh joiners at the same moment” works: it is the host controlling the moment, not the server, that keeps a pair together.

Failures and countermeasures

The redirect path is small, but it has four distinct failure shapes, and each has a different cause and a different countermeasure. Diagnosing which one you are looking at is the whole game here, because the player-facing symptom for at least two of them is “I tried to join and got an error”.

1. Redirect followed, then a connection error. The client’s redirect handler sets a latch in sessionStorage when it follows a pool redirect and treats a second redirect as a connection refused, so the client cannot loop between two siblings. If you get an immediate “connection refused” right after a listed card, the likely causes are: the target sibling was removed or closed between the redirect decision and the connect attempt (rare, server-side), or the latch is already set from a previous failed attempt in the same tab and the second redirect is being treated as a loop. Countermeasure: close the tab entirely (clearing sessionStorage) and re-enter through the listed card. Do not retry in the same tab more than once.
2. Redirect followed, target not in the pool you expected. If you land in a lobby whose mode or map does not match the card, that is not the pool: every sibling of a pool shares the entry’s configuration by construction (the siblings are minted from the same config, and the patch route cannot diverge them). A mode or map mismatch means you joined the wrong card, not that the pool mis-routed you. Countermeasure: re-check the card’s mode and map pills against the lobby you loaded; if they differ, you clicked a different listing.
3. Refusal that looks like a pool bounce but is a bot-check refusal. “Connection refused: Unauthorized: Turnstile token rejected” is the Cloudflare bot detector refusing the join, and it is unrelated to pool routing. Community threads from 2026 report this as the most common “bounced from lobbies” complaint, and it predates pools. Countermeasure: the standard bot-check remedies (reboot, try another lobby, try a different network) apply, and none of them involve the pool. If you are bounced by this error from one lobby but not another, the cause is the token, not the lobby.
4. Kick-to-menu mid-match. A sudden return to the starting screen is a disconnect or kick, and reconnection is exempt from pool routing, so a kick is never a pool redirect. If you are kicked and then re-join, you land back in your original lobby, not a sibling. Countermeasure: check the standard causes (server restart, inactivity, session expiry) before attributing a mid-match kick to the pool.

A quick diagnostic table for the four shapes:

Symptom	Cause	Countermeasure
”Connection refused” immediately after joining a listed card	Redirect anti-loop latch, or target closed between decision and connect	Close the tab, re-enter through the listed card
Loaded lobby’s mode/map differs from the card	Wrong card, not a pool mis-route (siblings share config)	Re-check the card pills; re-join the correct listing
”Turnstile token rejected”	Cloudflare bot-check refusal, unrelated to pools	Standard bot-check remedies; report as a token issue, not a pool issue
Kicked to menu mid-match, re-join lands in the same lobby	Disconnect/kick; reconnection is exempt from routing	See the disconnect/kick causes above

Mode and map adjustments

Pools do not change the mode, the map, or the modifier pills: all siblings inherit the entry’s configuration, and the server strips nothing from the config frame except the sibling identifiers. What pools change is the player mix inside a mode, and the adjustments below are per-mode notes on what that means for your opening decisions.

• FFA. The pool is a net positive. Your opening position is drawn from your own choices, not from the roster, so the only thing that changes is the crowd size available to the card. If you play FFA against a listed card, treat the card as “joinable until the pool is genuinely full”, and do not bail because the entry’s number looks high.
• Team modes. The pool is the variable that matters. Your team is whatever the sibling’s current roster plus you produces, and the sibling is unknown until you load. If you are the de facto leader of a team you want to control, the allowlist is your tool; if you are a flex player, the pool is a feature: you land on whatever roster needs your role. Plan your opening build for the worst draw of team composition, not the expected one.
• Nuclear / high-stakes lobbies. If your mode has long lead times (nuclear prep, SAM networks), a split across siblings is expensive: your planned counter to a specific opponent’s base may be in a sibling you never see. For lobbies where you are countering a named player, the allowlist or a private lobby beats the pool; for open public play, accept the split.
• Map-specific reads. A pool does not change which map is loaded, so map knowledge transfers across siblings unchanged. What does not transfer is the state of the map: the two siblings are running the same map at the same start time, but with different players and therefore different early expansion. Do not assume your teammate from the entry is in the sibling you loaded; re-identify your roster in the first thirty seconds.

The mode and map angles are about the same feature wearing different hats, and the differences matter for how you should react. In ranked and competitive modes, a pool redirect is usually less disruptive than it is in casual FFA, because the mode’s matchmaking and lobby rules are stricter and the pool is less likely to be formed in the first place. If you do get redirected in a ranked context, the practical consequence is the same (you land in a sibling with the same mode and countdown), but the stakes of being in a different room than your teammate are higher, so the coordination advice in the decision framework matters more. In casual FFA and public special lobbies, pools are the more common case, and the redirect is a normal part of the experience rather than an exception. On maps, the pool does not change the map — every sibling runs the same map as the entry, because the pool group shares the entry’s configuration. What changes is the composition of the room: a sibling may have a different mix of players, a different skill spread, and a different set of veterans than the entry you were looking at in the list. That is the practical thing to internalize when a redirect changes your game plan: the map and mode are identical, but the people you are playing with or against are different, and a sibling that looks “the same” in the list can play very differently in practice. The one map-specific consideration is that pool groups are created by the host and the host picks the map, so if you are hosting a pool you are also picking which map every sibling runs on, and the map choice is the same for all eight (or however many) siblings in the group. That means a map choice that works well for a single lobby is a map choice that works well for every sibling in the pool, and a map that is awkward for a lobby is awkward for the whole group.

Table: the pool at a glance

Property	Value	Where it comes from
Pool size	2 to 8 siblings	create_pool route validates count with min(2).max(MAX_POOL_MEMBERS), MAX_POOL_MEMBERS = 8
Listing	Only the entry is listed	applyListing is applied to lobbies[0] only at pool creation
Configuration	Shared, fixed at creation	Siblings minted from the entry’s config; the patch route does not copy pool
Start time	One shared deadline for the whole pool	Entry’s auto-start deadline copied to every sibling (setPoolAutoStartAt)
Routing input	hash(poolId + ":" + persistentId) % size	poolIndexFor / poolTargetFor in PoolRouting.ts
Redirect target	Sibling at the hashed index; skipped if equal to the entry you pointed at	poolTargetFor returns null when target equals entry
Exemptions	Reconnection, admin role, allowlisted publicId, spectators	Admission path in GameServer.ts
Spectator toggle	Refused if the hash target is another member	setSpectator pool check
Client behaviour	Follows the redirect via full page navigation; sessionStorage latch prevents a second redirect (treated as refused)	Transport.ts redirect handler
Sibling identifiers	Stripped from every lobby_info frame (join secrets)	configWithoutPool in GameServer.ts
Team pins	Rejected for pools (teams_unsupported_for_pool)	create_pool validation
Release boundary	Announced v0.34.19 (2026-09-25); working from v0.34.20 (2026-09-26)	v0.34.19 and v0.34.20 release notes

How to read the table, because the rows are not a checklist you work top to bottom but a set of facts about one feature, and the order is chosen so that each row answers the question the previous row raises. The first three rows are the what (what a pool is, what the redirect does, who is exempt), and they are the rows to read first if you are new to the feature. The middle rows are the when (the version boundary and the auto-start deadline), and they are the rows to read if you are trying to understand why a pool did or did not form on a given version. The bottom rows are the how (the admin command, the client redirect, the redirect-once guarantee), and they are the rows to read if you are the host or the admin and need to create or inspect a pool. The table is deliberately terse — it is a reference, not a tutorial — so the row that matters most to you is the one that answers the question you came with, and the rest is there for when you need to cross-check a detail. If you are a player, the rows you care about are “who is exempt” and “the redirect is one-way”; if you are a host, the rows you care about are “create_pool” and “auto-start deadline”; if you are an admin, the row you care about is “the pool config is shared across siblings.” The most common practical use is to open the table when a behavior surprises you and find the row that matches the symptom: a player who landed in an unexpected room looks at the “the redirect is one-way” row to remind themselves they cannot “go back” to the entry; a host whose pool did not start looks at the auto-start deadline row to check the countdown was not too short; an admin inspecting a pool looks at the shared-config row to remember that every sibling inherits the entry’s mode and map. The table therefore works as a quick anchor: instead of re-reading the whole guide when a specific detail escapes you, you find the row that carries that detail and come back to it, which saves time compared to searching the full text.

A verifiable tool: the admin pool route

The one place you can see a pool rather than only experience it is the admin bot API. The route POST /api/adminbot/create_pool is the only way a pool comes into existence, and its request shape documents the feature’s constraints in machine-readable form:

POST /api/adminbot/create_pool
{
  "count": 4,                    // 2..8, the number of siblings (entry included)
  "lobby": { ...config... }      // the entry's full lobby config; siblings copy it
}

Three properties of the request make the constraints concrete. The count field is the only sizing knob, and it is validated against min(2).max(8) — a request for one sibling is rejected, and a request for nine is rejected, so the size bound in the table above is not a documentation claim, it is a validation error you can trigger. The lobby config is the single source for every sibling: there is no per-sibling field in the request, which is why siblings cannot diverge in mode, map, or modifier pills. And the response returns the minted lobby identifiers, with only the first one listed — the response itself shows the pool’s shape (N identifiers, one public listing), which is exactly the shape a player never sees from the client side.

You will not normally call this route yourself: it is an admin-bot endpoint, and the public player path is simply “join a listed card and let the server route you”. The route matters for this guide because it is the ground truth for every number in the table above — size bound, entry-only listing, shared config, create-time-only existence — and if a future release changes any of those numbers, this route’s validation and response shape are where the change will be visible first.

What the admin route does, from the host’s perspective. The create_pool command is how a pool comes into existence: the host (or an admin with the permission) names a pool and specifies how many siblings it should contain — between two and eight — and the server then spins up the sibling lobbies with the shared configuration. From the host’s side the important facts are that the pool group is a single unit of management (you create, rename, and dissolve the group, not each sibling individually), that every sibling inherits the entry’s mode, map, and rules, and that the auto-start deadline is set at the group level, so a single countdown governs when all siblings start together. The one-way nature of the redirect is also an admin-facing fact: once a player has been sent to a sibling, there is no “undo” that pulls them back to the entry — if you need a specific player in a specific room, the reliable path is to make them a fresh joiner at the right moment (or a reconnector, if they are already inside the pool), not to wait for the server to move them. If you are running a public lobby with a pool, the two decisions that matter are the sibling count (more siblings means more parallel rooms, which is good for reducing “full” screens on popular cards but means players are more spread out) and the auto-start deadline (a short deadline keeps the pool from idling with a room or two half-full, a long deadline gives late joiners a chance to land in a sibling before the start). The tradeoff is the same for every host: tight deadlines and small sibling counts keep rooms cohesive, loose deadlines and large sibling counts keep the entry card from filling up. The command itself is documented in the admin reference for your server version; what this guide covers is the behavior the command produces, which is what players actually experience.

What to verify in your own session

Because pools are invisible from the client, the only honest verification you can do is behavioural, and it takes one join:

1. Join a listed card that you believe is a pool (a host-created listed lobby during an event is the likely case) and note which lobby you load.
2. Ask a friend who joined the same card at the same time which lobby they loaded. If they are in a different lobby with the same mode, map, and start time, the card was a pool and the routing worked as documented.
3. If both of you are in the same lobby, either the pool size is one (no pool) or your two hashes collided; with a pool of eight, the collision probability is 1 in 8, so one same-room result is weak evidence either way — repeat with more friends for a stronger read.
4. If you are bounced with a “Turnstile token rejected” or a kick-to-menu instead, that is not a pool outcome: apply the failure countermeasures above before attributing anything to routing.

The negative case is as important as the positive one: if a listed card never splits you from a friend across several independent joins, the card is not a pool (or the pool size is one). “This card always lands me in the same lobby as my friend” is, in a pool environment, the signal that the pool is not present.

The verification checklist is ordered from cheapest to most involved, because the first three checks cost seconds and rule out most of the cases. The version check (is my client at or after v0.34.20, and is the server running a build new enough for pools?) is the cheapest and the most commonly skipped. The connection-stability check (was my connection dropping around the time of the “redirect”?) is next, and it is the one that separates a genuine pool redirect from a disconnect-and-rejoin. The bot-check status check (was I flagged for a bot-check challenge around that time?) is the third, and it is the one that separates a pool redirect from a bot-check bounce. If all three checks come back clean and you still landed in a sibling you did not expect, then the pool is the correct explanation, and the remaining items in the checklist are about confirming that and acting on it. The confirmation step is to look at the lobby’s identity once you are inside: a pool sibling has the same mode, map, and countdown as the entry you clicked, but a different room identifier, and that identifier is what the redirect pointed at. The action step is the one from the decision framework: if you need to be with a specific player, make that player a reconnector (re-enter through a path the server treats as a return, not a fresh join) or make both of you fresh joiners at the same moment so the hash puts you in the same sibling. The whole checklist is deliberately short and specific because the feature is narrow: pools are a one-way, deterministic, client-transparent redirect that only applies to fresh joiners, and every item in the checklist is a check for one of those four properties. If a check fails, the pool is not the cause; if every check passes, the pool is the cause, and the guide’s scenarios tell you exactly what to do next.

Bottom line

A lobby pool is a capacity device, not a destination choice: one listed card, up to eight rooms, one shared start, one fixed config, and a deterministic hash that spreads fresh joiners across the rooms. You do not choose the sibling, you cannot see the siblings, and you cannot see the pool’s total occupancy — the card is all you get, and the card’s mode, map, and timer are still exactly what they promised. The decisions that change are the social ones: same-room play needs an allowlist, team play needs a worst-draw plan, and a “bounced” symptom needs the four-shape diagnosis before it gets blamed on routing. From v0.34.20 onward the mechanism works as the release notes describe; before that, it was announced but not live.

The short version for the player who does not want to read the rest. A pool is a group of two to eight identical lobbies behind one listed card, created by the host with create_pool, and the card you see in the list is only the entry. When you click that card as a fresh joiner, the server runs a deterministic hash on your identity and, if it maps to a different sibling that still has room, it sends a one-way redirect that your client follows automatically — you land in the sibling with the same mode, map, and countdown, and you do not get to pick which sibling. The pool never moves a player who is already inside a lobby, so a reconnect puts you back in the room you were standing in, and the redirect happens at most once per join. Pools shipped in v0.34.19 with an explicit “not fully formed yet” caveat and became the stable, documented behavior from v0.34.20, and because the feature is server-side the server’s build has to be new enough as well as your client’s. The four things to keep in your head are: the redirect is deterministic per player and per lobby (a retry does not reshuffle the hash, it only changes which siblings have room); it is one-way (there is no undo that pulls you back to the entry); it only applies to fresh joiners (reconnectors, spectators, allowlisted players, and admins are exempt); and it is silent (the client follows it without prompting, so “I clicked the card and ended up somewhere else” is the whole experience). If a listed card put you in a room you did not expect, that is the feature working, not a malfunction; the only time to suspect something else is when your version, connection, or bot-check status was not clean, in which case the cause is a bot-check bounce or a disconnect, not routing. If you need to be with a specific player, the reliable fix is to make them a reconnector or to make both of you fresh joiners at the same moment so the hash puts you together — not to retry the card and hope the pool puts you in the entry. That is the entire player-facing model of lobby pools, and the rest of the guide is the detail that backs each of those four facts.