Skip to main content
⌖ OF Intel

GUIDES

When Should a Host Pay to Queue a Listed Lobby into the Public Special Queue?

OpenFront v0.34.18 lets the host of a listed lobby pay Plutonium to jump straight into the public Special queue, right behind the lobby that is counting down. Here is exactly what that buys you, when it is worth it, and when listing and waiting is the better call.

Tutorial Difficulty · Intermediate Published Sep 25, 2026 Updated Sep 25, 2026 Reviewed by OpenFront Intel editors #public-lobby#queue#lobby-listing#hosting#plutonium#strategy

A listed hosted lobby in OpenFront does not automatically find the audience it wants. You create a private room, you flip it public, and then you wait for the hosted list to churn and for someone to click your card before the five-minute auto-start fires. In v0.34.18 — the release that shipped on 2026-09-24 — the host of a listed lobby gets a new lever: a Queue button that pays Plutonium to put your listed lobby directly into the public Special queue, right behind the lobby that is currently counting down. That single change converts “I hope my listed lobby gets seen and filled before it auto-starts” into “I can pay to guarantee my lobby a front-of-the-line spot in the public feed at a known moment.” This guide is the host-side decision that follows from that: when is the Plutonium worth paying, and when is listing and waiting the cheaper and better play? The short answer is that the queue is a timing and visibility purchase, not a fill guarantee — it makes your lobby appear in the right public queue at the right moment, but it does not force players into your room.

A first map of the decision, so the rest of the guide has a place to hang:

LeverCostWhat it buysUse it when
Queue buttonPlutonium (server-set, shown on button)Public Special-queue slot behind the counting-down lobbyTimed, scenario, cast, or slow-hosted-list lobby
Host start timerFreeStart time 1–5 min at listing, locked once listedYou want to control when your listed room starts
Player cap (10–100)FreeFilling the cap starts the game earlyYou want a smaller room that starts fast
Unlist + relistFreeCancels and restarts the 5-minute auto-start deadlineYou want more hosted-list time to fill
List and waitFreePlacement in the hosted queue on the normal scheduleNo timing, no cast, no concrete reason to start now

Everything below is built on the mechanic as it is in the live build, with the exact version boundary spelled out at the end.

What the Queue button actually does

The Queue button appears on the host dialog only when your lobby is publicly listed — that is, a private lobby you have chosen to show in the public browser. If the lobby is not listed, there is no button; if your lobby is already queued, the button is replaced by a green Queued badge. The button shows the price in Plutonium right on it, and that price is not a number the client invents: it is read from the live server configuration (the lobbyQueue price in the cosmetics config), and if that value is not present the button is hidden entirely. So the first thing a host checks is simply whether the button exists and what it costs — the exact Plutonium price is set by the server at play time and can change between builds, which is why this guide describes the mechanism rather than quoting a fixed number.

Two more eligibility conditions gate the button before price even comes into play. Only the creator of the lobby can pay to queue it — a second player sitting in your room sees no working queue path for your lobby, so the purchase is a host-only act. And the lobby must be one that is still open and listed: a lobby you have already left, one that is not in the public listing, or one that is not private-and-listed simply has nothing to queue, so the button is absent rather than disabled. Put together, the button is visible exactly when you are the host, your lobby is private, it is listed to the public browser, it is not already queued, and your own start countdown is not already running. Understanding that boundary matters because it tells you when the decision point exists at all; the rest of this guide assumes you have passed it and are sitting on the dialog with a priced button in front of you.

When you click the button the game asks you to confirm, and the confirmation says exactly what is being bought: “Pay {price} Plutonium to send this lobby to the public queue? It will start right after the lobby that is counting down.” That sentence is the whole mechanic. Your listed lobby is not sent to the front of the line in a generic sense — it is placed right behind the one lobby that is currently counting down in the Special queue. The server sorts paid-queued lobbies oldest-first, so your lobby moves up one place every time the lobby ahead of it starts. The tooltip on the button makes the same point: “Put this lobby in the public Special queue, right behind the lobby that is about to start.” In other words, paying queues you for the next start cycle, and then you inherit position from the queue ahead of you. This is a placement purchase with a known insertion point, and it is the thing every decision in this guide is about. The button also disappears once your own start countdown is running or you are within 30 seconds of your auto-start, which is the cutoff that keeps a host from paying for a spot the lobby would pass on its own.

