Every GTO training app asks you for the same leap of faith: trust that the numbers behind the charts were solved correctly. You should not have to take that on faith. GTO solver accuracy is measurable, the assumptions behind a solution (antes, rake, stack depths, payout structures) are checkable, and any product asking for your money should put both on the table.
This post exists because players keep asking us a fair question: where can I read about the solutions in the app? This is that page. It covers what the library contains (tournaments first, since that is what most people ask about), the game conditions every spot is solved under, and the verification each solution passes before it ships. A few implementation details stay private, and we explain exactly why. Everything a player needs to judge the data is here.
Why Solution Quality Is the Whole Product
A solver's output is judged by exploitability: how much a perfect opponent could win against your strategy if they knew it exactly. A true Nash equilibrium has zero exploitability. Real solver output always has a little, and the industry convention (popularized by GTO Wizard's Nash distance writing) is to express it as a share of the pot. Professionals generally treat a few tenths of a percent of the pot as solved and anything approaching one percent as the outer edge of acceptable. Our take: this convention is healthy for the whole industry, and it is the standard we hold our own data to.
The stakes are real. In one widely covered 2022 case, a top tournament pro noticed a commercial training app's postflop sims looked wrong, re-ran the spots in a desktop solver deliberately set to 8 percent accuracy, and found the outputs were nearly identical. That is more than an order of magnitude outside professional tolerance, and the episode followed the product for years. The lesson for players: "we have GTO solutions" is not the claim that matters. What matters is which game conditions were solved, to what convergence standard, and what checks the data passes before you see it.
So here is how a GTO Gecko solution is made, in the same order the work happens.
How a GTO Gecko Solution Is Made
Stage 1 is tree design. Before anything gets solved, someone has to decide what game is being solved: how many players, how deep, what the ante structure is, what rake comes out of the pot, and which bets and raises are on the menu. We build these trees by hand per format and per depth. Open sizes range from 2x to 3x plus all-in opens where stacks are short, the raise wars run all the way through 4-bets and 5-bet jams (including calling ranges against 4-bets, which many chart products simply do not carry), and limp lines appear where depth makes them part of equilibrium play. Most configurations publish several open sizes side by side, so you can study the tree that matches how you actually play instead of being handed one size and told it is optimal.
Stage 2 is the solve. Preflop solutions come from Monte Carlo CFR-family equilibrium engines (CFR is counterfactual regret minimization, the algorithm family behind every serious poker solver). Each solve runs until it meets a statistical convergence target set for that solve, not until a timer runs out. Postflop, the full flop and turn game trees for every published configuration are solved offline to a fixed exploitability target with an iteration cap, using card isomorphism so that each of the 1,755 strategically distinct flops stands in exactly for the full set of 22,100. River strategies are completed by the same solver engine from the exact reach ranges preserved in those solved trees, and held to the same standard.
Stage 3 is verification. Solving is not the risky part; exporting, converting, and shipping data is. Machines check every release. The details are in the accuracy section below, because they deserve more than a sentence.
Stage 4 is delivery. Solutions are packaged in a compact format that stores action frequencies to a hundredth of a percent and EVs to five decimal places, and the mobile apps and play.gtogecko.com read the same published datasets through matching decoders. A spot you look up on your phone and the same spot on the web app come from one source of truth.
One honest note on what we do not publish: the vendor list and the settings files. Poker tooling is a market full of lookalike apps, and our toolchain, tree scripts, and packaging pipeline are the result of years of work. We publish the method, the assumptions, and the checks (the parts you can evaluate from the outside), and keep the recipe private. Every serious solutions provider makes the same trade-off somewhere; we prefer to say so plainly.
What Is in the Library? Tournaments First
The preflop library currently spans more than 3,600 solved scenario configurations across tournaments, cash, and Spins, and the postflop library is more than 8.5 terabytes of precomputed solver output in roughly 660 million solution files. Here is how that breaks down, starting with MTTs.
MTT ChipEV Solutions
The modern MTT preflop catalog holds 1,167 solved scenarios covering every table size from heads-up to 9-handed. Depth coverage follows how tournaments actually play: heads-up trees run from 2 up to 200 big blinds, mid-table sizes cluster in the depths where real MTT decisions live, and 9-max coverage extends down into pure push-fold territory (82 of the trees are all-in-or-fold by construction, because at those depths that is the equilibrium). Antes are modeled the modern way: a big blind ante posted as dead money, sized at 12.5 percent of the big blind per player, with stacks accounted so that a 100bb tree is exactly 100bb deep behind the ante. If you have read our GTO preflop strategy guide, these are the solutions those concepts come from.
MTT ICM Solutions
ICM is where most products get vague, so here is our model, specifically: a 1,000-runner tournament paying 150 places, with the winner earning 15.19 percent of the prize pool and payouts stepping down to a min-cash of roughly 0.2 percent. Against that one consistent payout structure we solve 504 scenarios across 310 stack configurations, from 3-handed up to 9-handed, at stages spanning the whole tournament: 75 percent of the field remaining, then progressively shallower stages down to 5 percent, the stone bubble (151 players left), three tables, two tables, and final tables from 9-handed down to 3-handed.
Every ICM scenario ships with its full context visible in the app: the payout ladder, per-seat tournament equity before the hand, and bubble factors (which peak around 1.2 as the money approaches). EVs in these solutions are expressed in tournament equity, not chips, because that is what ICM decisions are actually about. Selected stack lineups are published across multiple stages, so you can watch the same spot tighten and loosen as the tournament progresses. The trees are genuinely re-solved per stage; nothing is interpolated between stages. For the strategy side of this, see ICM poker explained and our final table ICM guide.
MTT Postflop Solutions
Tournament postflop trees are precomputed at 15, 20, 30, 50, 70, and 100 big blinds with a big blind ante in the pot, covering single-raised pots at every depth, 3-bet pots from 20bb up, 4-bet pots from 50bb up, and dedicated blind-versus-blind line families (limped pots included, because that is how blind battles actually go). Every configuration covers all 1,755 strategically distinct flops, and precomputed aggregate reports let you study frequencies across every flop at once instead of one board at a time.
Cash, Spins, and Heads-Up
Cash game solutions are solved rake-aware, with three separate rake models: online 6-max at 100bb with 5 percent rake capped at 4bb, live 150bb games with 8 positions and 10 percent rake capped at 2bb, and straddled games at 100bb and 200bb with a mandatory straddle, an ante, and 4 percent rake capped at 2bb. Spins are solved 3-handed from 1 to 50 big blinds at antes of 0 and 17 percent of the big blind, with postflop trees at 10 through 30bb, and the heads-up endgame is solved at every half big blind from 2 to 20.5bb, so the pay-jump-critical depths have no gaps. There is also a curated 3-way postflop library (109 vetted flops across cash, MTT, and Spins configurations), and separate exploit trees against Fish, Nit, and Maniac player profiles, which our GTO versus exploitative guide puts in context. If Spins are your game, the Spin and Go game plan is built on exactly these solutions.
| Library | Coverage | Antes and rake |
|---|---|---|
| MTT ChipEV preflop | 1,167 scenarios, 2- to 9-handed, heads-up to 200bb, push-fold at the short end | BB ante, 12.5% of the big blind |
| MTT ICM preflop | 504 scenarios, 310 stack setups, 3- to 9-handed, 11 tournament stages | BB ante, one fixed 1,000-runner payout model |
| MTT postflop | 15 to 100bb, SRP, 3-bet, 4-bet, blind vs blind, all 1,755 distinct flops | BB ante in every pot |
| Cash preflop + postflop | Online 6-max 100bb, live 150bb 8-handed, straddled 100/200bb | Raked: 5% cap 4bb, 10% cap 2bb, 4% cap 2bb |
| Spins preflop + postflop | 3-handed, 1 to 50bb, heads-up in half-bb steps to 20.5bb | Antes 0 and 17% of the big blind |
| Multiway + exploit | 3-way postflop on 109 curated flops, profile-based exploit trees | Matches the parent format |
Do the Solutions Account for Antes and Rake?
Antes: yes, and precisely. Tournament and Spins solutions are solved with the ante in the pot from the first action, modeled the way modern games play it (a big blind ante posted as dead money rather than per-player antes). This is not cosmetic. The ante changes the price on everything: opens get wider, blind defense gets wider, and short-stack shove and call thresholds move by whole big blinds. A rake-free, ante-free chart applied to an ante game is systematically too tight, which is exactly the kind of quiet error that costs money for years. Our preflop charts guide shows what these ranges look like in practice.
Rake: yes, for every cash format, with the cap and percentage modeled per game type. Rake mostly comes out of small and medium pots, so it hits exactly the marginal preflop decisions that charts are supposed to settle: the thin blind defense, the borderline open, the small-pairs set-mine. Solving with rake in the tree makes those ranges measurably tighter than rake-free charts, which is why our cash ranges can look different from a rake-free solve you have seen elsewhere. Both are equilibria; only one was solved for the game you are sitting in. Tournament solutions are correctly rake-free in play, since MTT rake is paid in the buy-in and never touches an in-game pot.
Why assumptions move ranges
Three directional effects worth internalizing. With a BB ante in the pot, every unopened spot offers a better price, so equilibrium opens and defends widen. With rake in the tree, small and medium pots pay a tax, so thin calls and marginal opens tighten. Under ICM near the bubble, chips you can lose are worth more than chips you can win, so calling ranges tighten hard while shoving wide stays strong. An app that cannot tell you which of these its charts assume is asking you to guess.
How Do We Verify Accuracy?
Convergence happens at solve time: every solve runs to its accuracy target before it is accepted. But most data corruption in any solutions product happens after the solve, in export and packaging. So the pipeline is instrumented end to end:
- Node integrity gates. Every exported preflop node must contain all 169 starting hand classes, with minimum-frequency floors that catch lossy or truncated exports before they ship. A solve that fails the gate does not get published.
- Round-trip verification. ICM releases are decoded back out of the shipped format and compared against the original solver output, node by node. Maximum allowed EV deviation is within the storage precision itself, and solver invariants (like fold EV equaling exactly zero) are checked on every node of a release.
- Regression tests on live data. The apps' decode and tree-navigation paths are exercised by automated tests that replay real published solutions end to end, so a data update cannot silently change what a spot displays.
- Parity proofs. The exploit (player profile) solver is required to reproduce the pure GTO solution byte for byte when profile adjustments are switched off. Same engine, provably, not a separate approximation.
- Calibrated grading. The trainers grade against the solved data with EV-aware tolerance: any action the solver itself mixes at meaningful frequency is accepted, and spot difficulty is classified by the EV gap between the best and second-best action, down to hundredths of a big blind. When a spot is a true coin flip in the solution, the trainer knows it, and EV loss tracking is measured against that same data.
Just as important is what we do not claim. There is no heads-up-table postflop library in the product today; anything labeled 2 players postflop means two players reaching the flop at a fuller table. The ICM model is one specific, clearly stated tournament (it assumes equal skill and does not model future blind levels, like essentially all ICM tooling). And the quick-reference simplified ranges are simplified on purpose and labeled as such; the full mixed-frequency solutions sit behind them. If a limitation matters to your study, we would rather you know it than discover it.
Why Do Ranges Differ Between Apps?
Put two serious GTO products side by side and you will find spots where the frequencies disagree. Before concluding that someone is wrong, check the assumptions, because in most cases the apps are solving different games: a different rake model, a different ante structure, a different menu of open sizes, a different bet-size abstraction postflop, or a different convergence standard. On top of that, many preflop decisions are genuinely close: when a solver mixes an action at 40 and 60 percent, the EV gap between the options is often inside solver noise, and two correct solves can land on different sides of it.
That is exactly why every spot in GTO Gecko displays its configuration (format, depth, ante, rake, and for ICM the full tournament context), and why the trainer accepts any action the solution itself plays at meaningful frequency. The skill being trained is not memorizing one app's decimals; it is playing ranges whose assumptions you understand. Our guides on how to use a poker solver and solvers versus trainers go deeper on studying this way.
Frequently Asked Questions
What tournament model are the ICM solutions based on?
A 1,000-runner MTT paying 150 places, winner-take 15.19 percent of the pool, solved at 11 stages from 75 percent of the field remaining through the stone bubble, three tables, two tables, and final tables from 9-handed to 3-handed. Every scenario shows its payout ladder, stack-based equities, and bubble factors in the app.
Do the MTT solutions include antes?
Yes. MTT solutions use a big blind ante at 12.5 percent of the big blind per player, posted as dead money, with depths accounted behind the ante. Spins use 17 percent antes alongside ante-free trees. Tournament postflop trees carry the ante in the pot too.
Do the solutions account for rake?
Cash solutions are solved with rake inside the game tree: 5 percent capped at 4bb for online 6-max, 10 percent capped at 2bb for live 150bb games, and 4 percent capped at 2bb for straddled games. Tournament solutions are rake-free in play by design, since MTT rake is paid in the buy-in.
Are the solutions the same on mobile and web?
Yes. iOS, Android, macOS, and play.gtogecko.com read the same published datasets through matching decoders, and automated tests replay real published data through both. A spot gives the same answer wherever you open it.
How accurate are the solutions?
Every solve runs to a preset convergence target rather than a time limit, and the bar we design to is the industry's sub-percent exploitability convention described earlier in this post. Every release then passes machine verification: full 169-hand coverage at every node, round-trip decode checks, and regression tests against live data. We publish the standard and the checks rather than a single marketing number, because a number without its verification story is exactly what burned players in the past.
Why not name the solver software and settings?
Because the toolchain is the competitive asset copycat apps would most like to have. We publish what you can actually evaluate: the algorithm family (Monte Carlo CFR equilibrium solving), the game conditions of every solution, the precision of the shipped data, and the verification each release passes. The vendor list and settings files stay private.
Study on Solutions You Can Interrogate
The standard, in one paragraph: more than 3,600 solved preflop configurations and a multi-terabyte postflop library, every spot solved under stated conditions (antes, rake, depth, payouts), run to convergence targets, machine-verified before release, and shipped identically to every platform, with the assumptions displayed where you study. If a training tool will not tell you these things, ask why.
You can interrogate ours directly: open any spot in the web app or on iOS and Android, check the configuration panel, and hold the numbers to the standard this post just described. That is how we would evaluate a training app, so it is how you should evaluate this one.