A working notebook on poker AI in the GGPoker ecosystem.

What we mean by "poker bot" in 2026

I think you'll find that the term "poker bot" is being used to such extreme lengths now that nearly all public discussions begin at an incorrect foundation. As it relates to the goal of this website, a poker bot is simply a piece of software which receives visible game state (hole cards for your seat and theirs, community cards, etc.) as input and produces some type of action under a real time latency constraint. A poker bot does not receive packets, does not know what cards are in an opponents hand and does not have knowledge of the deck. All that a poker bot does can be done by a human with the same information and data inputs, but the human would need to do them quickly enough, and also consistently, and at scale.

The interesting work happens in three layers stacked under that definition. The first is a solver-anchored baseline: pre-computed strategies from counterfactual regret minimisation (CFR) variants, often via PioSolver or GTO+ for heads-up trees and MonkerSolver for multiway. These are too large to run online and too slow to query naively; the production system compresses them into action-frequency tables keyed on bucketed game states. The second is the opponent model, which is where the modern research lives: lightweight online updates that converge in tens to low hundreds of hands against an anonymous opponent. The third is a policy combiner that decides how much to deviate from the baseline given the current opponent estimate, and bakes in detection-aware behavioural noise.

The GGPoker ecology in one page

GGPoker has been run by NSUS Group since it was launched, and by traffic volume, GGPoker is the biggest cash game and poker tournament site for 2026. What could be of interest to researchers, however, are not the marketing-related surface aspects (sponsorships similar to those used by Pokerstars, Daniel Negreanu as an ambassador, the WSOP affiliation), but rather the design elements and architectural decisions made with respect to how much a robot is able to or unable to do on the site.

Three matter most. Anonymous tables with rotating screen names collapse the long-horizon HUD attack — there is no stable identifier to accumulate 50,000 hands against. Their Smart HUD is operator-controlled and intentionally limited; third-party HUDs and overlays are banned. And PokerCraft, the customer-facing analytics product, is a thin slice of an internal model that the security team runs against the entire player base looking for statistical outliers. That last one is the real teeth of the detection system, not the things players see.

How detection actually works

Detection topologies are layered, asynchronized, and weighted. There isn't one single trigger event that will result in the detection of fraud. Instead, there's a combination of signals (or a total) that accumulate over time to eventually reach a level where they trigger an escalation. When this occurs, it happens after the cumulative value has exceeded a pre-determined threshold set for an acceptable level of false positives.

Behavioural fingerprinting

The timing of inputs from a player (input-timing distribution), how long they keep their finger on an object in order to select it (touch dwell for mobile devices) and how curved their mouse path is when selecting items (mouse path curvature when using a desktop device). The time delay between taking an action and confirming that action as correct (action confirmation latency).

Statistical play-pattern analysis

Distributional outliers: VPIP/PFR ratios that sit on solver mass with too-low variance, bet-sizing that clusters on exact pot fractions, fold-to-3bet frequencies that match population by ±0.5pp across thousands of hands. Pure GTO output is paradoxically easier to flag here than a noisier strong-human strategy.

Anti-collusion graph models

Account graphs joined by IP, device fingerprint, deposit method, KYC document, and table co-occurrence. This layer catches most of the high-impact bans (chip dumping, soft-play) — botting is a side-product when an operator runs a bot farm under one fingerprint.

Human review on flagged accounts

The decisive layer. Mathematical models propose; humans decide. A reviewer reads hand history, looks at chat behaviour, checks whether the account ever sits out for a phone call. Most botting bans are signed off here, not in an automated rule.

Areas covered on this site

Open questions for developers

The notes on this site are not finished. Five threads I think are genuinely open and would welcome discussion on:

1. Online opponent-model convergence. Under anonymous-table rotation, what is the minimum hand count for a useful exploitative deviation? The current empirical floor sits around 80-150 hands for a generic VPIP/PFR/3-bet sketch; can a Bayesian prior on the population distribution cut this to 40-50 while staying robust to fish-vs-reg priors?
2. Multi-table state isolation. Running four GGPoker tables on a single device with a shared opponent cache without leaking timing correlations across hands. The naive implementation gets caught on cross-table action-latency synchronisation.
3. Detection-aware policy combiners. Treating the operator's classifier as a noisy adversary and shaping the output distribution to maximise EV under a budgeted detection probability. The literature on adversarial classification (Dalvi et al. 2004 onward) is mostly about spam; the poker case is more interesting because the cost matrix is asymmetric.
4. LLM-augmented decision support. Frontier LLMs are bad at poker — they hallucinate ranges, misapply ICM, and have no calibrated frequency intuition. Are they useful at all? Tentatively, yes, for hand-history annotation and exploit hypothesis generation, but not for live decisions.
5. MTT automation. ICM, bubble factor, and stack-depth variance make tournaments meaningfully harder to automate than cash. The interesting question is not "can it be done" but "where does the EV-per-engineering-hour curve flatten."

I would be happy to receive contributions from anyone with knowledge of implementations or datasets related to the above. I do try to respond to all correspondence received; however, if serious mail comes in as frequently as this site receives reads, it will move the notes considerably faster than anything I could possibly grind out.