The three guarantees the charge gives (and the two it does not)

It is worth separating precisely what the Plutonium buys, because the difference is the whole decision. What the charge does guarantee: first, that your listed lobby is placed in the public Special queue rather than sitting in the smaller hosted list, so it is visible in the queue players are actively scanning for a lobby to join. Second, that it is inserted at a specific, known position — immediately behind the lobby that is counting down — so you are not competing against other newly-listed rooms for a slot you have to wait for. Third, that the charge is safe from double-billing: the server checks every refusal condition before it charges, and the payment is idempotent per lobby, so if your request times out and you click again, or if the lobby was already queued, the repeat click returns success without taking another payment. The in-game failure text states this explicitly: “Could not queue the lobby. Try again; you won’t be charged twice.”

What the charge does not guarantee: it does not make players join your lobby, and it does not fill the room for you. A queued lobby is still a lobby players have to see and choose; the queue makes you visible and well-placed, it does not manufacture demand. And it does not override the host’s own start state — if your lobby is already counting down or is about to auto-start, the queue is refused and you pay nothing, which means the charge only ever buys a slot in a lobby that is still open. Holding that distinction — visibility and placement yes, fill no — is what keeps the spend rational. You are paying to be in the right queue at the right moment with a clean position, not paying for a full lobby, so the question “is it worth it” always resolves to “is being visible in the Special queue at the next start cycle worth this much Plutonium for this lobby?”

A useful way to internalise the split is to treat the three guarantees as the part of the purchase that is fully inside your control, and the two non-guarantees as the part that is only partly inside your control. Placement, position, and billing are mechanical: the server does exactly what the confirmation text promises and no more. But whether the lobby ahead of you fills quickly, whether the queue’s current audience likes your map and modifier, and whether your own lobby converts that visibility into a full room are all downstream of choices the rest of this guide covers. The queue reliably delivers the upstream half and reliably does not deliver the downstream half, and a rational host plans for exactly that division of labour rather than hoping the purchase quietly solves the problem it never claimed to solve.

When paying to queue is the right call

There are situations where the queue purchase is clearly worth the Plutonium. The clearest is a scenario or cast lobby: a lobby you set up deliberately for a specific experience — a challenge run, a narrative session, a stream where the audience is expected to find you. These lobbies are exactly what the community’s host content points at: players who run a produced, coordinated room care most that the room actually starts with the people who came for it, and a queue slot that puts your listed room directly behind the counting-down lobby is the cleanest way to make that room findable at a predictable moment. The second is time-sensitive intent: you have a reason for this lobby to start now, in this window, with this map and this modifier — maybe you have a set of friends waiting, maybe you want to catch the current Special-queue audience before it rotates to a different modifier set. Here the value of the queue is the timing itself; listing and waiting hands that timing to the scheduler’s playlist. The third is a thin or slow hosted list: when the hosted queue is short and churning, an unqueued listed lobby may auto-start with too few people before it is ever well-seen; paying to jump into the busier Special queue is a direct way to escape a slow hosted list. In all three cases the common thread is that the lobby has a concrete reason to be in the front of the public feed at a known time, and the Plutonium buys exactly that.

The rule of thumb across these cases is: if the cost of your lobby starting empty or too late is higher than the Plutonium on the button, queue it. A scenario lobby that fails to fill is a wasted setup and a letdown for the people who came; a lobby you needed at a specific time that auto-starts early defeats the purpose; a listed room stuck in a dead hosted list is just money in the tank doing nothing. In each of those, the queue is the cheaper option against the alternative, even if the queue itself does not fill the room, because it maximises the chance that the room you built starts in front of the audience it was built for. The purchase is justified by what it protects, not by what it magically creates.

The same logic reads backwards cleanly: the queue is not justified when the lobby you want to queue has no concrete stake in the moment. If the lobby is a casual listed room with no timing, no cast, and no reason it must start at the next cycle, the Plutonium is being spent to improve a situation that does not depend on it. That is the single most common reason hosts pay and then feel the value was not there — they were trying to buy a fill that the queue never promised, rather than a placement that the queue reliably provides. So before you pay, name the specific thing the queue is protecting: a scenario you built, a timed window, a cast you need, or a slow hosted list you are escaping. If you can name it, the spend has a target; if you cannot, the free path almost certainly serves you better and the button should stay unclicked.

