Jobs & the queue

A Job is a batch of solves: one set of settings (ranges, bet sizes, pot, stack, rake) applied to a list of flop boards. Jobs let you solve hundreds of boards overnight without babysitting each one.

Creating a job

Open the Jobs tab and go to the Single Job sub-tab. A job captures:

• Ranges — OOP and IP ranges (same syntax as the single-solve range editor). You can paste from other tools.
• Boards — a list of flops to solve. Pick a preset (25 representative flops, 74, 184, or the full 1755) or enter custom boards, one per line (e.g. As Kh Td).
• Bet sizing — all the same fields as the single-solve tree config: bet sizes, raise sizes, donk sizes, max raises, auto all-in threshold.
• Pot and stack — starting pot and effective stack in chips.
• Rake — rake rate and cap.
• Output folder — where .art solution files are saved.
• Naming pattern — controls the filename. Must contain <board>, which is replaced with the canonical flop string (e.g. AsKhTd). Default is just <board>, producing files like AsKhTd.art.

Click Create Job to add it to the queue.

The queue

Switch to the Queue sub-tab to see all your jobs. Each row shows the job name, board count, and progress (done / failed / pending).

• Drag to reorder — jobs solve in queue order, top to bottom.
• Run — starts solving from the first pending spot in the first queued job.
• Pause — pauses after the current board finishes. Resume picks up where it left off.
• Cancel — stops the entire run. Boards already solved are kept on disk.
• Edit — opens a job back in the Single Job editor so you can modify it.

The queue is sequential by design. The solver already uses all your CPU cores on one board, so running two solves in parallel would just slow both down.

While running, the queue shows live progress: current job, current board, iteration count, exploitability, elapsed time, average time per spot, and an ETA for the remaining spots.

Resume behavior (skip existing solves)

By default, Settings → Skip existing solves is on. When you run a job, any board whose .art file already exists on disk is skipped. This means:

• If a batch is interrupted (crash, cancel, power loss), re-running it picks up where it left off.
• If you delete a job and re-create it with the same output folder, already-solved boards are not re-solved.

Turn this off if you want to force a full re-solve — for example, after changing ranges.

Per-job 16-bit and low-memory toggles

Each job has its own checkboxes for:

• 16-bit compression — solve with half-precision storage. Uses roughly half the RAM per board. See Memory: big spots & fallbacks.
• Low-memory fallback — if a board does not fit even with 16-bit, fall back to river bucketing (grouping similar-strength river hands). On by default.

In batch mode, these work automatically. If a board does not fit at full precision, the runner silently falls back to 16-bit (if allowed). If it still does not fit, it falls back to river bucketing (if allowed). The run log records exactly what happened for each board.

This is the key difference from single-solve mode: single solves tell you to enable the checkbox yourself, while batch jobs handle it silently so an overnight run does not stop on one oversized board.

Run log

The Log sub-tab shows a per-board record of the most recent run: job name, board, iterations, exploitability, time, and whether any fallback was used. Use it to audit your results after a batch completes.