A solver and a model of the field are not competing answers to the same question. They are answers to two different questions, and most of the confusion about which one to trust comes from not noticing which question is on the table. This article is about telling them apart.

Two questions

A solver asks: given a game tree and an opponent who plays it as well as possible, what strategy cannot be beaten? The answer is an equilibrium. It is a property of the game, not of any particular pool, and it does not change depending on who is sitting across from you.

The model asks: given this pool, playing this limit in this format, what do they actually do in this spot, and what is the best response to that? The answer is a description of specific people and a strategy against them. It changes from pool to pool, and it would be wrong if applied to a different one.

Both questions are legitimate. Both answers are correct for what they ask. The mistake is using one where the other was needed.

	Solver	Model of the field
Opponent	Plays the game perfectly	Plays the way the data says this pool plays
Output	A strategy that cannot be exploited	A strategy that exploits this pool
Depends on	The rules and the tree	The pool, the limit, the format
Wrong when	The opponent is far from equilibrium	The opponent is not from this pool

Where a solver is the right tool

There are situations where the model has nothing to say and a solver does.

An unknown pool. If you are sitting down in a game you have no data on, a model built from a different pool is a guess dressed up as a measurement. The equilibrium is at least correct against any opponent, and it is the sensible baseline until you know who you are playing.

Checking your own balance. If you suspect a line of yours is exploitable, a solver will tell you exactly how. That is a question about your strategy against a perfect opponent, which is what a solver computes. The model cannot answer it, because the model's opponent is not perfect.

Understanding the structure of a spot. Equilibrium strategies reveal things about the game that no pool's play will show you: which hands are natural bluffs on a texture, why a bet size is tied to a range's polarity, how blockers move a decision. This is theory in the proper sense, and it transfers across pools because it is about the game rather than the players.

Opponents who adjust. Against a small number of strong, attentive players, an exploit computed against the pool average is an exploit against people who are not at your table. Equilibrium is the defensive position; how far to move from it against these specific opponents is a judgment the model informs but cannot make.

Where the model is the right tool

And there are questions a solver cannot address at all, because they are about the players.

Where the money is. A solver tells you what is balanced. It cannot tell you that this pool folds too much to a one-third bet on low paired boards, because nothing in the game tree says so; only the pool says so. Finding the spots where the field is weak is exactly what the model is built for.

The spots the solver never reached. A meaningful share of the situations that occur in a real game are absent from the solved trees people study: multiway pots, limped pots, unusual sizes, lines nobody would take at equilibrium but that the field takes all the time. The model has a range for every one of them, because the pool played every one of them.

The cost of a deviation. If the field opens wider than equilibrium, a solver's defense against that open is wrong in a way you cannot quantify from the solver. The model gives you the actual opening range and the best response to it, and the comparison line tells you what the deviation is worth.

"What if" questions. What if I stop donking? What if I bluff the river smaller? A solver can answer "what if" only against a perfect opponent, which turns every deviation into a loss. The model answers against the pool, which is where the question actually lives.

On locking ranges

Most solvers let you fix an opponent's range or strategy at a node and solve from there. This is the closest a solver comes to modeling a pool, and it is worth being precise about what it does and does not give you.

Two things stay the same after the lock. First, the locked range is whatever you typed in, and where it came from is your problem. If it is an estimate from your own experience, it carries whatever bias your experience has. Second, everything downstream of the lock is still solved to equilibrium: the opponent below the locked node plays perfectly, and your own strategy below it is balanced against that perfect play, not exploitative against the pool.

So a locked solve answers: "if the opponent arrives here with this range and then plays perfectly, what should I do?" That is a useful question in some spots. It is not the same question as "what does the pool do from here, and how do I take advantage of it?" The model answers the second one, with ranges measured from data rather than typed in, and with the pool continuing to play like the pool at every node below.

Using both

The practical arrangement is not to choose one tool but to know which one each question belongs to.

• Learn the structure of a spot from the solver: which hands do what, and why, in a vacuum.
• Learn what the pool actually does in that spot from the model.
• Use the exploit view to measure the gap between the two, and the comparison line to see how much of that gap winning players have already closed.
• Use the solver again when you want to check what you have opened up by deviating, and decide whether the pool at your table is likely to find it.

Seen this way, the solver is the map of the game and the model is the map of the people. You need the first to read the second, and the second to know where on the first the money is.