System 7 - QUANTARMY

System 7 (part 2): we went heads-up, and the exploiter finally got paid

Jesus Cuesta — Sun, 05 Jul 2026 21:03:35 GMT

In part 1 we ended on an uncomfortable lesson: we built an elaborate exploitative engine — hand classification, math filters, node-locking, an LLM for the hard nodes — and it lost. Against the reference panel, pure heuristic node-locking ran −9.75 bb/100 and the LLM hybrid −1.66 bb/100. What won, and by a landslide, was the dumbest tactic imaginable: open very wide and steal blinds without apology. +119 bb/100 with a strategy that fits on a napkin.

The moral of that piece was that the engine beats the brilliant idea: the edge isn't in the genius play, it's in the loop of author → test → compare → deploy → coach → repeat. And that exploitation only pays when there's a real leak to exploit.

What we didn't tell you — because it hadn't happened yet — is what that engine does when you finally give it a real opponent to aim at. This is that story. Since then we changed tables, rewrote half the engine, put it in Docker, and learned the hard way that in production, reliability is just another poker skill.

Recap: where we left off

For newcomers: System 7 is a No-Limit Hold'em agent that plays in the Arena on dev.fun, a tournament where software agents face each other (and humans). The core is deterministic Python — fast, reproducible, testable — with an LLM "brain" (MiniMax M3) we only call for the hard nodes. It's all open on GitHub.

Part 1 was played at 6-max tables. The honest diagnosis was that the reference panel, though theoretically sound, had a structural leak: it folded too much preflop. Our microscope of a machine wasn't needed; a hammer would do. But 6-max spreads the blame across five opponents and shreds your sample: you never see enough hands from any single villain to exploit him with confidence. The microscope had no one to focus on.

So we did the obvious thing we hadn't done: we took four players off the table.

The pivot to heads-up (Season S4)

Heads-up — one on one — changes everything, and not out of romance. It changes it through statistics. At 6-max, 500 hands are ~80 hands of each opponent: noise. Heads-up, 500 hands are 500 hands of the same opponent. At last the sample grows fast enough that "this guy folds too much to the 3-bet" goes from a hunch to a number with a confidence interval.

6-max: ~80 hands/opponent. Heads-up: ~500 of the same opponent

\text{SPR} = \frac{\text{Effective stack}}{\text{Pot}}

We spent the whole S4 season rebuilding the engine around a single opponent. In repo terms this was v0.6.0: node-locking activation, all-in EV, a heads-up-specific coach, and a unified panel. But the one-line summary hides the mindset shift: we stopped asking "what's the correct play against the field?" and started asking "what's the correct play against this guy I've been watching for 1,500 hands?".

It's exactly part 1's thesis — exploit instead of playing equilibrium — but finally with the terrain in our favor.

Node-locking that finally pays

Node-locking, as a reminder, means pinning (locking) part of the opponent's strategy based on what you've observed, and recomputing your best response against that specific leak. In part 1 it was, in practice, an expensive ornament: the sample wasn't big enough to trust the lock.

Heads-up, it is. We calibrated the adaptation threshold to ~1,900 hands per opponent, which is the order of magnitude the Arena deals in a serious session. Below that, we play a solid base and don't invent reads. Above it, the engine starts genuinely exploiting the classic archetypes:

NIT — plays only premiums: we steal his blinds relentlessly and pay him off almost nothing when he finally wakes up.
STATION — calls everything: we stop bluffing and fatten the value. Here a bluff is literally setting money on fire.
LAG — the loose-aggressive: we give the aggression back where the math holds and set traps at the nodes.
MANIAC — the extreme version: patience, traps, and letting him crash into himself.

Two fine-tunes came with this that sound minor and matter a lot. First, we widened the button c-bet range to coordinated boards: heads-up, initiative is valuable, and giving up too much turns you into the very NIT you want to exploit. Second, we fixed a leak of our own we'd been dragging along: underpairs on paired boards (an underpair against, say, KK on board) stopped being treated as commit-level hands and got reclassified as what they are — bluff-catchers. It's a small correction to a hand-classification table, and bb/100 live and die on exactly those.

python

def _archetype(st: dict) -> str:
    """Classify a villain from agent-stats. N-gated by sampleSize."""
    n = int(st.get("N") or 0)
    if n < 500:                    # too few hands -> don't trust the read
        return "UNKNOWN"
    vpip, pfr = _pct(st["vpid"]), _pct(st["pfr"])
    gap = vpip - pfr
    if vpip >= 30 and gap >= 15:   return "STATION"   # calls everything
    if vpip >= 40 and pfr >= 30:   return "MANIAC"    # ultra-aggressive
    if vpip <= 15 and gap <= 6:    return "NIT"       # only premiums
    if vpip >= 26 and pfr >= 20:   return "LAG"        # loose-aggressive
    return "TAG"                                          # solid default

All the tuning lives in system7-hu.json: open sizes, barrel frequencies, bluff 3-bets, and small-blind ranges. Strategy as data, versioned, swappable with an environment variable. That design — we promised it in part 1 — is what makes iteration cheap.

Motor v1.5: the survival logic

And here we reach today. v0.7.0, shipped this very afternoon, brings what we internally call motor v1.5, "survival." It's the biggest conceptual change since part 1, and it's born of an ugly observation: an engine optimized to maximize EV on every hand makes decisions that are great for the long run and ruinous for staying at the table.

The canonical example is AKo. Against a single opponent, getting it in with AKo is usually fine. But in multiway 4-bet/5-bet sequences, stacking off flat with AKo is throwing chips away: when that much money comes in from that many people, your gorgeous hand is, too often, the second-best one. Motor v1.5 stops doing that.

The new piece is commitment tiers — shallow / deep / all-in — indexed by re-raise depth. Instead of a uniform "with this strength, go with it all" rule, commitment is graduated by tier: the hotter the re-raise war gets, the more selective the hand you'll accept stacking off with. In multiway, paired hands also stop auto-committing at low SPR. Pure heads-up behavior is preserved intact: there, we still play to maximize.

Two engineering details that matter more than they look. All of this is behind a flag, survival:true: by default the behavior is unchanged, so nobody gets surprised and we can A/B against the previous engine. And it shipped with 18 new tests. Because a badly written commitment rule doesn't fail loudly: it fails silently, one stack every few hours — exactly the kind of leak part 1 taught us to fear.

Survival isn't the opposite of maximization. It's recognizing that in a format with a ladder and seasons, staying in the game has a value that hand-by-hand EV doesn't capture.

python

def _commit_tier(seats, seat_n, hero_bet, call_chips, eff, bb):
    """Commitment depth -> how much stack to risk.
    'shallow' (1st 3-bet) -> 'deep' (4-bet) -> 'allin' (5-bet+/jam)."""
    thr = max(KN["commit_4bet_bb"] * bb, 0.2 * eff)
    n_committed = sum(1 for s in seats
                      if s["seatNumber"] != seat_n
                      and (is_allin(s) or s.get("currentBetChips", 0) >= thr))
    risk = call_chips / max(eff, 1)
    hb = hero_bet / bb if bb else 0
    if n_committed >= 2 or risk >= 0.6 or hb >= 22:
        return "allin", n_committed
    if hb >= 8 or risk >= 0.35:
        return "deep", n_committed
    return "shallow", n_committed

Commitment tiers: shallow, deep, all-in

\text{EV}_{\text{total}} = \text{EV}_{\text{hand}} + \text{EV}_{\text{survival}}

Seasonal equity, heads-up ladder & auto-resume

v0.7.0 also brings three less glamorous, absolutely necessary pieces:

Seasonal equity. Before, equity curves mixed hands from different competitions and painted you a lying picture. Now the curve is scoped by competition_id: each season, its own graph. It sounds like accounting, and it is — but measuring honestly was the whole point of part 1, and mixing seasons is exactly the kind of statistical self-deception we preached against.

Heads-up ladder (the ladder bot). We packaged a static agent into its own ladder/ directory, with a defensive adapter and the treys library vendored inside. Why? Because the sandbox where some agents run has no filesystem and no way to install dependencies. An agent with zero disk dependencies is an agent that boots anywhere. It's the difference between "works on my machine" and "works on theirs."

PvP auto-resume. The game loop persists its state in data/prod_resume.json and survives host restarts, container recreation, and subprocess crashes. Before, an ill-timed restart left you a half-finished match and a hole in the data. Now it comes back on its own and picks up where it was. This connects straight to the next section, because we learned to value it the hard way.

Per-season equity: skill line (solid) vs variance line (dashed)

\text{EV}_{\text{ICM}} = \sum_{i=1}^{n} P(\text{place } i) \times \text{Payout}(i)

python

# PvP auto-resume — survive restarts
RESUME_FILE = "data/prod_resume.json"

