Theory · The project
Where This Is Going
What exists today, what is being built, and what we have decided not to build. Stages, not dates.
PokerLab AI is built around one idea: a model of how a real pool plays is more useful than an equilibrium computed against a pool that does not exist. Everything below follows from that. The explorer you can use today is the first piece; this page describes the rest, and the order it is likely to arrive in.
There are no dates here on purpose. Each stage depends on the one before it, and some depend on research questions that are not yet settled. What we can say is what comes next and roughly how large each step is.
What exists today
The range explorer: a model of one pool at one limit and format, with ranges on every street, hand classes and decision trees, exploit computation in a spot, the EV tree for a single hand, and a shareable address for any node. It runs on a shared showcase model that we maintain.
That is the foundation, and most of what follows is built on it. The engine that computes exploits is the same engine that will power hand reviews and strategy comparisons; the model format that serves the showcase pool is the same one that will serve a pool built from your own data.
What you will be able to do
Six things, in the order they were decided.
A model of your own pool
Upload hand histories from the games you play. See an estimate of how long training will take. Come back to a model of that pool, private to you, and work with it exactly as you work with the showcase model today. Keeping the model current as you add fresh data is a subscription; the model itself stays yours.
An explorer
Ranges at any point in any hand. Decision trees that show why a hand takes the line it takes. Ranges you can copy out for use elsewhere. This is the explorer, extended and rebuilt in our own interface rather than the embedded one you see today.
An exploit in any spot
Already available: ask for the best response to the field at any node. Planned: the same against a type of player rather than the pool average, once the research behind it is done.
A review of your own hands
Upload a hand or a session. See where you gave up value against the pool, by type of spot and by street, and what to focus on first. The question this answers is not "was this hand right?" but "where is your money going?"
"What if" across a whole strategy
Today the exploit answers for one decision at a time. The next step is a strategy that spans several nodes and streets: what if I limp-raise all my premium pairs, what if I stop donking flops, what changes if I size down my river bluffs. Each of these is a simulation, and its result is a comparison, not a promise.
A chat that knows the model
Ask a question in plain language. The assistant translates it into a task the model can run, tells you what it will cost and how long it will take, queues it, and explains the result when it arrives. The model does the poker; the assistant does the translation.
What we hold to
Some decisions were made early and will not change. They shape what gets built and, just as much, what does not.
- Online only. There is no downloadable tool and will not be one. The model runs on our side; you work with it through the site.
- Not for use during play. This is preparation against a real field, done away from the table. We do not support real-time use and take measures against it.
- Decision trees, not a hand trainer. We will not build a drill that asks "how do you play A7 offsuit here?" We build the tree that shows why A7 offsuit folds here and what changes when it is suited. Understanding the structure transfers; memorizing answers does not.
- Private by default. Data you upload and models built from it are visible to you alone. The only shared models are the showcase pools we prepare ourselves.
- No win-rate promises. The model ranks actions and compares strategies. It does not tell you what you will earn, and we will not pretend it can.
- As many games as possible. The method learns only from what is visible at the table, which is what makes it portable. Hold'em first; other formats, rooms and games follow.
How we get there
The product is built in vertical slices, each one usable on its own. Roughly in order:
| Stage | What it delivers | Size |
|---|---|---|
| Fast, accurate exploits | The engine behind everything paid: an answer in seconds on the turn and river, under a minute on the flop | done |
| Node addresses and sharing | A link to any spot; saved results you can send to someone | links done, saving next |
| EV tree in the explorer | Where a hand's value comes from, with a walk through the runouts | done |
| Several models, one service | A second showcase pool alongside the first; the plumbing for many models | medium |
| Task queue and account | Long computations run in the background; a personal space with your models, tasks and results | large |
| Hand history intake | Upload text histories from a room; we parse and check them | large |
| Upload to model | Your data becomes your pool model, updated as you add to it | very large |
| Our own interface | The explorer rebuilt natively, with the decision tree front and center | large |
| Hand review | "Where your money is" across a batch of hands | large |
| Chat | Questions in, priced tasks out | large |
| Billing | Subscriptions for model upkeep, credits for computation | medium |
The first stage where something is paid for comes after the task queue and billing exist, on the showcase pools, before we accept anyone else's data. The reason is simple: we want the exploit engine tested by real users on a model we control before it runs on a model built from data we have never seen.
Questions still being answered
Several stages depend on research that runs alongside the product work. These are open, and the honest answer to each is "we are measuring".
- How much data is enough? A pool model from a large mining dump is one thing. A model from a single player's database, or from a modest sample, is another. Before we accept uploads we need to know what we can promise at a given volume, and what we cannot.
- Does the method transfer? The current model is built on one room and one table format. Moving to a second room means new data, a new parser, and a check that the approach holds when the game structure changes.
- Is the hand review valid? A report that says "you lose value in these spots" has to be tested against players whose results we already know. Early results are encouraging; that is not the same as done.
- Exploiting a player type, not just the pool. The model today is the pool as a whole. A view of winning regulars, and of other player types, is planned: first as a description of how they play the same spots, later as a model you can compute a best response against. Both are separate research questions.
Progress on each of these is what moves the stages above from planned to built. When one of them is settled, the corresponding stage follows.
Questions left? See the FAQ.