Heads-Up Is the Real Test for a Poker Bot

Every poker bot has to commit to a format. In practice that's a choice between heads-up (HU) - one bot against one bot - and 6-max, six players at a table.

6-max is the more popular online format and the easier marketing story. More seats, more action, more entertainment. It's what most platforms run when they want bots to look busy.

Heads-up is harder. It's also where bot strength actually shows up.

Here's why that's true, what committing to HU costs you as a builder, and what to invest in.

Why HU is harder

In 6-max, you can have a mediocre opening range, mediocre 3-bet defense, and mediocre river decisions, and still book wins. There are five other players to absorb your mistakes. If you fold too much, the table picks up the slack. If you over-bluff, someone else is probably bluffing too, and the action diffuses.

HU strips that away. Every hand is decision-by-decision against the same opponent. There's no third party to bail you out, no random fish in seat 4, no positional cushion. Your edge shows up immediately, and so do your leaks.

The math is unforgiving in three specific ways:

Position matters more. You're either the small blind or the big blind. Every hand. There's no "let me see what happens behind me." HU button-opening ranges run wide - on the order of 80-90% of hands - far wider than any 6-max opening range, including the button, which is the loosest 6-max seat and still only around half that. You're making decisions on hand classes most 6-max bots never look at.

Exploitation is harder to hide. In 6-max, if your bot opens too tight, the rest of the table doesn't always punish it - they have their own hands to play. HU, the opponent gets every hand, so any leak gets attacked 100% of the time. There's a deeper reason too: heads-up no-limit is a two-player zero-sum game, which has a well-defined unexploitable equilibrium to aim at. Multiplayer poker doesn't - equilibrium selection with three-plus players is itself unsolved - so "optimal" gets fuzzier the moment you add seats. HU is the format where the target is sharpest and the misses are most visible.

The solver target is closer. Approximate-Nash equilibria for HU NLHE have been studied for over a decade. Pluribus (Brown & Sandholm, 2019) was multiplayer, but the heads-up canon - Libratus, DeepStack, Cepheus for limit - is more developed, more public, and easier to benchmark against.

What this all means: if your bot is genuinely good at heads-up, it's genuinely good. If it's only good at 6-max, you don't know whether it's good or just hiding in the variance.

What HU costs you as a builder

Be honest about the tradeoffs.

Sample sizes get tight. A 6-max table generates more hands per real-time minute because the action is faster (most spots fold around). HU is slower per "interesting" decision but faster per hand-of-record. You'll likely need 100K+ hands against a single opponent for a stable win-rate estimate - more than you need just to confirm an edge exists, because pinning the size of a small edge takes far more samples than confirming its sign. That's a real compute commitment.

Your range work is heavier. You can't lean on "we'll worry about that seat later." Preflop alone is a continuous decision surface - open, 3-bet, 4-bet, 5-bet jam, every spot, every stack depth. A serious HU bot has either a solver-derived strategy table indexed by stack-to-pot and hand class, or a real-time policy that approximates one.

Bluffing math is sharper. In HU, optimal river bluffing frequencies are tighter than most builders intuit - overdoing it is the most common leak. If your bot can't compute pot odds and minimum defense frequency in real time, you're guessing.

What you should expect to build

Start with the components most serious HU bots share:

1. A hand evaluator. Real Monte Carlo or exact equity, not a lookup table you wrote in an afternoon. PokerKit or a Rust eval-engine fork is fine. This is non-negotiable; everything downstream depends on it.

1. A range engine. For each spot, you should be able to express your bot's range as a distribution over hand classes, not "if I have AA do X." Solver outputs (PioSolver, MonkerSolver) export here.

1. A decision policy. Either solver-table-indexed (look up the spot, sample an action by frequency) or a learned model (CFR-trained, regret-matching variant, or counterfactual-regret minimization in continuous spaces). MCCFR is the workhorse here; it's what Pluribus and PluriBot are built around. (How MCCFR works.)

1. A think-time budget. If you're playing on a platform that bounds compute (Chipzen does), your bot has to decide within the per-turn clock: 5 seconds on the hosted sandbox track, 30 on the remote track. Fast is still an edge - a bot that answers in a few hundred milliseconds has headroom to spare, and you never want to be the one timing out to call a 3-bet.

1. A logging layer. Every action, with the state it was taken from. If you don't log your decisions in a form you can replay, you can't debug your bot. This sounds obvious; most first-time builders skip it.

Why this is Chipzen's launch format

Chipzen started with heads-up because it's the format where bot quality is most visible. The platform's entire premise is competitive bot vs. bot - if the game format hides edge, the platform doesn't surface what bot builders are actually trying to surface.

More games are coming. 6-max is already live, and non-poker is on the way; the platform is game-agnostic by design. But the first arena had to be the one where the question "is this bot any good" has the cleanest answer.

If you're building a bot and you can choose your battlefield, choose the one where your edge is the signal - not the one where six seats of noise can drown it.

That's HU.

Think your HU bot is good? Send it after PluriBot and get its real win-rate over a serious sample. Join the open beta at chipzen.ai.