def save_state(table_id, hand_num):
    with open(RESUME_FILE, "w") as f:
        json.dump({"table_id": table_id, "hand": hand_num,
                   "ts": time.time()}, f)

def resume():
    try:
        with open(RESUME_FILE) as f:
            return json.load(f)
    except FileNotFoundError:
        return None  # fresh start

From code to the trenches: production war stories

Part 1 ended on the "tooling": the three-zone dashboard (LAB / COACH / PRODUCTION). What it didn't cover is what it costs to keep that alive week after week. Spoiler: in an online tournament, operational reliability is just another poker skill. Here are the scars.

Docker, and the sin of recreating the container. The live deployment is Docker at /opt/arena-system7-llm (image system7-poker-arena:latest, dashboard on port 8787, restart: unless-stopped). We learned the most expensive rule of the project: never run up -d --force-recreate with jobs in flight. The Evals and PvPs are child subprocesses of the dashboard; recreating the container kills them stone dead, and you're left with half-finished evaluations and an empty .clasif folder. Hours of matches turned into nothing by one impatient deploy.

yaml

# docker-compose.yml — dashboard + optional workers
services:
  dashboard:
    build: .
    image: system7-poker-arena:latest
    command: ["dashboard"]
    ports: ["8787:8787"]
    volumes: ["./data:/data"]
    restart: unless-stopped
    environment:
      S7_STATS_DB: /data/s7_cash.db
      S7_RUN_BACKEND: subprocess

  bench:                          # optional: continuous Eval
    command: ["bench"]
    profiles: ["bench"]
    environment:
      S7_ENGINE: hybrid
      S7_MATCHES: "50"

The WAL that ate the disk. SQLite in WAL mode is wonderful until a job gets stuck and the write-ahead log grows to gigabytes. It happened to us. The hardening was three locks: journal_size_limit so the WAL can't grow unbounded, a per-match timeout so no job hangs forever, and a single-instance lock so two processes don't fight over the same database. None of this is poker. All of this is what lets you play poker.

python

# SQLite WAL hardening — three locks against runaway growth
conn = sqlite3.connect("s7_cash.db")
conn.execute("PRAGMA journal_mode = WAL")
conn.execute("PRAGMA journal_size_limit = 67108864")  # 64 MB cap
conn.execute("PRAGMA busy_timeout = 30000")            # 30s lock wait
conn.execute("PRAGMA wal_autocheckpoint = 1000")       # checkpoint every 1000 pages

Local self-play lies. You'd think the sensible way to measure an engine is to pit it against itself locally. Nope: the kit's self-play doesn't measure positional strength well, because it pins the hero to the small blind and skews the HUD. An engine's real strength is only measured live, in the Arena's Eval and PvP. Another lesson in statistical humility — of which we're now collecting a set.

The bottleneck wasn't the one we thought. We bumped resources on the fly to 6 cores / 4 GB. And the engineer's intuition — "if it's slow, it's the CPU" — turned out false: each M3 match eats ~170 MB of RAM, and the real bottleneck is RAM and the Arena's real-time tempo, not compute. The deterministic engine answers in milliseconds; what sets the pace is the table. Incidentally, the LLM calls run on MiniMax/Xiaomi token plans, keys in .env — no hardcoded providers.

The coach that improves itself

The piece that's matured most is the coach. In part 1 it was, above all, a diagnostician with LLM-powered hand reviews. Now it's a self-improving loop: M3 reads the stats reports, spots leaks, and proposes new strategy versions — those versioned JSONs — for us to A/B test. The human stays in the driver's seat (approving or discarding versions), but the "here's a pattern, try raising this frequency" work is done by the machine.

Heads-up, the coach became position-aware: separate objectives for the button (SB) and big-blind defense, activating past the 500-hand mark and warning when the diagnosis goes stale because you've played too many hands without updating the deployed strategy. Same old principle: don't trust an old read.

M3 reads stats, proposes strategy, A/B test, deploy

json

// strategies/system7-hu.json — heads-up tuning
{
  "survival": true,
  "game": "cash",
  "commit_value":       ["AA","KK","QQ","JJ","TT","AKs","AKo","AQs"],
  "commit_value_deep":  ["AA","KK","QQ","AKs"],
  "commit_value_allin":  ["AA","KK"],
  "knobs": {
    "commit_spr": 3,
    "commit_4bet_bb": 8,
    "commit_5bet_bb": 22,
    "commit_multi_n": 2
  }
}

Honest results, again

Here's where we have to stay true to ourselves. In part 1 we put concrete numbers down because we had them, with their ±20 bb/100 confidence intervals and all. In this entry we are not going to invent a heads-up winrate for a tidy ending, because this season's serious measurement is still live and we don't want to sell you noise dressed up as signal.

What we can say honestly is directional: node-locking, which at 6-max was decoration, at heads-up has someone to aim at and behaves as it should against the archetypes. Motor v1.5 bleeds less in the marginal multiway spots. And the equity curves — now split by season, with their skill line (solid) and their variance line (dashed) — finally tell a story that isn't contaminated by hands from another competition.

The sample will tell the rest, once the sample is a sample. We'd rather say "still alive and iterating" than a headline with a big number and an embarrassing confidence interval. That discipline was the heart of part 1, and we're not about to drop it now that things are starting to work.

What we took away (part 2)

Exploitation needs a target. All of part 1's machinery was correct; it just lacked an opponent to focus the microscope on. Heads-up gave it one. The idea wasn't wrong; the table was.
Survival isn't the opposite of maximizing. Optimizing every hand in a vacuum loses you stacks that matter. Motor v1.5 sacrifices a little point-EV to stay standing, and in a format with a ladder, that is real EV.
Reliability is a poker skill. A runaway WAL, an ill-timed --force-recreate, or a restart with no auto-resume cost you as many chips as a bad line. In an online tournament, uptime plays hands.
The loop still beats the idea. Same as part 1: author → test → deploy → coach → repeat. The coach that now proposes strategies isn't magic; it's the same loop, with one more rung automated.

We're still alive in the Arena. And for the first time, the exploiter we wrote with so much care has someone in front of it worth exploiting.

Resources & links

Code (v0.7.0): github.com/quantarmyz/system7-poker-arena — deterministic engine, LLM hybrid, dashboard, and tooling.
Platform: dev.fun · arena.dev.fun
Reasoning model: MiniMax (M3)
Part 1: System 7: we taught an AI to exploit poker
And from the house: rat-talks.com · unespeculador.com · pythonparatrading.com

The project is still live in the Arena. If you're into the intersection of AI, game theory, and decision-making under uncertainty, the repo is open and the scars are documented.

System 7 (parte 2): nos fuimos al heads-up, y el explotador por fin cobró

Jesus Cuesta — Sun, 05 Jul 2026 21:03:34 GMT

En la primera parte terminamos con una lección incómoda: construimos un motor explotador elaboradísimo —clasificación de manos, filtros matemáticos, node-locking, un LLM para los nudos difíciles— y perdió. Contra el panel de referencia, el node-locking heurístico puro hacía −9.75 bb/100 y la versión híbrida con LLM −1.66 bb/100. Lo que ganaba, y por goleada, era la táctica más tonta imaginable: abrir muchísimo y robar ciegas sin complejos. +119 bb/100 con una estrategia que cabe en una servilleta.

La moraleja de aquella entrega fue que el motor le gana a la idea brillante: la ventaja no está en la jugada genial, sino en el bucle de autor → test → comparar → desplegar → coach → repetir. Y que la explotación solo paga cuando hay una fuga real que explotar.

Lo que no contamos —porque todavía no había pasado— es qué ocurre cuando le das a ese motor un rival de verdad al que apuntar. Esta es esa historia. Desde entonces cambiamos de mesa, reescribimos medio motor, lo metimos en Docker y aprendimos, a base de golpes, que en producción la fiabilidad es una habilidad de póker más.

Recapitulando: dónde lo dejamos

Para quien llegue nuevo: System 7 es un agente de No-Limit Hold'em que juega en el Arena de dev.fun, un torneo donde agentes de software se enfrentan entre sí (y a humanos). El núcleo es Python determinista —rápido, reproducible, testeable— con un "cerebro" LLM (MiniMax M3) al que solo llamamos para los nudos difíciles. Todo está abierto en GitHub.

La parte 1 se jugó en mesas de 6-max. El diagnóstico honesto fue que el panel de referencia, aunque teóricamente sólido, tenía una fuga estructural: foldeaba demasiado preflop. Nuestra maquinaria de microscopio no hacía falta; bastaba un martillo. Pero un 6-max reparte la culpa entre cinco rivales y trocea la muestra: nunca ves suficientes manos de un mismo villano como para explotarlo con confianza. El microscopio no tenía a quién enfocar.

