\"How many slots?\" looks like a vanity question and is actually a design decision that touches gameplay, bandwidth, and CPU all at once. A 32-slot server on de_dust2 is chaos; a 12-slot zombie server dies of boredom. CS 1.6 caps you at 32, but the right number is almost always lower than the maximum, and picking it well is the difference between a server that feels good and one that feels like a scrum. Here is how to reason about it.
Maximum players is fixed at launch, not in server.cfg. It is the maxplayers value on the command line (or +maxplayers), and it cannot exceed 32:
./hlds_run -game cstrike +ip 0.0.0.0 -port 27015 \ +map de_dust2 +maxplayers 20
Changing it requires a restart — you cannot raise slots on a running server. If you reserve slots for admins with adminslots.amxx, those come out of this total: 20 slots with 2 reserved means 18 public slots and 2 held for admins.
The map decides how many players is fun, more than anything else:
| Content | Comfortable range | Why |
|---|---|---|
| Classic de_/cs_ (dust2, inferno) | 12–20 | Designed around ~5v5 to 10v10; more turns chokepoints into meat grinders. |
| Popular 24/7 single map | 18–24 | Enough for constant action without total spawn chaos. |
| Zombie / fun / surf / deathrun | 24–32 | Chaos is the point; big lobbies feel alive. |
| Competitive / PUG | 10–12 | Strict 5v5 plus a spectator slot or two. |
Putting 32 players on a tight defusal map does not make it more popular — it makes rounds a spawn-to-death lottery, and good players leave. Big counts belong on maps and modes built for them.
Each occupied slot consumes upstream bandwidth bounded by sv_maxrate. A rough ceiling for a full server is slots × sv_maxrate:
32 slots x 25000 bytes/s = 800,000 bytes/s
~= 6.4 Mbit/s upstream at peak
That is the worst case, but you must have the headroom or players choke. If your uplink cannot sustain the full-server rate, either lower the slot count or lower sv_maxrate — and lowering the rate degrades everyone's feel. Bandwidth is usually the real constraint on a home or budget host, not CPU. See the rate cvars in the essential cvars list.
More players means more entities, more traffic, and more work per tick, which pushes down your effective server FPS. A server that holds a steady high FPS at 16 players may sag at 32, and once FPS drops below your sv_maxupdaterate everyone gets choke on the scoreboard regardless of their own connection (see choke and loss and the sys_ticrate truth). Plugin load compounds this: a heavy zombie or stats setup at 32 slots needs real CPU. Size slots to what your box can actually push at a stable frame rate, not to the theoretical cap.
An empty 32-slot server looks more dead than an empty 16-slot one — \"3/32\" reads as a ghost town, \"3/16\" reads as a server warming up. Servers fill from a seed of players, and a smaller cap crosses the \"looks active\" threshold sooner. A practical pattern for a new server is to start smaller (16–20) so it appears busy, then raise the cap once you have a regular crowd that fills it. You can always add slots later; you cannot un-see an empty 4/32.
sv_maxupdaterate under load. Fewer slots, more CPU, or a lower update rate.sv_maxrate exceeds your bandwidth. Reduce one of them.maxplayers is fixed at launch. Plan it, because changing it needs a restart.adminslots.amxx and set the reserve count.Confirm the running slot count and then watch performance at load. The maxplayers value shows in the server console and in status:
status // hostname, players : X (20 max) -- confirms the cap
Fill the server (or use bots to simulate load) and watch server FPS with stats in the console. If FPS stays above your update rate and no one chokes, the count suits your hardware; if FPS sags, you are over-slotted for the box and should scale back. Set rates deliberately alongside this — see the essential cvars reference.