If you’re involved in the poker world in 2019, probably you’ve heard the terms thrown around – GTO, Pio, Monker, simulations, Jesolver, Snowie.. etc. They all refer to a new category of poker software known as ‘solvers’. If you’re not sure what this means, you’ve found the right article, as today I’m going to explain exactly what a poker solver is and how they work.

Though the interfaces, capabilities and performance of the various solver softwares vary, they all do the same thing – they take a set of assumptions (also known as parameters) as input, and output a solution in the form of a game tree. Let’s break down each of these terms.

To run a poker solver you need to give it some assumptions about the situation you played. To illustrate, check out this hand I played (and lost 😀 ) a little while ago – http://hand2note.com/Hands/Hand/zozUQwuZkE2BcFGsa8v8ig%3D%3D

Was this play ok, or should I have folded somewhere? A poker solver can give us some concrete data points in our analysis of this question. First, we set up the parameters of the situation, of which there are exactly 7.

Poker Solver Input Parameters

• Out of Position Player (OOP) Range – in this case, I was the OOP player and I know exactly what hands I’d be 3betting at what frequency, so I can input this very accurately
• In Position Player (IP) Range – obviously I don’t know exactly which hands are calling my 3bet at what frequency here, but I can make some reasonable assumptions based on his open, fold to 3bet and 4bet frequency here
• Board – this I almost never get wrong 😀 – for best results we should always solve from the flop onwards, as solves starting from the turn aren’t very realistic and inputting turn ranges (with differences according to suits etc) is a nightmare manually
• Starting Pot – this one is easy, just enter how much is in the middle (the convention is to use BB= 10 chips for readability)
• Effective Stacks – how much money is behind? If one player has less than another, the lesser amount is the effective stack.
• Betting Options (for both players) – this is by far the most complicated parameter – you need to tell the solver what betting options each player has. This simplifies the game tree to a manageable size, if we allow both players to bet any amount at any stage the game tree becomes infinitely large and we can’t generate any useful results.
• Rake – this is an optional parameter, normally people run simulations without rake and then guess what effect rake will have, but running with rake can generate more useful results if you’re trying to come up with effective strategies for a particular rake environment, especially preflop and especially at smaller stakes where rake is a larger factor

Expected Value (EV) in Poker

Phew! Ok so we’ve made our assumptions about betsizing and our opponent’s range, and input all these parameters into our software, what now? If everything’s been input correctly, we can start the simulation. The solver starts with each player randomly taking actions, and assigns a number to each of these actions according to how many chips the action yielded. This number is known as the expected value, or EV. In subsequent iterations, it will increase the frequency with which each player takes the higher EV action, and decrease the frequency of lower EV actions. For example, if checking AA on the flop yields 10 chips for the OOP player, while betting yields 40 chips, the solver will iterate towards a solution where AA bets always and never checks. At the same time, if folding 33 on the flop yields the IP player 0 chips, while raising generates 100 chips, the solver will iterate towards never folding 33 as the IP player.

Similar EV’s and Frequencies

Sometimes, the solver finds that two actions generate a very similar EV. For example in the hand above, it is likely that the EV of raising JT for the IP player is very similar to the EV of calling. In this circumstance, the solver will suggest calling with some frequency and raising with some frequency. In this circumstance, the IP player can have JT on the turn after calling flop or after raising flop, making turn play much harder for the OOP player if that particular draw gets there. Lots of people get very hung up about these frequencies when they run their first few sims, worrying that they will not be able to accurately execute the precise strategy suggested by the solver. It’s important to remember that what matters is the EV of your actions, rather than getting every frequency spot on, as middling frequencies are only generated when the EV of two or more actions are the same.

Towards GTO

Typically, solvers will update the status of your simulation after each iteration – each iteration might take a very short time for situations where there isn’t much money left behind relative to the pot (such as a 3 or 4bet pot or a shortstack situation), hence a smaller game tree, or a very long time for more complicated game trees (like limped or single raised pots with deep stacks behind). The current accuracy of the simulation is expressed in terms of the exploitability of each strategy – if OOP’s strategy hasn’t had enough iterations (and therefore can be easily exploited by IP), the solver will let you know. Most solvers express this exploitability in terms of the % of the pot that either player can exploit the other player’s strategy for. As it iterates, the poker solver will get closer and closer to GTO, which is a state where neither player can change their strategy to exploit the other. Typically, professional players let simulations run to around 1% exploitability, as this is accurate enough to provide useful results and further improvement requires many more iterations.

‘typically, professional players let simulations run to around 1% exploitability, as this is accurate enough to provide useful results’

And that’s it! We’ve looked at what poker solvers are at a high/macro level and what they need to operate. Thanks for taking the time to read it, if you enjoyed the article, leave a comment or share it on your favourite social media platform.

GL out there!

D7