Así que hicimos lo obvio que no habíamos hecho: quitamos a cuatro jugadores de la mesa.

El giro al heads-up (temporada S4)

El heads-up —uno contra uno— lo cambia todo, y no por romanticismo. Lo cambia por estadística. En 6-max, 500 manos son ~80 manos de cada rival: ruido. En heads-up, 500 manos son 500 manos del mismo rival. Por fin la muestra crece lo bastante rápido como para que "este tío foldea demasiado a la 3-bet" pase de corazonada a número con intervalo de confianza.

6-max: ~80 manos/rival. Heads-up: ~500 del mismo rival

\text{SPR} = \frac{\text{Effective stack}}{\text{Pot}}

Toda la temporada S4 la dedicamos a rehacer el motor pensando en un solo oponente. En términos de repo, esto fue la v0.6.0: activación de node-locking, EV en all-in, un coach específico de heads-up y un panel unificado. Pero la frase de una línea esconde el cambio de mentalidad: dejamos de preguntar "¿cuál es la jugada correcta contra el campo?" y empezamos a preguntar "¿cuál es la jugada correcta contra este que llevo 1.500 manos mirando?".

Es exactamente la tesis de la parte 1 —explotar en lugar de jugar equilibrio— pero por fin con el terreno a favor.

Node-locking que por fin paga

El node-locking, recordemos, es fijar (clavar, lock) una parte de la estrategia del rival según lo que has observado, y recalcular tu respuesta óptima contra esa fuga concreta. En la parte 1 era, en la práctica, un adorno caro: la muestra no daba para fiarse del lock.

En heads-up sí da. Calibramos el umbral de adaptación a ~1.900 manos por oponente, que es el orden de magnitud que el Arena reparte en una sesión seria. Por debajo de eso, jugamos base sólida y no nos inventamos reads. Por encima, el motor empieza a explotar de verdad los arquetipos clásicos:

NIT — el que solo juega manos premium: le robamos las ciegas sin descanso y le pagamos poquísimo cuando por fin despierta.
STATION — el que paga todo: dejamos de farolear y engordamos el valor. Aquí el farol es literalmente prender dinero.
LAG — el agresivo suelto: le devolvemos la agresión donde la matemática aguanta y le tendemos trampas en los nudos.
MANIAC — la versión extrema: paciencia, trampas y dejar que se estrelle solo.

Con esto vinieron dos ajustes finos que suenan a poco y valen mucho. Primero, ampliamos el rango de c-bet en botón a boards coordinados: en heads-up, la iniciativa vale, y ceder demasiado te convierte en el NIT que quieres explotar. Segundo, arreglamos una fuga propia que llevábamos arrastrando: las parejas bajas en boards emparejados (una pareja de menos frente a, digamos, KK en el board) dejaron de tratarse como manos de compromiso y pasaron a clasificarse como lo que son, bluff-catchers. Es una corrección pequeña de una tabla de clasificación de manos, y de esas viven o mueren los bb/100.

python

def _archetype(st: dict) -> str:
    """Classify a villain from agent-stats. N-gated by sampleSize."""
    n = int(st.get("N") or 0)
    if n < 500:                    # too few hands -> don't trust the read
        return "UNKNOWN"
    vpip, pfr = _pct(st["vpid"]), _pct(st["pfr"])
    gap = vpip - pfr
    if vpip >= 30 and gap >= 15:   return "STATION"   # calls everything
    if vpip >= 40 and pfr >= 30:   return "MANIAC"    # ultra-aggressive
    if vpip <= 15 and gap <= 6:    return "NIT"       # only premiums
    if vpip >= 26 and pfr >= 20:   return "LAG"        # loose-aggressive
    return "TAG"                                          # solid default

Todo el afinado vive en system7-hu.json: tamaños de apertura, frecuencias de barril, 3-bets de farol y rangos de ciega pequeña. Estrategia como dato, versionada, intercambiable con una variable de entorno. Ese diseño —lo prometimos en la parte 1— es lo que hace que iterar sea barato.

Motor v1.5: la lógica de supervivencia

Y aquí llegamos a lo de hoy mismo. La v0.7.0, publicada esta misma tarde, trae lo que internamente llamamos motor v1.5, "supervivencia". Es el cambio conceptual más grande desde la parte 1, y nace de una observación fea: un motor optimizado para maximizar EV en cada mano toma decisiones estupendas para el largo plazo y ruinosas para seguir en la mesa.

El ejemplo canónico es AKo. Contra un solo rival, meter la pila con AKo suele estar bien. Pero en secuencias multiway de 4-bet/5-bet, meterla plano con AKo es tirar fichas: cuando entra tanto dinero de tanta gente, tu mano preciosa es, con demasiada frecuencia, la segunda mejor. El motor v1.5 deja de hacerlo.

La pieza nueva son los niveles de compromiso —shallow / deep / all-in— indexados por la profundidad de la re-subida. En vez de una regla uniforme de "con esta fuerza, voy con todo", el compromiso se gradúa por tramo: cuanto más se recrudece la guerra de re-raises, más selectiva se vuelve la mano con la que aceptas jugarte la pila. En multiway, además, las parejas dejan de comprometerse automáticamente en SPR bajo. El comportamiento en heads-up puro se conserva intacto: allí seguimos jugando a maximizar.

Dos detalles de ingeniería que importan más de lo que parece. Todo esto está detrás de un flag, survival:true: por defecto el comportamiento no cambia, así que nadie se lleva sorpresas y podemos hacer A/B contra el motor anterior. Y llegó acompañado de 18 tests nuevos. Porque una regla de compromiso mal escrita no falla ruidosamente: falla silenciosamente, una pila cada varias horas, justo del tipo de fuga que la parte 1 nos enseñó a temer.

Supervivencia no es lo contrario de maximización. Es reconocer que en un formato con escalera y temporadas, seguir jugando tiene un valor que la EV mano a mano no captura.

python

def _commit_tier(seats, seat_n, hero_bet, call_chips, eff, bb):
    """Commitment depth -> how much stack to risk.
    'shallow' (1st 3-bet) -> 'deep' (4-bet) -> 'allin' (5-bet+/jam)."""
    thr = max(KN["commit_4bet_bb"] * bb, 0.2 * eff)
    n_committed = sum(1 for s in seats
                      if s["seatNumber"] != seat_n
                      and (is_allin(s) or s.get("currentBetChips", 0) >= thr))
    risk = call_chips / max(eff, 1)
    hb = hero_bet / bb if bb else 0
    if n_committed >= 2 or risk >= 0.6 or hb >= 22:
        return "allin", n_committed
    if hb >= 8 or risk >= 0.35:
        return "deep", n_committed
    return "shallow", n_committed

Niveles de compromiso: shallow, deep, all-in

\text{EV}_{\text{total}} = \text{EV}_{\text{hand}} + \text{EV}_{\text{survival}}

Equity por temporada, escalera heads-up y auto-reanudación

La v0.7.0 trae además tres piezas menos glamurosas y absolutamente necesarias:

Equity por temporada. Antes, las curvas de equity mezclaban manos de competiciones distintas y te pintaban un dibujo mentiroso. Ahora la curva se acota por competition_id: cada temporada, su gráfica. Suena a contabilidad, y lo es —pero medir bien fue el tema central de la parte 1, y mezclar temporadas es exactamente la clase de autoengaño estadístico contra el que predicábamos.

Escalera heads-up (el ladder bot). Empaquetamos un agente estático en su propio directorio ladder/, con un adaptador defensivo y la librería treys vendorizada dentro. ¿Por qué? Porque el sandbox donde corren algunos agentes no tiene sistema de archivos ni forma de instalar dependencias. Un agente con cero dependencias de disco es un agente que arranca donde sea. Es la diferencia entre "funciona en mi máquina" y "funciona en la suya".

Auto-reanudación de PvP. El bucle de juego persiste su estado en data/prod_resume.json y sobrevive a reinicios del host, recreaciones del contenedor y caídas de subprocesos. Antes, un reinicio a deshora te dejaba una partida a medias y un hueco en los datos. Ahora se levanta solo y sigue donde estaba. Esto conecta directamente con la siguiente sección, porque aprendimos a valorarlo por las malas.

Curva de equity por temporada: habilidad vs varianza

\text{EV}_{\text{ICM}} = \sum_{i=1}^{n} P(\text{place } i) \times \text{Payout}(i)

python

# PvP auto-resume — survive restarts
RESUME_FILE = "data/prod_resume.json"

def save_state(table_id, hand_num):
    with open(RESUME_FILE, "w") as f:
        json.dump({"table_id": table_id, "hand": hand_num,
                   "ts": time.time()}, f)

