Solver engines

Engines at a glance

PulseGTO has one engine for whole Hold'em games, two for Hold'em postflop spots, and the PLO engine, which does both for pot-limit Omaha. They answer different questions, so their accuracy numbers cannot be compared directly.

Looking for the desktop software? Explore the heads-up and three-way postflop solver for your own ranges and bet sizes, or the preflop solver for custom game trees to train a whole-game blueprint. For measured comparisons, see the PulseGTO vs PioSOLVER benchmark: accuracy, time and memory.

Preflop engineRangeCFR (HU)RangeCFR (3-way)PLO engine
PurposeTrain a whole-game blueprintPostflop spot without hand abstraction, 2 playersPostflop spot from your own ranges or a blueprint node, without hand abstraction, 3 playersPot-limit Omaha: a whole-game 6-max blueprint and heads-up postflop solves
Players2–622–32–6 in the blueprint, 2 in postflop solves
StreetsPreflop to riverFlop, turn, riverFlop, turn, riverPreflop to river
HandsPreflop hand classes; postflop abstractionEvery comboEvery combo16,432 preflop hand classes; every hand in postflop solves
Board cardsCovered across trainingRemaining cards coveredFull coverage where RAM permits; reduced flop coverage when neededCovered across training; every card in turn and river re-solves
Opponent actionsSampledAllAllSampled in training; all in postflop solves
Accuracy reportedRegret bound (convergence in the abstraction)Exploitability, full best responseAverage best-response gain per player (on a sampled flop: over the sampled turns)Training deals and samples per hand class; exploitability for postflop solves
In the appPreflop SettingsRun, HU mode, RecalculateHU mode card (3 players), Recalculate on a 3-player nodePLO mode: Preflop Settings, Blueprint, Run, Re-solve, Change node

Terms used on these pages

  • No hand abstraction: every hand combination has its own strategy. RangeCFR works this way; blueprint postflop play does not.
  • Hand abstraction: a lower-detail representation that makes whole-game training practical, while limiting postflop precision.
  • Exact card removal: every combo is tracked with its two cards, so blockers between the players' hands and the board are applied exactly, not approximated.
  • Exact payoffs: the value of each showdown or fold is computed exactly (pot, side pots, rake, split pots), not estimated. By default, rake is taken from the matched pot: when a hand ends with a fold, the unmatched part of the last bet goes back to the bettor and is not raked. A blueprint configured with Rake uncalled bets uses the full pot on a fold, including the uncalled bet; its re-solves retain that rule.
  • Full enumeration of future cards: every remaining turn and river card is covered in the configured solve. Three-way flop solves do this by default when the tree fits in RAM.
  • Card sampling: only some chance cards are dealt, either per iteration or for the whole solve. The answer then has sampling error on top of convergence error.
  • Action sampling: some training paths are sampled to reduce cost. Individual iterations can therefore be noisy.
  • Convergence: CFR-type solvers approach an equilibrium over iterations; after a finite number of iterations the result is an approximate equilibrium of the game being solved. For a blueprint, that game is the abstraction.
  • Exploitability: how much a best response could win against the strategy, in % of the pot or bb/100. It measures the distance from equilibrium of the game being solved. Zero would mean an equilibrium of that game; in practice it is small but not zero.
  • EV error: how far a displayed EV is from the value in a more accurate solution. A strategy can have low measured convergence error while its displayed blueprint EVs remain approximate (see Reading EV).
  • The action tree: every engine solves only the bet sizes and raise levels in its tree. Sizes that are not in the tree are never considered, however accurate the solve.
  • Blueprint accuracy: convergence plus the error of the abstraction itself (see Accuracy & limitations).