Jev vs Jev in Gomoku

About 500 ms per move is what the log shows (a 25-move game in 13,913 ms) against a claimed 50 to 500 ms band, so it lands at the slow end. The author estimates 110 to 130 ms of that is network latency to US West Coast servers. It is one game, in Japanese, and preliminary: a single data point at the top of the band, not a benchmark.

Not the way it looks. Confidence swung from 1 on the first move to 0.12 mid-game, then 0.9 on move 19 and 0.83 on the winning move, and plenty of low-confidence moves were fine. A calibrated probability is not a win probability, so do not threshold on it as if it were, and do not read a low number as an error.

Input tokens grew from about 746 at move 1 to roughly 3,052 by the end, because the ASCII board and move history are resent in full each turn, and output tokens grew with them. At list pricing that stays trivial, but the growth is linear in game length, which matters for any harness that keeps replaying state.

Effectively yes, and it is stated. A rules-based engine enumerates only legal empty cells and precomputes line-run hints such as 2o, 3o, WINS and BLOCK, then Jev picks among those options. So the model chooses among pre-computed candidates instead of searching, and the author notes the filtering is where tuning headroom sits. Code is at mizchi/jev-gomoku.

A single Choice question over the currently legal empty cells. The state carries the game name, a 15 board size, which stone Jev plays, the rules, a notation legend explaining hints such as 2o, 3o, WINS and BLOCK, the ASCII board, the move count and the recent moves. Each candidate cell's criteria describe your best line against the opponent's best line, so Jev picks among pre-filtered options rather than searching.

That programmers will probably prefer a structured agent like Jev over an existing chat assistant. His framing is that Jev is not merely a fast model: it gains speed and accuracy by deliberately constraining the output, so the real design work is in how you structure those constraints. He labels the experiment preliminary and rapid, and points at the code at mizchi/jev-gomoku.

Per move it records the move number, stone, chosen cell, elapsed_ms, confidence, a fallback boolean, whether the move won, and input and output tokens. Those fields are what let the author separate model time from network latency and watch confidence and token counts change as the game progresses.