def resume():
    try:
        with open(RESUME_FILE) as f:
            return json.load(f)
    except FileNotFoundError:
        return None  # fresh start

Del código a la trinchera: historias de producción

La parte 1 terminaba en el "tooling": el panel de tres zonas (LAB / COACH / PRODUCCIÓN). Lo que no contaba es lo que cuesta tener eso vivo semana tras semana. Spoiler: en un torneo online, la fiabilidad operativa es una habilidad de póker más. Estas son las cicatrices.

Docker, y el pecado de recrear el contenedor. El despliegue vivo es Docker en /opt/arena-system7-llm (imagen system7-poker-arena:latest, dashboard en el puerto 8787, restart: unless-stopped). Aprendimos la regla más cara del proyecto: nunca hagas up -d --force-recreate con jobs en vuelo. Los Eval y los PvP son subprocesos hijos del dashboard; recrear el contenedor los mata en seco, y te quedas con evaluaciones a medias y una carpeta .clasif vacía. Horas de partidas convertidas en nada por un despliegue impaciente.

yaml

# docker-compose.yml — dashboard + optional workers
services:
  dashboard:
    build: .
    image: system7-poker-arena:latest
    command: ["dashboard"]
    ports: ["8787:8787"]
    volumes: ["./data:/data"]
    restart: unless-stopped
    environment:
      S7_STATS_DB: /data/s7_cash.db
      S7_RUN_BACKEND: subprocess

  bench:                          # optional: continuous Eval
    command: ["bench"]
    profiles: ["bench"]
    environment:
      S7_ENGINE: hybrid
      S7_MATCHES: "50"

El WAL que se comió el disco. SQLite en modo WAL es maravilloso hasta que un job se atasca y el write-ahead log crece a gigabytes. Nos pasó. El hardening fue a base de tres candados: journal_size_limit para que el WAL no crezca sin freno, un timeout por match para que ningún job se quede colgado eternamente, y un lock de instancia única para que no haya dos procesos peleándose por la misma base de datos. Nada de esto es póker. Todo esto es lo que te permite jugar al póker.

python

# SQLite WAL hardening — three locks against runaway growth
conn = sqlite3.connect("s7_cash.db")
conn.execute("PRAGMA journal_mode = WAL")
conn.execute("PRAGMA journal_size_limit = 67108864")  # 64 MB cap
conn.execute("PRAGMA busy_timeout = 30000")            # 30s lock wait
conn.execute("PRAGMA wal_autocheckpoint = 1000")       # checkpoint every 1000 pages

El self-play local miente. Uno pensaría que la forma sensata de medir un motor es enfrentarlo contra sí mismo en local. No: el self-play del kit no mide bien la fuerza por posición, porque clava al héroe en la ciega pequeña y sesga el HUD. La fuerza real de un motor solo se mide en vivo, en el Eval y el PvP del Arena. Otra lección de humildad estadística, de las que ya coleccionamos.

El cuello de botella no era el que creíamos. Subimos los recursos en caliente a 6 cores / 4 GB. Y la intuición de ingeniero —"si va lento, es la CPU"— resultó falsa: cada partida con M3 come ~170 MB de RAM, y el verdadero cuello es la RAM y el tempo en tiempo real del Arena, no el cómputo. El motor determinista responde en milisegundos; lo que marca el ritmo es la mesa. Por cierto, las llamadas al LLM van sobre planes de tokens de MiniMax/Xiaomi, con las claves en .env —nada de proveedores hardcodeados.

El coach que se mejora solo

La pieza que más ha madurado es el coach. En la parte 1 era, sobre todo, un diagnosticador con reviews de manos vía LLM. Ahora es un bucle que se mejora a sí mismo: M3 lee los informes de estadísticas, detecta fugas y propone nuevas versiones de estrategia —esos JSON versionados— para que las probemos en A/B. El humano sigue en el asiento del conductor (aprobando o descartando versiones), pero el trabajo de "aquí hay un patrón, prueba a subir esta frecuencia" lo hace la máquina.

En heads-up el coach se volvió consciente de la posición: objetivos distintos para el botón (SB) y para la defensa de ciega grande, activándose a partir de las 500 manos y avisando cuando el diagnóstico se queda obsoleto porque llevas demasiadas manos sin actualizar la estrategia desplegada. Es el mismo principio de siempre: no confíes en un read viejo.

M3 lee stats, propone estrategia, A/B test, deploy

json

// strategies/system7-hu.json — heads-up tuning
{
  "survival": true,
  "game": "cash",
  "commit_value":       ["AA","KK","QQ","JJ","TT","AKs","AKo","AQs"],
  "commit_value_deep":  ["AA","KK","QQ","AKs"],
  "commit_value_allin":  ["AA","KK"],
  "knobs": {
    "commit_spr": 3,
    "commit_4bet_bb": 8,
    "commit_5bet_bb": 22,
    "commit_multi_n": 2
  }
}

Resultados honestos, otra vez

Aquí es donde nos toca ser fieles a nosotros mismos. En la parte 1 pusimos números concretos porque los teníamos, con sus intervalos de confianza de ±20 bb/100 y todo. En esta entrega no vamos a inventarnos un winrate de heads-up para cerrar bonito, porque la medición seria de esta temporada sigue viva y no queremos venderte ruido disfrazado de señal.

Lo que sí podemos decir con honestidad es direccional: el node-locking, que en 6-max era decoración, en heads-up tiene a quién apuntar y se comporta como debe contra los arquetipos. El motor v1.5 sangra menos en los multiway marginales. Y las curvas de equity —ahora separadas por temporada, con su línea de habilidad (sólida) y su línea de varianza (discontinua)— por fin cuentan una historia que no está contaminada por manos de otra competición.

El resto lo dirá la muestra, cuando la muestra sea muestra. Preferimos "seguimos vivos e iterando" a un titular con un número grande y un intervalo de confianza vergonzoso. Esa disciplina fue el corazón de la parte 1, y no pensamos abandonarla ahora que las cosas empiezan a salir.

Lo que nos llevamos (parte 2)

La explotación necesita un blanco. Toda la maquinaria de la parte 1 era correcta; le faltaba un rival al que enfocar el microscopio. El heads-up se lo dio. La idea no estaba mal; estaba mal la mesa.
Supervivencia no es lo contrario de maximizar. Optimizar cada mano en el vacío te hace perder pilas que importan. El motor v1.5 sacrifica algo de EV puntual a cambio de seguir en pie, y en un formato con escalera eso es EV de verdad.
La fiabilidad es una habilidad de póker. Un WAL desbocado, un --force-recreate a destiempo o un reinicio sin auto-reanudación te cuestan tantas fichas como una mala línea. En un torneo online, el uptime juega manos.
El bucle sigue ganándole a la idea. Como en la parte 1: autor → test → desplegar → coach → repetir. El coach que ahora propone estrategias no es magia; es el mismo bucle, con un peldaño más automatizado.

Seguimos vivos en el Arena. Y por primera vez, el explotador que escribimos con tanto mimo tiene delante a alguien a quien explotar.

Recursos y enlaces

Código (v0.7.0): github.com/quantarmyz/system7-poker-arena — motor determinista, híbrido con LLM, dashboard y tooling.
Plataforma: dev.fun · arena.dev.fun
Modelo de razonamiento: MiniMax (M3)
Parte 1: System 7: enseñamos a una IA a exploitar el póker
Y por la casa: rat-talks.com · unespeculador.com · pythonparatrading.com

El proyecto sigue vivo en el Arena. Si te interesa el cruce entre IA, teoría de juegos y decisión bajo incertidumbre, el repo está abierto y las cicatrices, documentadas.

System 7: we taught an AI to exploit poker — and what actually won was something else

Jesus Cuesta — Sun, 21 Jun 2026 20:44:05 GMT

A technical field report on building a poker agent for dev.fun's Arena: the heuristic method, LLMs at the table, and the honest results — including the ones we didn't expect.

The experiment

On dev.fun there's a place where AI agents sit down at a No-Limit Texas Hold'em table and play each other. It's not a demo: real hands, real chips, real opponents (some humans behind a bot, some pure bots) and, in the tournaments, real on-chain money on the line.

The question we asked is deceptively simple: how do you build an agent that wins?

The short answer, after months of code, thousands of hands, and a dashboard that ended up looking like a quant fund's control room, is this: we built an extraordinarily sophisticated machine to exploit opponents… and the thing that actually beat the toughest adversary was an idea so simple it's almost dumb. This post is the long story of how we got there, and what it taught us about poker, about LLMs, and about measuring things honestly.

dev.fun and the Arena

The dev.fun Arena is a competition of poker agents. Your agent is a program that talks to a real-time API. The loop is always the same:

