Neural robot move latency is an order of magnitude behind the gnubg robots

[nodots]

Summary

The neural robot is noticeably slower per move than the gnubg-backed robots — not marginally, but by roughly an order of magnitude. Since both robot types run through the same platform orchestration, the difference players feel is the engine decision latency itself.

Measurements (2026-08-03, against the public engine)

probe	latency
GET /v1/health (network + TLS baseline)	~0.47 s
POST /v1/move, opening position, 5 different rolls	1.75–2.0 s each

Opening positions are the cheap case: eval cost varies ~100x by game phase, and the engine's counted eval budget binds hardest on heavy-contact middlegames, where moves run multiple seconds. In a July protocol head-to-head vs gnubg, 2 of 38 moves timed out entirely. gnubg at the same search depth (2-ply) answers in tens to low hundreds of milliseconds.

Perceptually: under ~300 ms reads as instant (the gnubg bots), 1–2 s reads as deliberate, 3+ s reads as slow. The neural robot sits in the deliberate-to-slow band, and it is slowest exactly in tense positions where the player is most engaged. Over a game this adds 30–60+ seconds of waiting.

Why (architecture level)

• The 2-ply search is single-threaded JavaScript driving ONNX inference; nothing inside a move decision runs in parallel.
• The eval budget is counted (leaf evaluations), not timed — it bounds work per move, not wall clock, so expensive-eval positions take as long as they take.
• The engine serves from a single cloud core that is measurably slower than a desktop core, and the search cannot use more than one.
• Every robot move is an HTTP round trip to the engine (~0.5 s before any search starts).

Work items

• Instrument robot turn latency per bot type in the platform (p50/p95), so orchestration overhead and engine compute are separated with production data rather than probes.
• Engine-side: continue eval-path speedups (a prior profiling pass removed a redundant shot sweep for a 15.8x gain on 2-ply search; the remaining cost is now dominated by leaf evaluation throughput).
• Engine-side: phase-aware budget allocation — spend less on quiet positions, more on contact, within the same worst-case bound.
• Decide a latency target for robot moves (e.g. p95 under 2 s) and track it here.

Non-goals

This issue is about decision latency, not playing strength. Strength figures for the served configuration are published separately in the engine's methodology docs.