When listing and waiting is the better call

The opposite case is every listed lobby whose goal is simply “get into a public game that fits my setup, whenever the list produces one.” For a lobby with no hard timing, no fixed cast, and no reason to start at a specific moment, the queue purchase is a payment for something you do not need. The hosted list is small and capped — at most ten hosted lobbies at once, each on a five-minute auto-start — but it is real and it rotates, and a listed lobby that simply waits will start on schedule and give you the game you set up without spending a single Plutonium. If you are happy for the lobby to start whenever the window closes, or you are fine with the lobby being found by players who are browsing the hosted queue, listing and waiting costs nothing and the queue adds nothing you need at all, so the honest play for a casual room is to let the hosted scheduler do its job.

There is also a practical reason not to queue a lobby that is genuinely open to anyone: the Special queue is where players go for modifiers and variety, so a plain, unmodified lobby placed there competes on the exact axis it cannot win on. A queue slot that puts a standard FFA lobby right behind the counting-down modifier lobby hands it visibility, but the players in that queue are specifically hunting for the modifier that made them look at the card ahead of yours. In that situation the queue spends Plutonium to get your plain lobby in front of an audience that is filtering for something else, and the better play is to let the hosted list do its job. The decision, then, is not “queue or not queue” in the abstract — it is “does this lobby have a concrete timing, audience, or setup reason that the Special queue at the next start cycle would actually serve?” If the honest answer is no, the free path is the correct one and the queue button is there for the lobbies that do have that reason. One final reason not to queue is cost sensitivity: because the charge is per-lobby and non-refundable, a host who lists several lobbies in a session multiplies the spend, and a strategy of queuing every listed room is the fastest way to turn a visibility tool into a recurring drain. Queue the lobbies with a named stake, and let the rest take the free hosted-list path.

The cost and the risk: what Plutonium actually buys you

Because the price is set by the live server config and shown on the button, the honest way to cost this is relative, not absolute. The queue costs a fixed amount of Plutonium per listed lobby, charged once, and the amount is whatever the button displays for you at play time. Against that, weigh two things. The first is the sunk-cost character of the spend: the queue fee is not refunded if the lobby then starts empty, so the Plutonium is paid for visibility and placement regardless of the outcome, which means the only lobbies worth it are the ones where a good placement is by itself worth the amount on the button. The second is the bounded exposure: the charge is one-time per lobby, it is idempotent so a retry cannot double it, and every refusal path (already queued, already counting down, within the 30-second cutoff, not listed, not the creator, insufficient balance) costs nothing. That means the worst case is paying the button’s price for a lobby that turns out not to fill — you still got the game you built and the queue made it as visible as possible — and the best case is the queue putting a high-stakes lobby directly in front of the right audience at the next start cycle.

The risk model is therefore asymmetric in a useful way: the downside is capped at the button price and is fully understood before you click, while the upside is a real, known placement in the busier Special queue. There is no compounding cost and no repeat billing on a retry, and the game even tells you that you cannot be charged twice if the request fails. So the spend is a clean, single, bounded wager on visibility, and the rational way to make it is to treat the number on the button as a price for one placement and ask whether a good placement of this lobby at the next start cycle is worth that much. For a casual listed lobby the answer is usually no; for a scenario, a timed, or a slow-list lobby the answer can easily be yes. The Plutonium is the price of moving from “the scheduler decides when my lobby matters” to “I decide when my lobby is in front of the public feed,” and that swap is the entire value proposition of the feature.

A practical way to price it against your own session is to estimate how many Plutonium you have available for the whole session and divide that by how many lobbies you expect to list. If the queue price on the button is a sizeable fraction of your per-lobby budget, then queuing every lobby is not sustainable and you should reserve it for the lobbies with a named stake. If the price is small relative to your budget, the decision relaxes toward “queue the lobbies that benefit from timing,” but even then the free tools — the start timer and the player cap — should do the work first, and the queue should be the last lever you pull rather than the first. The point is not that the Plutonium is expensive in absolute terms; it is that it is a per-decision spend that compounds across a session, so the right habit is to make each queue click a deliberate, named decision rather than a default action you take on every listed room.

