How our solves are tested

1 · Match their game, exactly

We solved the same game a commercial MonkerSolver pack was solved on — every action and bet size at every depth, 20,223 distinct action paths at 100bb — so our ranges and theirs are compared like for like. An automated check confirms our tree matches the reference pack's exactly: zero mismatched paths and zero size deviations.

2 · Match their abstraction, match their answers

We solved that identical game with equity-distribution bucketing at MonkerSolver-class resolution (1,024 buckets per street) and required every non-blind position to land within ±3 points of the reference pack. At 20bb, 6-max, under the reference's own rake structure:

Configured to think the way MonkerSolver thinks, our engine reproduces MonkerSolver's answers — validating tree handling, equity evaluation, multiway and side-pot logic, and convergence end to end. Terminal payouts are separately verified against brute-force enumeration; heads-up convergence matches published benchmarks.

3 · Where our ranges differ, and what we don't yet claim

Solved card-exact on the same tree, our ranges come out 2–4 points tighter than the reference, concentrated in offsuit broadway hands (AJo, KJo, A9o) that Monker-derived packs open from early position and exact play folds. Turning bucketing on in our own solver brings those hands back, which shows the difference tracks card abstraction rather than a bug.

We do not claim this makes our ranges more profitable. The reference solver publishes its own EV for these hands, and by that accounting the marginal hands where we differ are priced at or near break-even — so opening them is not obviously an error. An EV-weighted comparison against those published values does not favour us. We investigated why: it is not solve convergence (the gap barely moves from 250 to 1,000 iterations) and it is not postflop tree depth (widening the postflop betting menu barely moves it either). It comes down to a genuine disagreement between an exact solver and a bucketed one on a handful of indifferent hands — and it cannot be settled without an unbiased full-game EV that neither solver can currently produce (theirs is bucketed; ours carries a known multiway approximation). So we make a correctness and transparency claim, not a profit claim. What is established is above: an identical game tree, and a matched-abstraction gate our solver passes at every non-blind position.

Honest disclosure: the small blind

SB first-in is the one spot we don't claim to match anyone, in either mode. Limping, min-raising and folding are nearly EV-equivalent for wide bands of hands there, and published solutions from every vendor disagree by 10+ points. Treat SB first-in charts — ours and everyone's — as one defensible equilibrium among several.

How the tournament packs are produced

9-max, big-blind ante, 10–100bb, bet sizings published per pack. Solved card-exact by GPU vector CFR — 128 full boards per iteration, 500+ regret-matching⁺ iterations, sharded across four data-center GPUs per solve. No rake (tournament chip EV), antes modeled as invested chips. Every pack is reproducible from a committed configuration, using the same code that produced the tables above.

The differences at a glance