Tree building
Before the solver can iterate, it builds the game tree: a map of every way the hand can play out under your settings. The tree determines how much memory a solve needs and how long each iteration takes. This page explains what is in the tree, why some spots are enormous, and how ARTGTO protects you when a spot is too big.
You see this stage in the status bar as Building game tree… (or Building game tree (iso)…).
Streets
A postflop solve covers up to three streets:
- Flop — the three cards you pick in the board picker (required).
- Turn — optional. Leave it empty and the tree includes every possible turn card.
- River — optional. Leave it empty and the tree includes every river card after every turn.
This is the single biggest size lever. A flop solve with open turn and river contains a complete turn-and-river subtree for every runout — that is what makes it a true GTO solution for the whole hand, and also what makes it large. Fixing the turn (or turn and river) shrinks the tree enormously, at the cost of only covering that one runout.
Three kinds of nodes
The tree is made of three kinds of points:
| Node type | Who acts | Examples |
|---|---|---|
| Decision node | A player | The available actions: check, bet 123, call 123, fold, raise 456, or all-in variants like bet 123 (all-in) and raise 456 (all-in, forced). |
| Chance node | The deck | A turn or river card is dealt. One branch per (group of) possible card(s). |
| Terminal node | Nobody | The hand ends: either a fold (one player takes the pot) or a showdown (the pot is split by hand strength, with rake applied if configured). |
Every path from the root to a terminal node is one complete way the hand can play out. The solver stores strategy data for every hand in range at every decision node — that product, hands × actions × nodes, is what fills your RAM.
Suit isomorphism: free compression
Many cards are strategically identical. Take a rainbow flop like 2s 5d 9h: if the turn is the 7 of one unused suit or the 7 of another, nothing strategic changes — same straights, same flush possibilities (none), same everything. Building separate branches for those cards would mean solving the same situation twice.
ARTGTO detects these groups and builds one chance branch per group of equivalent cards, with a weight recording how many real cards it stands for. The solver accounts for the weights exactly, so the result is identical to the full tree — this is lossless. On a two-tone flop, this typically removes 40-60% of the chance branches, which means proportionally less memory and faster iterations.
When this kicks in, the status bar reads Building game tree (iso)…. You do not configure anything; it is automatic.
What makes trees big
Roughly in order of impact:
| Factor | Why it grows the tree |
|---|---|
| Open turn and river | Every runout gets its own complete subtree (see above). |
| Number of bet sizes | Each extra size at a node multiplies everything below it. Two flop sizes instead of one nearly doubles the flop subtree. |
| Raises allowed per street | Each allowed re-raise adds another full layer of decisions. Deep stacks make this worse, because more raise levels fit before all-in. |
| Effective stack depth | Deeper stacks allow more and larger raises before players are all-in. |
| Range width | Every combo in range needs strategy storage at every decision node it can reach. |
The river usually dominates: it sits at the bottom of the tree, so every multiplication above it lands there. On deep-stacked spots the river commonly accounts for most of the memory.
Two bet sizing settings act as natural tree-pruners:
- Auto all-in threshold — if a bet or raise would commit at least this percentage of the remaining stack (default 75%), it becomes an all-in instead. This removes near-all-in raise wars that add size without adding strategic content.
- Raise cap with forced all-in — limit the number of re-raises per street, and optionally force the last allowed raise to be all-in (shown in the tree as
raise 456 (all-in, forced)).
See Bet sizing for the full syntax and all settings.
The memory guard
ARTGTO estimates the memory footprint of a spot before solving it, node by node and street by street. Around that estimate there are two layers of protection, both visible in the solver controls.
Layer 1: 16-bit compress (optional, off by default)
Stores the solver's working values (regrets and accumulated strategy) in 16-bit form instead of 32-bit, roughly halving solver memory. Trade-offs, honestly:
- Each iteration is somewhat slower, because values are unpacked and repacked on the fly.
- 16-bit numbers hold less precision. On most boards this changes nothing: compressed solves reach the standard 0.3%-of-pot equilibrium just like uncompressed ones. But on strongly polarized boards, accuracy hits a floor around 0.2% of the pot and cannot be refined further, no matter how many iterations you run.
At the default Target Exploit % of 0.3 the floor is never binding. Only enable lower targets with compression off.
Layer 2: Low-memory fallback (on by default)
Some spots do not fit even with compression — deep stacks, many raises, and wide ranges multiply together. Rather than failing, the solver falls back to river bucketing: it groups river hands of similar strength and gives each group one shared strategy, choosing the largest bucket count that fits (400, then 200, then 100).
What this preserves and what it costs:
- Flop and turn keep full per-hand detail. Bucketing applies only to river decisions.
- Showdowns stay exact. Who wins each runout is still evaluated hand by hand, never by bucket.
- River decisions lose some precision. Hands in the same bucket play the same river strategy, so fine per-combo river distinctions are smoothed out.
The fallback engages only when the spot could not solve at all otherwise. A normal-sized spot is never bucketed, even with the checkbox on. Turning the checkbox off means oversized spots fail with an error instead of solving approximately — useful if you would rather re-spec the spot than accept reduced river precision.
Solves that used the fallback are always labeled, so you can never mistake one for a full-precision solution:
- The status bar shows it, for example:
Done — 250 iters in 2:34 · exploit 0.143% · river-bucketed @ 200(the number is the bucket count). - Batch run logs record the line
SOLVED (river buckets @ N)for each affected spot.
river-bucketed @ N solution as approximate, especially thin value bets and bluff-catching mixes between similar hands. Flop and turn strategy, and all EV/equity from exact showdowns, remain reliable. If river precision matters for the question you are studying, shrink the tree (fewer sizes, fewer raises, or a fixed turn) until the spot solves without the fallback.Next steps
- How the solver works — what happens after the tree is built.
- Bet sizing — the syntax and settings that define the tree's actions.
- System requirements — RAM and core guidance.