Node locking in Postflopizer GTO Solver
Contents
- How to node lock a hand
- The adjustment sometimes happens on another part of the game tree
- The solver will play perfectly after the lock
- Locking further nodes
- The solver will rarely balance
- EV differences
- Conclusion
An article by Barry Carter
One of the biggest criticisms of Game Theory Optimal play is that it doesn’t reflect real life games. Most players do not play like Stephen Chidwick or Jason Koon, so trying to replicate how they play seems pointless at low stakes online or in soft live games.
GTO Solvers like Postflopizer show you much more than just how to play against a GTO opponent. They can also show you how to play when your opponent has a clearly identifiable leak like calling or folding too much. This is because of a feature called ‘node locking’.
A ‘node’ is just a decision point in a poker hand. To ‘node lock’ simply means to manually intervene and tell the solver how to act on that node.
If the solver bets a lot on a node, but you think a real life opponent would check, when you node lock you tell the solver to check instead. It will then recalculate how it should play based on this new information.
Before Postflopizer node locking was quite difficult. I personally found the process of node locking needlessly complicated using PioSolver. Thankfully I was given early access to Postflopizer and without it, I would not have been able to write my latest book Beyond GTO: Poker Exploits Simplified, which is essentially a book on node locking. Node locking really does take seconds in Postflopizer.
How to node lock a hand
To node lock a hand, you run the simulation first to get the GTO solution. It’s very important to also pay attention to the GTO solution rather than skip past it. The best way to learn is to first understand the fundamentals and then to discover what happens when your opponent deviates from the baseline strategy.
For example, in this hand we have 50BBs effective. UTG (OOP) has opened, the Button (IP) has 3-bet, and UTG has called.
The flop is 8♣7♣6♥. These are the ranges:
In GTO Solver World, OOP leads out a lot here:
This is a flop where range advantage shifts in favour of the preflop defender. OOP has all the sets, straights, some overpairs and lots of strong draws like 89s.
As such, when they check, this is what IP does:
Despite having position and a stronger preflop range, IP checks back 41% of the time, recognising that OOP has range advantage.
But what if we think that IP does not understand this concept and board texture? What if we think they are a typical player who thinks they should c-bet 100% of the time when they have raised preflop?
We click the ‘Edit Strategy’ button and this is what we see:
You simply click on the bet size you want to change the strategy to, then click on either the individual hands on the left, or the hand classes on the right, to change the strategy. So you can make AA bet 3.8 or you can make all overpairs bet 3.88, for example. Or you can select some of the prefilled mixed strategies, or make your own. When you pick, for example, a 50/50 mix of check and bet 3.8 for a hand or hand class, Postflopizer will decide how that is split up between the specific hands in that class.
Here we have made the IP player bet 3.8BBs with every hand.
We have selected ‘Unlock Previous Action’, which means that we will allow the solver to adjust the previous action if it wants. If, however, you want the previous action to remain as it was change this to ‘Lock Previous Action’. As a general rule, it is better to keep the previous action locked because it will usually reflect how the hand was played, but you will see in a moment why it is useful to do the opposite.
You then click ‘Apply & Calculate’ and re-run the hand with this new information.
The adjustment sometimes happens on another part of the game tree
The first thing to know after a node lock is that sometimes how you adjust is most significant on a separate branch of the game tree. Here is a classic example.
As we saw, the OOP player lead out 83% of the time in the GTO example. When OOP checked, IP checked back 41% of the time.
After we node-locked to make IP c-bet 100% of the time, this is OOP’s first action:
They have gone from leading 81% of the time to checking 100% of the time.
One of the reasons why OOP leads so much on an 8♣7♣6♥ flop is because if they didn’t, IP would check back a lot. However, when it is guaranteed that they will bet, OOP prefers to check and let them do it. This is often to set up a check/raise.
This highlights two important things about node locking.
First of all, the adjustment sometimes comes before the mistake is made. You will see the opposite of this too. If a player doesn’t c-bet enough, the OOP will often start to lead when they normally would check to ensure money goes into the pot.
Secondly, when a player makes an error on one part of the game tree, the solver will make an effort to force them into that part of the game tree. Here IP is making a c-betting error, so Postflopizer has forced them into the c-betting part of the tree by checking.
The solver will play perfectly after the lock
IP has made a big error by c-betting too much, and this is what OOP does when they do c-bet on the flop:
OOP exploits the error by check/raising almost everything in its range. Just for context, this is what happens in GTO Solver world when it goes check/bet:
OOP has gone from raising 23.8% of the time in GTO World, to raising 78.5% of the time when IP bets too much. This is a massive strategic adjustment. OOP will print money with both bluffs and value by doing this. This is because IP is unbalanced. They do not have enough strong hands in their range to justify betting all of them, so OOP can exploit them with the much stronger range.
This is what happens when OOP raises:
Although IP’s c-betting range was unbalanced, notice that their response to the check/raise is much more balanced. The value hands that raise are overpairs and are balanced out with mostly Tx and 9x bluffs. The calling range is balanced with AA, sets, some draws and some bluff catchers like AKo.
In real life a player who c-bets too much on this flop is likely not going to be this balanced when facing a raise. This is a very important consideration with node locking. After you force the solver to make a mistake, it will play as close to perfect as possible afterwards to try and compensate for it.
This means you have two options when node locking.
- Takeaway broad heuristics: Here we can broadly say that the response to players who c-bet too much is to check/raise them a lot.
- Do further node locks to get a more accurate picture: If we think we know how our opponent plays on further streets, we can node lock again to reflect that
Locking further nodes
Let’s say we think our opponent will not be as balanced facing a check/raise. In fact, we think they will shove all their top pair or better hands, call with their draws, and fold everything else. So they never bluff, essentially. We simply repeat the node locking process once again:
Now we can go back a step, this is the new OOP response when IP c-bets 100%:
In GTO Solver World, OOP raised 23.8% of the time. In our previous node lock they raised 78.5% of the time. Now, with the additional information that IP gets all their value in, but never bluffs, OOP check/raises 100% of the time.
This might surprise people that they raise more when IP has such a strong raising range. The reason we increase our check/raise frequency is because we are no longer worried about IP bluffing us off our hand. A general trend you will see when node locking is that the solver hates being raised as a bluff. It will take steps to avoid this happening. We increase our betting frequency here because we will never be folded off our hand when we are ahead, and we are also ahead of the raising range a lot of the time.
The solver will rarely balance
Let’s go back a step or two. A reminder that this is the GTO response when it goes check/bet:
In GTO World most hands mix. AA, for example, is close to 50/50 check or bet. This is so OOP can have a strong overpair in both scenarios. Most of the draws mix for the same reasons. Some outlier hands choose one action over the other. T9s is the nuts, so it calls because it is not worried about being outdrawn. The sets all raise because they are strong but vulnerable. They want to get the money in while they are likely ahead.
This is the first node locked response when IP bets too much (before we adjusted their response to the check/raise):
We have talked about how IP was unbalanced. Ironically, the response to this is also to be less balanced.
There is much less mixing in this range. AA mostly gets the money in, T9s always gets the money in, and the strong draws mostly get the money in.
When your opponent is not worried about balance, you don’t have to be either. When your opponent is exploitable, the way to make money against them is to counter-exploit.
EV differences
A final habit to get into when node locking hands is to compare the EVs in both the GTO and node locked solves. You can do this a number of ways in Postflopizer, but the easiest way is on the Results Analysis screen. This is the GTO example:
And this is after our second node lock:
In GTO World OOP makes 8.78 BBs on average. When we make IP bet too much and then not bluff when check/raised, OOP makes 11.91 BBs on average.
That is a 3.13 BB mistake, which over a large sample is a 313 BB/100 error. This is a gargantuan error over the long term, one which would see you go broke if you continued to make it. In reality, you might make this error, but your opponents would make similar errors in other spots that balance it out. But this is still an error where fixing it would hugely improve your bottom line.
You can also look at the EV of errors on the specific node they are made.
For example, in GTO World when checked to, the 3.8BB bet from IP makes 9.99 BBs on average:
This is because they are betting with a strong balanced range.
Betting 3.8 BBs in the node locked example makes just 3.09 BBs on average:
Again, the difference between GTO World and the node-locked example is 6.9 BBs, or 690 BB/100 over a large sample. It is truly haemorrhaging money.
It’s really important to compare EV between GTO and node locked examples because it puts a number on how costly some errors are. You will find that some errors are not actually that bad and others are terrible. Broadly speaking, players who are too tight tend to have the most costly errors long term which might surprise some people, because of opportunity cost.
Conclusion
The GTO solution should always be your first port of call. You cannot truly understand how to exploit an opponent until you first know the baseline strategy that you are deviating from.
However, when you have developed a reliable read on your opponent, or a whole player population, node locking will vastly improve your winrate.
You can never perfectly node lock a hand because that would require you to look at all possible bet sizes, on all possible turn and river runouts. Once you have locked for the clear-cut leaks of a player, it’s much more useful to look at the broad adjustments rather than getting into the weeds with specific details. That way you can develop heuristics that work in lots of situations. From this one hand example we might suggest the following heuristics:
- If a player doesn’t c-bet much, lead into them
- If a player c-bets too much, check/raise them a lot
- If a player doesn’t bluff raise often, you can bet against them with a much wider range
- If a player is making a clear mistake, tailor your actions to get onto the part of the game tree where they make that mistake
Beyond that, experiment with node locking. If your opponent called too much, after you have reviewed that hand, run it again for if they folded too much, or raised too much, or only raised as a bluff and called with the nuts, or vice versa. As we have stated in previous articles the way to get the most from Postflopizer is to follow your curiosity.