The two free levers: unlist-and-relist and the host start timer

Before spending Plutonium, a host in v0.34.18 has two free tools that solve much of the same problem, and ignoring them is the most common waste. The first is unlist and relist: a listed lobby runs on a fixed five-minute auto-start deadline, and unlisting cancels that deadline while relisting starts a fresh one. That means a host who wants to reset the clock on a listed lobby — to give a slow-filling room another full five minutes, or to re-time a room so it lines up with a better moment — can simply delist and relist at no cost. This is the free alternative to a large part of the queue’s value: if your goal is “give my listed lobby more time to fill,” relisting does it for free and repeatedly, so the queue is only worth paying for when what you need is public Special-queue visibility at the next start cycle, not just more hosted-list time.

The second free lever, new in the same v0.34.18 release, is the host-selectable start timer. When listing, the host now picks the start time — anywhere from a one-minute minimum up to the five-minute maximum — and picks the player cap, anywhere from ten to one hundred players, and that configuration is locked once the lobby is listed. A listed lobby that fills to its cap starts early, so a host who sets a lower cap gets a lobby that starts as soon as a reasonable number of people are in. These two tools change the “should I pay to queue” calculation directly: a host who can already set the start time and the cap can often make the lobby start with a good number of players without touching the public queue at all. The right move is to use the free tools first — set the start time and the cap to the size you actually want — and only pay the queue when the specific thing you need is placement in the public Special queue, which the free tools cannot provide. Using the queue to fix a timing or fill problem that relisting or the start timer would solve for free is the one mistake this feature makes easy.

The order matters more than the tools themselves. A host who reaches for the queue first is often solving a problem the free tools would have solved at zero cost, and that is the difference between a deliberate purchase and an impulsive one. The disciplined sequence is: (1) decide the start time and player cap you actually want, (2) list the lobby and let the free tools work the hosted list, (3) only if the specific thing you still need is public Special-queue placement at the next start cycle does the queue come into the picture. Step (3) is the only step that costs Plutonium, and it is the only step that the free tools cannot do. A host who internalises that sequence pays the queue exactly when the queue is the tool that does what no free tool can do, and no time before that.

Failure modes and the counter for each

The queue has a short, well-defined set of failure modes, and the game is unusually good about telling you which one you hit, so the counters are concrete. Insufficient balance is the first: if you do not have enough Plutonium for the button’s price, the queue is refused and you are not charged — the spend simply does not happen, so the counter is to top up Plutonium before you host a lobby you intend to queue, not to try and retry. The second is the lobby already starting: if your own start countdown is running, or the listing is within 30 seconds of auto-start, the queue is refused for free (the in-game text is “queue_lobby_starting”), so the counter is to queue early in the listing window, not at the last second — the 30-second cutoff is there precisely so you cannot pay for a spot the lobby would pass on its own, and respecting it means deciding to queue before the last thirty seconds. The third is a payment error in flight: if the charge itself fails, the game returns a failure and leaves the lobby unqueued, and it tells you to try again with the explicit reassurance that you will not be charged twice, so the counter is simply to retry the click rather than to assume you were billed.

There are also the eligibility refusals that cost nothing: only the lobby’s creator can queue it (anyone else gets a refusal with no charge), and a public, unlisted, or already-out-of-lobby lobby cannot be queued. These matter because they define the exact boundary of when the button is even available — listed, private, in-lobby, and you are the creator. The fourth practical failure mode is the one the mechanic does not protect you from: paying for a placement that still does not fill the room. The queue makes your lobby visible and well-placed, but it does not add players, so the counter there is the one from earlier in this guide — only queue lobbies where the placement itself is worth the Plutonium, because a lobby with no reason to be in the Special queue can be made perfectly visible and still start empty. Every one of these failure modes either costs nothing by design or is covered by a specific, stated counter, and the pattern across them is that the system refuses free wherever it can and charges exactly once when it should, which is what makes the spend safe to make.

Mode and map adjustments: making the queued lobby worth the placement

