chess-gpt-insufficient-material-thinking

chess-gpt-insufficient-material-thinking

peterwooden/chess-gpt-insufficient-material with a thinking display. model.onnx and vocabulary.json are copied byte for byte from that package at 590ff7774d63a6f26d62407b4f61189a027fb6b6; only the entrypoint differs, and the PUCT search itself is untouched — every constant, the simulation loop, and the argmax-visits choice are identical, and the display is a pure read of the root's visit counts.

Source: adapters/lab-fullbudget/entry-v3-thinking.source.js.

The entrypoint emits the tournament thinking-display commands documented in docs/TOURNAMENT_RULES.md (2026-08-08):

• Candidate arrows for the most-visited root moves, intensity scaled by visit share against the leading move (floor 0.35, so the fourth candidate stays visible while the leader dominates). MCTS visit counts carry real dynamic range and move through the search, so they can be shown honestly — unlike a beam of value-head scores, which span a few hundredths and would render identically.
• Final arrow at full intensity for the move actually returned.

Redraws are throttled to a bounded count across the clock rather than a fixed interval: at roughly 250 simulations per 10 s move, emitting per simulation would be about four times the runner's 64-per-500 ms limiter, and a fixed interval would breach the same caps on a longer clock instead. Measured cost is 23–24 commands per move, peaking at 4 per 500 ms.

Move selection is unchanged. At limits low enough that the loop runs one or two simulations — a fully deterministic regime — both packages choose identical moves across 5 positions; at a 10 s clock both return the same move on 8 consecutive runs of the same position. The search spends its whole clock by design, so at intermediate limits the published package already disagrees with itself run to run; that sensitivity is its own, not the display's.