Poker HUD stats freeze when the table caps at 4 seats

Poker HUD stats freeze when a table caps at 4 seats. If you've ever watched your VPIP and PFR numbers stop updating the moment a six-max table breaks down to four players, that isn't a display lag or a database hiccup — it's a structural mismatch between how the HUD engine counts seats and how the room reports them. The stats you see on screen aren't wrong, exactly; they're just frozen at whatever they were when the fifth and sixth seats emptied, and they'll stay that way until the table fills back up or you close the session.

That distinction matters because a frozen HUD doesn't announce itself. The numbers keep sitting there in their little coloured boxes, looking authoritative, while the underlying hand history has moved on without them. A player who trusts those numbers at a four-handed table is making decisions on data that describes a game that no longer exists.

Why the freeze happens

Most HUD software works by mapping a table's seat coordinates to a position model. The engine asks the room, via the client's window structure or the hand history file, "how many seats are at this table?" and then assigns positions — UTG, HJ, CO, BTN, SB, BB — against that seat count. The stat aggregation layer then filters your opponent's historical hands to those played from the same position at the same table size.

When a six-max table breaks to four, three things can go wrong, and usually at least one does.

The seat count doesn't update. The room's client may keep reporting a six-seat table structure even after two players leave, because the physical table object still has six seat slots — two of them just happen to be empty. The HUD reads "6" and keeps filtering for six-max hands. Your opponent's four-handed button range, which is dramatically wider than their six-max button range, never gets pulled into the sample.

The position mapping collapses. Some engines handle the seat reduction but re-map positions incorrectly. The player who was in the cutoff at six-handed becomes the button at four-handed, but the HUD keeps tagging their hands as cutoff hands. You end up comparing a four-handed button range against six-handed cutoff data, which is roughly as useful as comparing a short stack's shoving range to a deep-stacked flatting range.

The hand history parser stops mid-session. This is the nastiest version. The parser reads the table name, sees it's the same table it's been tracking, and applies its cached seat count. New hands get imported — your database grows — but the HUD's on-screen filter doesn't refresh because the table identity hasn't changed. The stats are stale, not because the data is missing, but because the query never re-ran.

The practical symptom is consistent: your opponent's sample size stops climbing, or climbs far more slowly than the hands you're actually playing. If you've played 40 hands against someone at a broken table and their HUD still shows 120 hands, the freeze is live.

What the frozen numbers actually look like

A frozen HUD doesn't display obviously broken data. It displays plausible data, which is worse.

Take a regular who plays 24/19 at six-max — a 24% VPIP, 19% PFR. Their true four-handed ranges are wider, maybe 32/27, because the blinds come around 50% more often per orbit and there's less multiway incentive to tighten up. If your HUD freezes on their six-max sample, you'll see 24/19 and read them as tighter than they are. You'll fold hands that are actually profitable against their real range, and you'll give their four-handed raises more credit than they deserve.

The reverse happens too. A player who was running hot at six-max with a 35/30 over a small sample gets frozen there, and you'll over-adjust by three-betting lighter than their true four-handed tendencies warrant.

The sample-size problem compounds it. At a four-handed table, hands come around roughly 1.5× faster per player than at six-max — you see about 50% more orbits per hundred hands dealt. A HUD frozen at 100 hands of six-max data is effectively showing you data from a game where your opponent has seen 33% fewer button opportunities than they would have at four-handed. The confidence intervals you'd normally apply to a 100-hand sample are wrong by a meaningful margin.

The 4-seat threshold specifically

Four seats is the awkward number. Two- and three-handed play triggers most HUDs' heads-up and short-handed profiles correctly, because those table sizes are common enough that developers tested them. Five- and six-handed are the default. Four-handed falls into a gap: it's short-handed enough that position ranges shift substantially, but not short-handed enough to trip the "this is basically heads-up" logic that many engines use.

There's a concrete way to check whether your setup is affected. Pick a table that's broken from six to four and watch a single opponent's hand count over the next 20 hands. If the count increases by fewer than 20, your HUD is under-counting. If it doesn't move at all, the filter is frozen entirely. Do this once per session for a week and you'll know whether your specific room and HUD combination has the bug — it's room-dependent, because the seat-count reporting is handled differently by different clients, and HUD-version-dependent, because several vendors patched it at different times over the past few years.

The fix, where one exists, is usually to force a table re-detection: close and reopen the table window, or restart the HUD's table manager. That re-runs the seat-count query and re-filters the stats. It's a workaround, not a solution, and it costs you a hand or two of attention every time a table breaks.

What it means for your reads

The deeper issue is that a frozen HUD teaches you to trust a number that describes a different game. Positional stats are the most sensitive to table size of any HUD metric — far more than overall VPIP or three-bet percentage, which shift but less dramatically. If you're relying on positional breakdowns at four-handed tables, you're relying on the exact stats most likely to be wrong.

The defensive move is to weight your own observation more heavily than the HUD when a table drops to four. Watch how often the player in the cutoff opens, how they respond to a three-bet from the blinds, whether they defend their big blind as wide as their six-max numbers suggest. Twenty hands of direct observation at four-handed is worth more than 200 hands of frozen six-max data, because it's data from the game you're actually playing.

And if you play a lot of short-handed, it's worth testing whether your HUD vendor has addressed the four-seat case at all — or whether you're the one running the re-detection every time a table breaks.

The open question is whether this stays a user-side workaround or becomes something rooms fix at the source. Seat-count reporting is a client-side detail that rooms have little incentive to standardise, and HUD vendors have little leverage to demand it. Until one side moves, the four-seat freeze will keep quietly distorting reads for anyone who doesn't know to look for it — and the players who don't know are the ones it costs the most.