Because the queue puts your listed lobby into the Special queue specifically — the queue where players are hunting for modifiers and variety — the placement is only as good as the lobby you put in it. The most direct adjustment is to run a modifier on the queued lobby: a plain lobby inserted behind a modifier lobby loses to the modifier lobby on the axis those players are filtering for, so if you are paying for Special-queue visibility, give the lobby a modifier that actually matches what the queue is looking at. Read the modifier set the current Special lobbies are running and pick a modifier that fits that audience; the placement buys you the audience, and the modifier is what makes that audience stop on your card. If you would rather not run a modifier, that is an argument for listing and waiting in the hosted queue instead of paying for Special placement.

The second adjustment is the start timer and cap you set at listing time, because they interact directly with the queue. A lower player cap means the lobby starts sooner once enough players are in, which is what you want if you paid for a front-of-line spot and want it to convert into a started game quickly; a higher cap and a longer start window gives the queued lobby more time to draw the queue’s audience before it locks in. Pair those with a map that is currently popular or that the Special audience expects, because a queued lobby on a well-known map converts the visibility into joins faster than one on a map nobody in that queue is looking for. The point across all three adjustments is that the queue is a multiplier on a lobby you built well, not a substitute for building it well: a great lobby, right modifier, sensible cap and start time, and a queue slot is a lobby that is visible, relevant, and ready to start; a mediocre lobby with a queue slot is just a more visible mediocre lobby. The Plutonium amplifies the lobby’s own merits, so the correct play is to make the lobby worth the amplification first.

There is a sequencing point that ties these adjustments together and is easy to get wrong. Because the start time and player cap are locked the moment the lobby is listed, any mode, map, modifier, cap, or start-time change you want to make to a queued lobby requires you to unlist and relist it — and unlisting also drops the lobby out of the queue you paid to enter. So the disciplined order is: decide the modifier, the map, the cap, and the start time before you pay the queue, not after. If you queue first and then decide the map is wrong, you cannot fix it without losing the placement you just bought. Treat the queue payment as the last step in a build sequence — configure the lobby the way you want it, list it, let the free tools (start timer and cap) do their part, and only then pay for Special-queue placement on a lobby you have already made worth the spend. That single ordering rule removes most of the ways a host can waste the queue fee.

Version boundary: what is live today versus what changed just before

The version boundary here matters because v0.34.18 shipped the queue and the host start timer and the expanded hosted cap in the same release, and it is easy to read the feature set from an older build or an earlier guide and miss that the whole cluster is now live. The live build you are playing today is v0.34.18, released 2026-09-24, and in it: a host of a listed private lobby can pay Plutonium to queue it into the public Special queue, placed right behind the counting-down lobby; the charge is idempotent and every refusal is free; the 30-second cutoff before auto-start blocks the queue; the button price comes from live server config; and the same release added the host-selectable start time (one-minute minimum up to the five-minute maximum), the ten-to-one-hundred player cap, and the rule that filling to the cap starts the game early, with the configuration locked once listed. That is the current, verifiable state, and it is what every recommendation in this guide is built on — the queue, the timer, and the cap are all available now, not upcoming.

The build before it, v0.34.17, had none of this: a listed lobby ran on the fixed five-minute auto-start with no host control over the start time, the hosted cap was smaller, and there was no way at all to pay a listed lobby into the Special queue — the only option was to list and wait. If you are following a stream or a tip that describes a host picking a one-minute start or a 100-player lobby, that is now describing the live build, not the next one, because v0.34.18 is what is in your client. Keeping this boundary clean is what makes the rest of the guide reliable: the queue, the 30-second cutoff, the free unlist-and-relist, the host start timer, and the 10-100 cap are all stated for the build you are actually playing, and the one thing to confirm at play time is the Plutonium price on the button itself, because that single number is the only part of the mechanic that the server sets rather than the release fixing. Every other fact here — the placement rule, the cutoff, the free refusals, the idempotency, the timer and cap ranges — is stable in the live v0.34.18 build, which is why you can act on them without re-checking. For the wider picture of how a listed lobby appears to the players it is trying to reach, see How to Read, Filter, and Choose the Right Public Lobby and how the public Special queue schedules its lobbies in How Public Special Lobbies Work.

Related content

Continue reading
Adaptive Build Order: Spend the Next Gold on the Constraint

Use OpenFront v34.3 costs, troop growth, route payback, and stop signals to choose City, Port, Factory, defense, or a liquid reserve without copying a fixed script.