Planner Actor Poker

browser_use posted "Luna (planner) -> Jev (actor) playing poker and winning" (source post, 2026-09-24). This project is our version of that split:

• A planner reads the opponent's tendencies every 25 hands and writes a short strategy note.
• An actor makes every betting decision from small typed questions.

We measure whether the actor wins, and whether the planner helps.

• Game: heads-up fixed-limit Texas Hold'em, chosen over no-limit so every decision is fold / check-call / bet-raise, with lower variance. Blinds are 1/2 chips (1 bb = 2 chips). Bets are 1 bb on preflop and flop and 2 bb on turn and river, capped at 4 bets per street.
• Code facts: the made hand, named ("top pair", "overpair", "AK suited"); draws; equity against a random hand from Monte Carlo, bucketed into words ("strong", "weak"); whether calling is profitable on raw equity; position; street; the opponent's last action. No raw cards reach the model. Only named categories do, so identical situations share one cached answer. That is the dino-runner lesson.
• Actor: one request per decision, two Nouls. keep_playing (continue rather than fold?) is asked only when there is something to call. aggress (bet or raise now?) is asked only when a raise is legal. Code composes the answer: fold if keep_playing < 0.5, raise if aggress ≥ 0.5, else check or call.
• Planner, every 25 hands. It reads code-counted opponent stats (fold-to-bet rate, raise share, showdown rate) and picks one of 5 strategy notes, which goes into the actor's state. There are three variants:
  • (a) heuristic: deterministic rules;
  • (b) openjev: a Choice over the same 5 notes. openjev can't write free text, so the planner picks a note from a menu. A text-writing planner like browser_use's Luna would be a separate LLM, which we don't use: no paid models;
  • (c) none: the actor-only ablation.
• Opponents: random; tight_passive (plays about 20% of hands, rarely raises); equity (raises at ≥65% equity vs a random hand, calls when equity beats the pot odds).
• Reference hero: the same equity bot, as a code-only baseline with no model.
• Duplicate format. Every deal is played twice with seats and cards swapped, so card luck mostly cancels. The equity-bot mirror match scores exactly 0.0 ± 0.0, which checks the engine.

Why decomposing helps. Odds, equity and hand reading are code. The model makes two yes/no judgments per spot, and the planner changes only one field of the state. Each piece can be ablated alone, which is how we found the planner was hurting.

bb/100 for our hero, with 95% confidence intervals. 200 duplicate deals = 400 hands per cell, 12 cells, 4,800 hands in all:

What it shows:

• The actor alone wins against all three bots, and every interval is clear of zero. Against tight-passive and equity it beats the code-only equity bot playing the same seats and cards (+38.9 vs −4.4, and +67.8 vs 0.0).
• Against random it wins less than the equity bot does (+68.8 vs +103.2). The actor folds more marginal hands than a pure pot-odds rule.
• The planner made things worse. Against the equity bot, the planner's read was "call_down_maniac": the bot raises a lot, but only with strong hands. That note turned +67.8 into −4.4. Against tight-passive, "exploit_folds" (bluff more) turned +38.9 into +15.2.
• The planner reads frequencies, not hand strength. It sees a high raise share and concludes "maniac", so its advice is wrong for a value-raiser.
• The openjev planner picked the same note as the heuristic in at least 46 of 48 design steps, so it made the same mistake. It's cheap (16–43 calls per 400 hands), but it isn't smarter here.
• Honest takeaway: a planner on top added no edge here. It needs a better read (showdown hand strength as well as frequencies) before it helps. The actor-only ablation is the one to beat.
• The notes each planner used are listed per cell in results/real_suite_200deals.json.

REAL JEV (OpenCode Zen free, jev-1.13-free): not run on real Jev: exceeds free-tier budget. No retry is scheduled. The saved results contain the openjev pass; its measured sample and interval are generated above. Free-route evaluation is reserved for the frozen held-out projects.

• openjev suite: 2,072 requests, 698,491 input tokens, $0. That's about 330 tokens per decision.
• Cache: 4,800 hands needed only 2,072 requests, because the state has no raw cards and identical situations reuse the cached answer.
• Latency: median 335–385 ms per decision.
• At TypeSafe's list price ($0.042 per 1M input tokens) the whole suite would cost about $0.05.

• Better-calibrated keep_playing / aggress should mostly show up as fewer marginal folds. See the REAL JEV section for what the small real-Jev sample showed.
• The planner problem is a design problem. A different model would get the same frequency-only read. The next version should feed the planner showdown hand strength and use the "add a question" fix: a Noul like "are this opponent's raises mostly value?" rather than a raise-frequency rule.

Inspired by browser_use's "Luna (planner) -> Jev (actor) playing poker and winning" post (2026-09-24): claims unverified. The numbers on this page are ours, from our own simulation.

• Latent Space: games are a named family. Put state in as JSON, keep facts in code, and ask small independent questions (both Nouls travel in one request). Don't call the model inside a tight loop.
• building-with-jev (dbreunig): "the final decision is wrong while each answer is right → change the policy in code". That describes the planner, which is policy.
• browser_use (the post above): the planner/actor split itself.

cd samples/planner-actor-poker && ./run.sh      # = poker.py --suite --deals 200 --threads 3