NLHB.EXE — Cash vs Tournament
C:\> home \ cash-vs-tournament
DIVERGENCE.DOC — Two Game Shapes

Cash games and tournaments are two different operational problems

Answer first: from the decision-engine side, cash and tournament NL Holdem are close cousins — same game tree, different stack and ICM dynamics. From the operations side, they are entirely different problems. We have run both since 2017, and the lesson we keep relearning is that a stack which is excellent for cash will quietly bleed out in tournaments unless the operations layer is rebuilt around the new session shape.

TL;DR for operators
  • Cash: long sessions, predictable seat-allocation, frequent rebuy events to handle
  • Tournament: finite arc, ICM-aware late-game policy, hostage seating (you cannot leave)
  • Detection surface differs: cash favours longitudinal behavioural signals; tournaments favour late-stage timing and bet-sizing tells

Session shape

A cash session, for us, is a unit of time with a clear stop condition. When the seat is unprofitable, we stand up. When the table changes character, we stand up. When telemetry says the room's anomaly score is creeping, we stand up. The kill-switch is cheap to use.

A tournament is the opposite. Once a bot is seated, it is hostage to the structure. You cannot pull it without burning the registration. That changes everything downstream. Our tournament supervisor has to decide, in advance, what events warrant burning the entry — and most do not.

CASH — bounded loop sit → play → evaluate → (stay | stand up) → repeat TOURNAMENT — one-way arc register → early → mid → bubble → ITM → FT → finish
Fig. 1 — operationally these are two different products, not two modes of one.

Kill-switch logic

For cash, our kill-switch is liberal. It pulls a seat on small signals. The cost of an unjustified pull is one missed session — small. The cost of a missed pull is a flagged account — large.

For tournaments, the kill-switch is conservative and event-shaped. Pulling mid-tournament is expensive: lost buy-in, lost equity, and a strange exit pattern that itself is a behavioural signal. We will only pull mid-tournament for a confirmed network-level incident, never for a borderline anomaly score.

ICM and late-game policy

Cash policies are stack-depth-aware but not ICM-aware. Tournament policies have to be ICM-aware in the late stages or they will play the wrong game on the bubble and at the final table. We keep two distinct policy heads for this reason. Trying to fold an ICM correction into a single cash policy at runtime was a mistake we made in 2019 and stopped making in 2020.

Reconciliation cadence

Cash reconciliation runs hourly. The agent ledger and our internal counter must agree to within rake-adjusted tolerance. In tournaments, reconciliation happens at registration, at each break, and at bust-out. The events between are blind — we trust the supervisor and we audit afterwards.

Detection surface

Cash detection skews longitudinal: weeks-long behavioural fingerprints, sit-stand patterns, win-rate curves. Tournament detection skews episodic: bet-sizing tells in late stages, push-fold timing under pressure, FT-only behaviour. The mitigations are different. The teams that share a single anti-detection playbook across both are the teams that get caught first in whichever surface they neglected.

Want to compare notes on cash-versus-tournament operations with operators who have done both for eight years?

Deal us in
Ready
Page 2 of 3
README v.2026.06