No. PokerLab AI is a study tool and is not intended for use during play. We do not recommend it, and we take measures to prevent it.

It is also not designed for it. A single exploit takes seconds on a river and up to a minute or more on a flop, requests are queued one at a time, and each account has a rate limit. The tool is built for working through spots away from the table.

Real hands, in large volume, from a single limit and format. Each model describes one pool: the players of that limit in that room, the way they actually play. There is no "poker in general" model, because pools differ, and a model of one would not describe another.

No. Nothing from a solver goes into the model. It learns only from what is visible at the table: the actions everybody sees, and the cards that get shown at showdown. If the pool does something a solver would never do, the model learns the pool's version, because that is what the data shows.

No. Training reads the hands and produces a model of how the pool behaves. The model contains patterns, not hands. You cannot get a hand history back out of it.

You cannot know for any single hand. But across a large volume you can estimate it, and estimate it well. The model treats every unseen hand as a distribution over all possible holdings, weighted by what the player did along the way. The hands that do reach showdown anchor those weights to reality. The full explanation is in How We Reconstruct Hands Nobody Showed.

On hands it has never seen. Part of the data is set aside before training and used only for testing. On those hands we check three things: whether the model predicts the actions players actually took, whether it predicts the cards players actually showed at showdown, and whether the money it expects a strategy to make matches what that strategy made in the data.

The showdown check is the important one. The model sees only the actions, never the cards, and has to say what the player is likely holding. Getting that right requires understanding which hands take which lines, not just knowing how often players bet.

The full set of metrics and what each one measures is described in How the Model Is Tested.

No, and it is not presented as such. Every version is measured against the same held-out data, and a new version is adopted only if it does at least as well as the previous one across the board. Some spots are modeled better than others. Where the model is weaker, that is known and being worked on, not hidden.

We do not promise a win rate. What the tool gives you is a ranking of your options in a spot, against a model of how your pool actually plays, and a way to compare strategies without paying for the comparison at the table. How that translates into results depends on how you use it.

Yes, eventually. The exploit is a best response to a field that plays the way the data says it plays and does not adjust to you. Think of it as the answer for your first hand at a table where nobody knows you. It is a ceiling and a diagnostic, not a script. Knowing the maximum exploit is how you find out which parts of it are worth keeping once people start paying attention.

Because it is computed, not looked up. When you press the button, the model plays out the rest of the hand from that point: every holding you could have, every response the pool could make, every card that could come. On the river that is quick. On the turn it takes seconds to tens of seconds. On the flop the full tree is too large to walk exactly in reasonable time, so the model uses a trained estimate for the deepest part of it; the cost of that approximation is small and is measured.

We chose accuracy over speed on purpose. A study tool can afford to think for a minute, and a faster answer would have to be a less precise one.

Exploits are heavy, and at the moment they run one at a time. If someone is ahead of you, the button tells you your place in line and roughly how long until your turn. Results are cached: a spot that has been computed once opens instantly for everyone afterward.

The service is not yet running at its planned capacity. Additional computing power will be added once the business model is settled and we know what load to provision for. Until then, expect the queue to be noticeable at busy times.

At the current stage there is a per-minute cap on requests, set high enough that ordinary study should not reach it. Range lookups do not use credits. Exploits and EV trees are queued rather than metered. Limits will be revisited together with capacity once the business model is settled; if you run into one during normal use, let us know.

A solver answers "what is balanced here against a perfect opponent?" The field is not a perfect opponent. The model answers "what does this pool actually do here, and what is the best response to it?" Those are different questions with different answers, and only the second one is about the game you are in.

That helps, but two things remain. The locked ranges are your own estimate rather than a measurement, and from the locked point onward the solver still builds a balanced strategy, not an exploiting one. The model provides both: ranges taken from data, and the best response to them.

No. Equilibrium is correct; it is an answer to a different question than the one you face against a specific pool. It is worth understanding as a baseline, and there are situations, a completely unknown pool, for instance, where it is the only sensible starting point. Most of the time you are not in that situation.

That is the field view: the pool as a whole does different things with the same hand, so you see a mix. Switch to the exploit view and there are no mixes. Against a fixed model of the pool, one action is best for each hand, and that is the one shown.

The method is described in the theory articles at the level of principle: what the model learns from, how it reconstructs unseen hands, how it is tested, and what an exploit means. The specific construction of the model is not published.

Each model is built for one limit and one format, and describes that pool only. The method is the same for any of them; what changes is the data. The current release covers no-limit hold'em. More rooms, limits and formats are planned, and other games, including PLO, will follow.

Not quite. Winning players are a minority of the pool and a mix of styles, so the field range is not their range. The explorer today shows the pool as a whole; a separate view of winning regulars is planned, and even then it will be a description of a broad group, not a target to copy.