join — you take a seat.
pending-actions — the API tells you "it's your turn, here's the situation" (your cards, the board, the bets, the stacks, who did what).
action — you respond: fold, check, call, bet, raise and how much.

python

# System 7 — game loop against the Arena API
client = ArenaClient(base_url, api_key=ARENA_API_KEY)
client.join(table_id)                          # 1. take a seat

while True:
    table = client.pending_actions(table_id)   # 2. "your turn, here's the situation"
    decision = hybrid.decide(table, deadline_s=30)
    client.action(table_id,                    # 3. respond: fold/check/call/bet/raise
                  action=decision["action"],
                  amount=decision.get("amount"))

The game loop: join, pending-actions, action

There's a deadline per decision: don't answer in time and you get auto-folded. It's real poker, with a real clock.

The Arena has three "tracks," and the difference matters because each rewards different things:

Eval — your agent plays 500 hands against a fixed panel of five reference bots. It's a benchmark: it scores you in bb/100 (big blinds won per 100 hands, poker's universal metric) and ranks you. No prize, one-shot per agent. This is no field of fish: the panel is the closest thing to a "perfect" opponent you'll face.
Playground — PvP with play money, free and continuous. Here you do get real opponents, with their quirks and their leaks.
Tournament — an MTT (multi-table tournament) with on-chain entry (Monad chain, MON token): you buy in once, get a fixed stack, and compete across tables of 2 to 6 players that melt down until one champion remains.

That distinction — a near-perfect opponent (Eval) versus leaky opponents (Playground/Tournament) — is the axis of everything that follows.

Two ways to play: GTO versus exploitation

Modern poker lives between two philosophies.

GTO (Game Theory Optimal). You play the Nash equilibrium: an unexploitable strategy. Whatever you do, you don't lose in the long run, because you mix your plays so the opponent can never gain an edge. It's what solvers and Counterfactual Regret Minimization (CFR/DeepCFR) networks approximate. GTO doesn't try to win big; it tries to never lose.

Exploitation. You give up part of that armor to punish the opponent's specific mistakes. Folds too much to raises? You bluff more. Calls with anything? You stop bluffing and bet bigger for value. It's how human pros think: equilibrium is the floor, but the money is in the other guy's leaks.

Our starting thesis was the exploitative player's: use GTO as a defensive floor and, from there, deviate aggressively to squeeze every weakness. In the jargon, node-locking: you mentally "lock" the opponent's error at a node of the decision tree and attack right there. We built an entire engine around this idea. It's called System 7.

GTO as defensive floor + aggressive exploitative deviations

\sigma^* = \arg\min_{\sigma} \max_{\sigma'} u(\sigma', \sigma)

System 7: a hand-written exploitation engine

The first thing to understand about System 7 is what it is not: it's not an LLM, and at decision time it calls no network and no model. It's pure, deterministic Python —and open source on GitHub. It takes the table, runs the math, and returns a play in milliseconds. All the "intelligence" is encoded as rules, distilled from an exploitative methodology (the EducaPoker / "University Strategy" school, with the fingerprint of players like Raúl Mestre).

The engine is organized into four directives.

D1 — How much you trust what you see (the sample N). You can't exploit an opponent you know nothing about. System 7 scales its aggression by how many hands it has observed the villain:

N < 100: blindness. Ignore the stats (pure noise), play standard ranges, respect opponent aggression.
100 ≤ N < 500: start profiling by the gap between VPIP (how often they put money in) and PFR (how often they raise). Out come the archetypes: Nit (super-tight), TAG (solid), LAG (loose-aggressive), Calling Station (calls everything) and Maniac. Each is played differently: against the station, zero tolerance for bluffs and bigger value bets; against the nit, steal their blinds relentlessly.
N ≥ 500: fine node-locking. If the opponent folds to 3-bets more than 55% of the time, we re-raise any hand with an Ace blocker. If they abandon the flop to a continuation bet more than 45% of the time, we bet 100% of our range with a small sizing.

python

def _archetype(st: dict) -> str:
    """Classify a villain from agent-stats. N-gated by sampleSize."""
    n = int(st.get("N") or 0)
    if n < 500:                    # too few hands -> don't trust the read
        return "UNKNOWN"
    vpip, pfr = _pct(st["vpid"]), _pct(st["pfr"])
    gap = vpip - pfr
    if vpip >= 30 and gap >= 15:   return "STATION"   # calls everything
    if vpip >= 40 and pfr >= 30:   return "MANIAC"    # ultra-aggressive
    if vpip <= 15 and gap <= 6:    return "NIT"       # only premiums
    if vpip >= 26 and pfr >= 20:   return "LAG"        # loose-aggressive
    return "TAG"                                          # solid default

D2 — What you have and where you are (the geometry). Instead of thinking "I have a pair of aces," System 7 classifies the hand by its relative fit with the board: MMF (monster hands: sets, flushes, straights), MF (strong hands: top pair good kicker, overpair), MM (medium), MD (weak), and Air/Draws. And it classifies the board by texture: dry, semi-coordinated, coordinated and extremely coordinated (where even a set drops a tier because the danger is huge). On top of that, the dynamics of the running cards: a scary card (an Ace, a King that completes a flush) favors the aggressor and lowers the bluffing threshold; a defensive card brakes the aggression and calls for pot control.

D3 — The relentless arithmetic (pot odds vs equity). No hunches here. It computes the pot odds (what you risk versus what you can win) and compares them to your real equity, counting adjusted outs for the texture — a flush draw is worth less if the opponent can hold a higher one; overcards are worth almost zero on a very coordinated board. The rule is a mandate: if your equity doesn't cover the pot odds, you fold — unless the HUD certifies the opponent will fold (then the bluff has value of its own).

python

def _pme(call_chips: int, pot: int) -> float:
    """Pot odds: what you risk vs what you can win."""
    tot = pot + call_chips
    return (call_chips / tot) if tot > 0 else 1.0

def _per(adj_outs: int, board_len: int) -> float:
    """Adjusted-outs equity (rule of 4/2)."""
    mult = 4 if board_len == 3 else (2 if board_len == 4 else 0)
    return min(0.95, adj_outs * mult / 100.0)

\text{PME} = \frac{\text{Call}}{\text{Pot} + \text{Call}}

\text{PER}_{\text{flop}} = \frac{\text{Outs} \times 4}{100}, \quad \text{PER}_{\text{turn}} = \frac{\text{Outs} \times 2}{100}

\text{Call if } \text{PER} \geq \text{PME}

D4 — The postflop and the "Killer Parsley." When the SPR (stack-to-pot ratio) drops below 3, you commit with any strong hand: pot control vanishes, you're all in. And for the bluffs there's the protocol nicknamed "Perejil Asesino" (Killer Parsley): a conditional bluff. You only raise as a bluff if conditions are met (evident opponent weakness, a lifeline of 8–10 real outs backing the play in case you get called, adjustments for the number of opponents…). You never bluff on impulse with trash; every aggression is backed by math or a documented leak.

And above it all, the HUD: a module that reads opponents' live stats (sample size, VPIP, PFR, 3-bet, fold-to-cbet, showdown…), sorts them into archetypes, and feeds the D1 deviations. The HUD is what turns System 7 from a disciplined robot into an exploiter.

python

# Strategy as versioned data — strategies/<name>.json
SIZING = {
    "dry":     {"flop": 0.33, "turn": 0.50, "river": 0.60},
    "semi":    {"flop": 0.50, "turn": 0.60, "river": 0.66},
    "coord":   {"flop": 0.66, "turn": 0.75, "river": 0.75},
    "extreme": {"flop": 0.75, "turn": 0.80, "river": 0.80},
}
# Toggle strategy: S7_STRAT=s7-opus uv run run_hybrid_system7.py

It is, in short, a serious and complete attempt to encode how an exploitative pro thinks. It worked. The question was: did it win?

Putting an LLM at the table

The heuristic engine is fast and cheap, but it has a ceiling: rules, however refined, don't cover every weird spot. So we tried a hybrid engine: the heuristic handles the trivial spots (the vast majority) and, in the hard spots, hands the decision to an LLM that reasons the play out.

We used MiniMax M3, a reasoning model, with the method's own system prompt (the four directives in plain language, plus a JSON output contract). The LLM gets the reconstructed situation and returns a justified play. The cost? About 27 seconds per decision and non-trivial token usage — which is why it only steps in for the spots that truly warrant it (difficulty gating).

python

def _is_hard(table: dict, deadline_s: float) -> bool:
    """Gate: True => worth a slow LLM call (~27s)."""
    if deadline_s < 30:            # M3 takes ~27s; don't risk auto-fold
        return False
    board = list(table.get("boardCards") or [])
    if not board:                  # preflop: position ranges suffice
        return False
    texture = H._texture(board)
    strength = H._strength(hole, board, texture)
    outs = H._adjusted_outs(hole, board, texture)
    if strength == "MMF":         # clear value / commit
        return False
    if strength == "MM" or (strength in ("AIR", "MD") and outs >= 4):
        return True               # thin value / semi-bluff / give-up
    return False

Here's a theme that's become central across the whole AI ecosystem: reasoning models. An M3 or a DeepSeek-R1 "thinks out loud" before answering, which gives them a real edge on problems with many interdependent variables — and poker, in its hard spots, is exactly that. This comes back elegantly later, in our own coach.

What happened (and what we didn't expect)

Here's the honest part, which is also the most interesting.

The Eval panel — that "near-perfect" opponent — turned out to be five identical clones of a DeepCFR bot: a balanced TAG (VPIP ~21.7, PFR ~16.4, aggression factor ~1.95), with no obvious leaks. The closest thing to GTO we'd get to measure.

We measured:

System 7 heuristic (pure node-locking): −9.75 bb/100.
Hybrid with M3 (reasoning the hard spots): −1.66 bb/100.

That is: our elaborate exploitation machine lost against the panel. The LLM improved it (from −9.75 to −1.66 — its reasoning in hard spots genuinely helped), but neither beat the opponent.

The lesson, in one sentence: you can't over-exploit someone who has no leaks. The whole node-locking apparatus — the archetypes, the Killer Parsley, the fine deviations — only pays when the opponent makes systematic errors. Against a near-GTO with no leaks, that machinery spins in a vacuum and even hurts you (you deviate from equilibrium for no reward).

And then, the twist. We tried a strategy so simple it's almost dumb: very wide ranges and steal-aggression (open far more hands, steal blinds relentlessly). Against the same panel, that wide strategy scored +119 bb/100 in the qualifiers.

Why? Because the panel, "GTO" as it was, had one exploitable property: it folded around 78% of its hands preflop. Even a disciplined bot is, structurally, too tight. And that's a leak — just not the kind the HUD spots hand by hand, but a structural one, punished with the oldest play in the book: stealing.

There's the project's nice irony: exploitation did win — but the right exploit was the simple, structural one (steal), not the elaborate multi-street read. We built a microscope to find subtle leaks when what paid was a hammer.

A mandatory note of statistical humility: bb/100 over 500 hands has a ±20 confidence interval. Both the −9.75 and the +119 are noisy in absolute terms. What was consistent across runs was the direction: against this panel, width ≫ node-locking. Treating a 500-hand number as a verdict is one of the easiest — and most expensive — mistakes to make.

Node-locking -9.75 vs Wide +119 bb/100 (CI +-20)

\text{CI}_{95\%} \approx \pm \frac{200}{\sqrt{N/100}} \text{ bb/100}

\text{CI}_{95\%} \approx \pm \frac{200}{\sqrt{N/100}} \text{ bb/100}

So where does all the exploitative machinery shine? Where there are real leaks: in the Playground and the Tournament, against real opponents who do call too much, fold too little, and bluff badly. There the HUD and node-locking stop spinning in a vacuum.

From lab to production: the tooling

An agent is nothing without the factory that produces it. Half the project is a control dashboard that organizes the agent's whole lifecycle into three zones:

LAB — where a strategy is born: a 13×13 grid (poker's 169 hands) to paint ranges by hand, pick engine (heuristic / hybrid), model, and HUD, and backtest several agents at once (with concurrency capped so as not to blow up the APIs or trigger rate-limits). Results are reported as bb/100 aggregated per strategy, with its confidence interval — not as a single run.
COACH — where the agent learns. A diagnosis of your play versus optimal (VPIP, PFR, c-bet… against reference bands) and an LLM coach that critiques your hands and proposes concrete tweaks. The latest addition: a hand-by-hand coach — you take your 10 most and least profitable hands, select them, and a reasoning model (DeepSeek-R1) tells you for each one whether you played it well or badly and where the leak is. (A fun detail: the reasoning model is noticeably more critical than the standard one; where the standard model applauds an all-in, the reasoning model spots that the overbet scared off the worse hands and only got called by the better ones.)
PRODUCTION — where the agent competes: live deployment, a real equity curve versus theoretical EV, a hand replayer to review every play, and a tracker that profiles opponents.

And all of it closes a self-improvement loop: propose a version → test it → compare against the control → deploy it → the coach critiques it → repeat. An agent, and a coach for that agent, in the same place.

LAB, COACH, PRODUCTION: the self-improvement loop

The jump to tournaments

Cash and tournaments don't play the same. In an MTT the blinds rise and your stack, measured in big blinds, shrinks — and the strategy has to change with depth. System 7 adapts its ranges by stack tier: deep (you play normal poker), medium, short, and very short (push/fold: shove or fold, no middle ground). At the final table, when the tournament narrows to two players, the engine detects heads-up dynamically and switches to a position-aware frame (the button acts last postflop, c-bets its range, barrels). The finest part is still pending — ICM (the fact that a chip's value isn't linear near the payouts) — but the tournament foundation is there.

What we take away

Beyond poker, the project leaves a few lessons that apply to any agent making decisions under uncertainty:

GTO and exploitation aren't rivals, they're layers. Equilibrium is your floor; exploitation is your ceiling. But exploitation only pays if the other side has leaks — and the right leak might be the simplest of all.
The LLM shines as judgment in the hard spots, not as a full controller. The cheap, deterministic thing handles 95%; the expensive, slow model is reserved for the 5% that truly needs it. And reasoning models add value where many variables are tangled.
Measuring honestly is half the work. A noisy number is not a verdict. Confidence intervals, direction over absolute value, and the discipline not to fool yourself are worth more than any strategy trick.
The meta-game is building the factory. The edge wasn't in a brilliant play but in the loop: authoring → backtest → comparison → deployment → coaching → repeat. An agent is only as good as the machinery that iterates it.

That, in the end, is what QuantArmy is about: agents for deciding under uncertainty. Poker turned out to be a perfect testing ground — bounded, measurable, and merciless with self-deception. It teaches you fast that your mental model isn't reality, and that the toughest opponent isn't beaten with more sophistication, but with the right idea.

Resources & links

💻 Code (open source): github.com/quantarmyz/system7-poker-arena — the heuristic engine, the LLM hybrid, the dashboard and all the tooling.
🃏 The platform: dev.fun · the poker Arena.
🧠 Reasoning models: DeepSeek · MiniMax.
📖 Part 2: we went heads-up, and the exploiter finally got paid — the diary continues.

The project is still live in the Arena. If you're into the intersection of AI, game theory, and decision-making under uncertainty, this is only the beginning.

System 7: enseñamos a una IA a explotar el póker — y lo que de verdad ganó fue otra cosa

Jesus Cuesta — Sun, 21 Jun 2026 20:44:05 GMT

Crónica técnica de construir un agente de póker para el Arena de dev.fun: el método heurístico, los LLM en la mesa, y los resultados honestos — incluidos los que no esperábamos.

El experimento

En dev.fun hay un sitio donde agentes de inteligencia artificial se sientan a una mesa de Texas Hold'em No Limit y juegan unos contra otros. No es una demo: hay manos reales, fichas reales, rivales reales (algunos humanos detrás de un bot, otros bots a secas) y, en los torneos, dinero on-chain en juego.

La pregunta que nos hicimos es engañosamente simple: ¿cómo construyes un agente que gane?

La respuesta corta, después de meses de código, miles de manos y un panel de control que acabó pareciendo la sala de un fondo cuantitativo, es esta: construimos una máquina sofisticadísima para explotar a los rivales… y lo que de verdad batió al adversario más duro fue una idea tonta de tan simple. Este post es la historia larga de cómo llegamos ahí, qué aprendimos del póker, de los LLM y de medir las cosas con honestidad.

dev.fun y el Arena

El Arena de dev.fun es una competición de agentes de póker. Tu agente es un programa que habla con una API en tiempo real. El bucle es siempre el mismo:

join — te sientas en una mesa.
pending-actions — la API te dice "es tu turno, esta es la situación" (tus cartas, el board, las apuestas, las fichas, quién ha hecho qué).
action — respondes: fold, check, call, bet, raise y cuánto.

python

# System 7 — game loop against the Arena API
client = ArenaClient(base_url, api_key=ARENA_API_KEY)
client.join(table_id)                          # 1. take a seat

while True:
    table = client.pending_actions(table_id)   # 2. "your turn, here's the situation"
    decision = hybrid.decide(table, deadline_s=30)
    client.action(table_id,                    # 3. respond: fold/check/call/bet/raise
                  action=decision["action"],
                  amount=decision.get("amount"))

El bucle de juego: join, pending-actions, action

Hay un deadline por decisión: si no contestas a tiempo, te hacen auto-fold. Es póker de verdad, con su reloj.

El Arena tiene tres "pistas", y entender la diferencia es clave porque cada una premia cosas distintas:

Eval — tu agente juega 500 manos contra un panel fijo de cinco bots de referencia. Es un benchmark: te puntúa en bb/100 (ciegas grandes ganadas por cada 100 manos, la métrica universal del póker) y te coloca en un ranking. No reparte premio y es de una sola tirada por agente. Aquí no te enfrentas a peces: el panel es lo más cercano a un rival "perfecto" que vas a ver.
Playground — PvP con dinero de juguete, gratis y continuo. Aquí sí hay rivales reales, con sus manías y sus fugas.
Tournament — un MTT (torneo multi-mesa) con entrada on-chain (cadena Monad, token MON): pagas una vez, recibes un stack fijo y compites en mesas de 2 a 6 jugadores que se van fundiendo hasta que queda un campeón.

Esa distinción — un rival casi perfecto (Eval) frente a rivales con fugas (Playground/Torneo) — es el eje de todo lo que viene.

Dos formas de jugar: GTO contra explotación

En el póker moderno conviven dos filosofías.

GTO (Game Theory Optimal). Juegas el equilibrio de Nash: una estrategia inexplotable. Hagas lo que hagas, no pierdes a la larga, porque mezclas tus jugadas de forma que el rival nunca puede sacarte ventaja. Es lo que aproximan los solvers y las redes entrenadas con Counterfactual Regret Minimization (CFR/DeepCFR). El GTO no intenta ganarte mucho; intenta no perder nunca.

Explotación. Renuncias a parte de esa coraza para castigar los errores concretos del rival. ¿Foldea demasiado a las subidas? Faroleas más. ¿Paga con cualquier cosa? Dejas de farolear y subes el valor. Es la forma en que piensan los profesionales humanos: el equilibrio es la base, pero el dinero está en las fugas del de enfrente.

Nuestra tesis de partida fue la del jugador explotador: usar el GTO como suelo defensivo y, a partir de ahí, desviarse agresivamente para exprimir cada debilidad. En la jerga, node-locking: "clavas" mentalmente el error del rival en un nodo del árbol de decisión y atacas justo ahí. Construimos un motor entero alrededor de esta idea. Se llama System 7.

GTO como suelo defensivo + desviaciones explotadoras

\sigma^* = \arg\min_{\sigma} \max_{\sigma'} u(\sigma', \sigma)

System 7: un motor explotador escrito a mano

Lo primero que hay que entender de System 7 es lo que no es: no es un LLM, y en el momento de decidir no llama a ninguna red ni a ningún modelo. Es Python puro y determinista —y código abierto en GitHub—. Recibe la mesa, hace cuentas y devuelve una jugada en milisegundos. Toda la "inteligencia" está codificada como reglas, destiladas de una metodología de juego explotador (la escuela de EducaPoker / "Estrategia Universidad", con la huella de jugadores como Raúl Mestre).

El motor se organiza en cuatro directivas.

D1 — Cuánto te fías de lo que ves (la muestra N). No puedes explotar a un rival del que no sabes nada. System 7 escala su agresividad según cuántas manos lleva observando al villano:

N < 100: ceguera. Ignora las estadísticas (puro ruido) y juega rangos estándar, respetando la agresión rival.
100 ≤ N < 500: empieza a perfilar por el gap entre VPIP (con qué frecuencia mete fichas) y PFR (con qué frecuencia sube). De ahí salen los arquetipos: Nit (tightísimo), TAG (sólido), LAG (agresivo y suelto), Calling Station (paga todo) y Maníaco. A cada uno se le juega distinto: a la station, tolerancia cero a los faroles y subir el valor; al nit, robarle las ciegas sin parar.
N ≥ 500: node-locking fino. Si el rival foldea a las resubidas más del 55% de las veces, le 3-beteamos cualquier mano con un As bloqueador. Si abandona el flop ante la apuesta de continuación más del 45%, le apostamos el 100% de nuestro rango con un sizing pequeño.

python

def _archetype(st: dict) -> str:
    """Classify a villain from agent-stats. N-gated by sampleSize."""
    n = int(st.get("N") or 0)
    if n < 500:                    # too few hands -> don't trust the read
        return "UNKNOWN"
    vpip, pfr = _pct(st["vpid"]), _pct(st["pfr"])
    gap = vpip - pfr
    if vpip >= 30 and gap >= 15:   return "STATION"   # calls everything
    if vpip >= 40 and pfr >= 30:   return "MANIAC"    # ultra-aggressive
    if vpip <= 15 and gap <= 6:    return "NIT"       # only premiums
    if vpip >= 26 and pfr >= 20:   return "LAG"        # loose-aggressive
    return "TAG"                                          # solid default

D2 — Qué tienes y dónde estás (la geometría). En lugar de pensar "tengo pareja de ases", System 7 clasifica la mano por su encaje relativo con el board: MMF (manos monstruo: sets, colores, escaleras), MF (manos fuertes: top pair con buen kicker, overpair), MM (manos medias), MD (manos débiles) y Aire/Proyectos. Y clasifica la mesa por textura: seca, semi-coordinada, coordinada y extremadamente coordinada (donde hasta un set baja de categoría porque el peligro es enorme). Encima añade la dinámica de las cartas que van saliendo: una carta scary (un As, un K que cierra un color) favorece al agresor y baja el umbral para farolear; una carta defensiva frena la agresión y pide control del bote.

D3 — La aritmética implacable (PME vs PER). Aquí no hay corazonadas. Calcula el PME (las pot odds: cuánto arriesgas frente a lo que puedes ganar) y lo compara con el PER (tu equity real, contando outs ajustadas por la textura — un proyecto de color vale menos si el rival puede tener uno mayor; las sobrecartas valen casi cero en una mesa muy coordinada). La regla es un mandato: si tu equity no cubre las pot odds, foldeas, salvo que el HUD certifique que el rival se va a tirar (entonces el farol tiene su propio valor).

python

def _pme(call_chips: int, pot: int) -> float:
    """Pot odds: what you risk vs what you can win."""
    tot = pot + call_chips
    return (call_chips / tot) if tot > 0 else 1.0

def _per(adj_outs: int, board_len: int) -> float:
    """Adjusted-outs equity (rule of 4/2)."""
    mult = 4 if board_len == 3 else (2 if board_len == 4 else 0)
    return min(0.95, adj_outs * mult / 100.0)

\text{PME} = \frac{\text{Call}}{\text{Pot} + \text{Call}}

\text{PER}_{\text{flop}} = \frac{\text{Outs} \times 4}{100}, \quad \text{PER}_{\text{turn}} = \frac{\text{Outs} \times 2}{100}

\text{Call if } \text{PER} \geq \text{PME}

D4 — El postflop y el "Perejil Asesino". Cuando el SPR (la relación entre el bote y las fichas que quedan) baja de 3, te comprometes con cualquier mano fuerte: el control del bote desaparece, vas con todo. Y para los faroles está el protocolo bautizado como "Perejil Asesino": un farol condicionado. Solo subes de farol si se cumplen condiciones (debilidad evidente del rival, un salvavidas de 8 a 10 outs reales que respalda la jugada por si te pagan, ajustes por número de rivales…). Nunca se farolea por impulso con basura; cada agresión va respaldada por matemática o por una fuga documentada.

Y por encima de todo, el HUD: un módulo que lee en vivo las estadísticas de los rivales (tamaño de muestra, VPIP, PFR, 3-bet, fold-to-cbet, showdown…), los clasifica en arquetipos y alimenta las desviaciones de la D1. El HUD es lo que convierte a System 7 de un robot disciplinado en un explotador.

python

# Strategy as versioned data — strategies/<name>.json
SIZING = {
    "dry":     {"flop": 0.33, "turn": 0.50, "river": 0.60},
    "semi":    {"flop": 0.50, "turn": 0.60, "river": 0.66},
    "coord":   {"flop": 0.66, "turn": 0.75, "river": 0.75},
    "extreme": {"flop": 0.75, "turn": 0.80, "river": 0.80},
}
# Toggle strategy: S7_STRAT=s7-opus uv run run_hybrid_system7.py

Es, en resumen, un intento serio y completo de codificar cómo piensa un profesional explotador. Funcionaba. La pregunta era: ¿ganaba?

Meter un LLM en la mesa

El motor heurístico es rápido y barato, pero tiene un techo: las reglas, por finas que sean, no cubren todos los spots raros. Así que probamos un motor híbrido: la heurística resuelve los spots triviales (la inmensa mayoría) y, en los spots difíciles, le pasa la decisión a un LLM que razona la jugada.

Usamos MiniMax M3, un modelo de razonamiento, con el propio System Prompt del método (las cuatro directivas, traducidas a lenguaje, más un contrato de salida en JSON). El LLM recibe la situación reconstruida y devuelve una jugada justificada. ¿El coste? Unos 27 segundos por decisión y un consumo de tokens nada trivial — por eso solo entra en los spots que de verdad lo merecen (gating por dificultad).

python

def _is_hard(table: dict, deadline_s: float) -> bool:
    """Gate: True => worth a slow LLM call (~27s)."""
    if deadline_s < 30:            # M3 takes ~27s; don't risk auto-fold
        return False
    board = list(table.get("boardCards") or [])
    if not board:                  # preflop: position ranges suffice
        return False
    texture = H._texture(board)
    strength = H._strength(hole, board, texture)
    outs = H._adjusted_outs(hole, board, texture)
    if strength == "MMF":         # clear value / commit
        return False
    if strength == "MM" or (strength in ("AIR", "MD") and outs >= 4):
        return True               # thin value / semi-bluff / give-up
    return False

Aquí aparece un tema que se ha vuelto central en todo el ecosistema de IA: los modelos de razonamiento. Un M3 o un DeepSeek-R1 "piensan en voz alta" antes de responder, lo que les da una ventaja real en problemas con muchas variables interdependientes — y el póker, en sus spots difíciles, es exactamente eso. Más adelante esto reaparece de forma elegante en nuestro propio coach.

Lo que pasó (y lo que no esperábamos)

Aquí viene la parte honesta, que es también la más interesante.

El panel del Eval — ese rival "casi perfecto" — resultó ser cinco clones idénticos de un bot DeepCFR: un TAG equilibrado (VPIP ~21.7, PFR ~16.4, factor de agresión ~1.95), sin fugas evidentes. Lo más parecido al GTO que íbamos a poder medir.

Medimos:

System 7 heurístico (node-locking puro): −9.75 bb/100.
Híbrido con M3 (razonando los spots difíciles): −1.66 bb/100.

Es decir: nuestra elaboradísima máquina de explotar perdía contra el panel. El LLM la mejoraba (de −9.75 a −1.66 — su razonamiento en spots difíciles ayudaba de verdad), pero ninguno de los dos batía al rival.

La lección, en una frase: no puedes sobre-explotar a alguien que no tiene fugas. Todo el aparato de node-locking — los arquetipos, el Perejil Asesino, las desviaciones finas — solo cobra cuando el rival comete errores sistemáticos. Contra un near-GTO sin leaks, esa maquinaria gira en el vacío e incluso te hace daño (te desvías del equilibrio sin recompensa).

Y entonces, el giro. Probamos una estrategia tonta de tan simple: rangos muy anchos y agresión de robo (abrir muchas más manos, robar ciegas sin freno). Contra el mismo panel, esa estrategia wide puntuó +119 bb/100 en las clasificatorias.

¿Por qué? Porque el panel, pese a ser "GTO", tenía una propiedad explotable: foldeaba alrededor del 78% de sus manos preflop. Hasta un bot disciplinado es, estructuralmente, demasiado tight. Y eso es una fuga — solo que no del tipo que el HUD detecta mano a mano, sino una estructural, que se castiga con la jugada más vieja del libro: robar.

Ahí está la ironía bonita del proyecto: la explotación sí ganó — pero el exploit correcto era el simple y estructural (robar), no la elaborada lectura multi-calle. Construimos un microscopio para encontrar fugas sutiles cuando lo que pagaba era un martillo.

Una nota de humildad estadística obligatoria: bb/100 sobre 500 manos tiene un intervalo de confianza de ±20. Tanto el −9.75 como el +119 son ruidosos en valor absoluto. Lo que sí fue consistente entre tiradas fue la dirección: contra este panel, anchura ≫ node-locking. Tratar un número de 500 manos como veredicto es uno de los errores más fáciles — y más caros — de cometer.

Node-locking -9.75 vs Wide +119 bb/100 (CI +-20)

\text{CI}_{95\%} \approx \pm \frac{200}{\sqrt{N/100}} \text{ bb/100}

\text{CI}_{95\%} \approx \pm \frac{200}{\sqrt{N/100}} \text{ bb/100}

¿Y dónde brilla, entonces, toda la maquinaria explotadora? Donde hay fugas de verdad: en el Playground y el Torneo, contra rivales reales que sí pagan de más, foldean de menos y farolean mal. Ahí el HUD y el node-locking dejan de girar en el vacío.

Del laboratorio a producción: el tooling

Un agente no es nada sin la fábrica que lo produce. La mitad del proyecto es un panel de control que organiza todo el ciclo de vida del agente en tres zonas:

LAB — donde naces una estrategia: una rejilla 13×13 (las 169 manos del póker) para pintar rangos a mano, elegir motor (heurístico / híbrido), modelo y HUD, y backtestear varios agentes a la vez (con la concurrencia capada para no reventar las APIs ni provocar rate-limits). El resultado se reporta como bb/100 agregado por estrategia, con su intervalo de confianza — no como un run suelto.
COACH — donde el agente aprende. Un diagnóstico de tu juego frente al óptimo (VPIP, PFR, c-bet… contra las bandas de referencia) y un coach LLM que critica tus manos y propone ajustes concretos. Lo último que añadimos: un coach mano a mano — coges tus 10 manos más y menos rentables, las seleccionas, y un modelo de razonamiento (DeepSeek-R1) te dice de cada una si la jugaste bien o mal y dónde está la fuga. (Curiosidad: el modelo de razonamiento es notablemente más crítico que el normal; donde el modelo estándar aplaude un all-in, el de razonamiento detecta que ese overbet espantaba las manos peores y solo cobraba a las mejores.)
PRODUCCIÓN — donde el agente compite: despliegue en vivo, curva de equity real frente a la EV teórica, un reproductor de manos para revisar cada jugada, y un tracker que perfila a los rivales.

Y todo esto cierra un bucle de auto-mejora: propones una versión → la testeas → la comparas contra el control → la despliegas → el coach la critica → repites. Un agente, y un entrenador para ese agente, en el mismo sitio.

LAB, COACH, PRODUCCION: el bucle de auto-mejora

El salto al torneo

El cash y el torneo no se juegan igual. En un MTT las ciegas suben y tu stack, medido en ciegas grandes, se encoge — y la estrategia tiene que cambiar con la profundidad. System 7 adapta sus rangos por tramos de stack: profundo (juegas póker normal), medio, corto, y muy corto (push/fold: o vas con todo o te tiras, sin medias tintas). En la mesa final, cuando el torneo se reduce a dos jugadores, el motor detecta el heads-up dinámicamente y cambia a un marco consciente de la posición (el botón juega último postflop, c-betea de rango, barrelea). Queda pendiente lo más fino — el ICM (que el valor de una ficha no es lineal cerca de los premios) — pero la base de torneo está.

Lo que nos llevamos

Más allá del póker, el proyecto deja unas cuantas lecciones que aplican a cualquier agente que tome decisiones bajo incertidumbre:

GTO y explotación no son rivales, son capas. El equilibrio es tu suelo; la explotación es tu techo. Pero la explotación solo paga si el de enfrente tiene fugas — y la fuga correcta puede ser la más simple de todas.
El LLM brilla como juicio en los spots difíciles, no como controlador total. Lo barato y determinista resuelve el 95%; el modelo caro y lento se reserva para el 5% que de verdad lo necesita. Y los modelos de razonamiento aportan donde hay muchas variables enredadas.
Medir con honestidad es la mitad del trabajo. Un número ruidoso no es un veredicto. Los intervalos de confianza, la dirección frente al valor absoluto, y la disciplina de no auto-engañarse valen más que cualquier truco de estrategia.
El meta-juego es construir la fábrica. El edge no estuvo en una jugada genial sino en el bucle: autoría → backtest → comparación → despliegue → coaching → repetir. Un agente es tan bueno como la maquinaria que lo itera.

Eso, al final, es de lo que va QuantArmy: agentes para decidir bajo incertidumbre. El póker resultó ser un campo de pruebas perfecto — acotado, medible y despiadado con el autoengaño. Te enseña rápido que tu modelo mental no es la realidad, y que el rival más duro no se gana con más sofisticación, sino con la idea correcta.

Recursos y enlaces

💻 Código (open source): github.com/quantarmyz/system7-poker-arena — el motor heurístico, el híbrido con LLM, el dashboard y todo el tooling.
🃏 La plataforma: dev.fun · el Arena de póker.
🧠 Modelos de razonamiento: DeepSeek · MiniMax.
📖 Parte 2: nos fuimos al heads-up, y el explotador por fin cobró — el diario continúa.

El proyecto sigue vivo en el Arena. Si te interesa el cruce de IA, teoría de juegos y decisión bajo incertidumbre, esto no ha hecho más que empezar.