Chess as autocomplete

In my previous article, we built a mental model of LLMs as autocomplete.

As a quick recap: LLMs are given the sentence

and simply predict the next token.

So in theory, if we frame the game of chess as a language autocomplete problem, we should be able to train an LLM to play chess.

Can we train a transformer to play chess blindfolded by autocompleting the language of chess?

Blindfold chess is a variant of chess where the players do not see the board. Someone reads out the moves to them, and they reply by announcing their own next move out loud.

This sounds exactly like the framing we want: moves in, moves out.

The most commonly used language to represent chess games is called Standard Algebraic Notation (SAN). For example, the Italian Game starts with the moves

1. e4 e5 2. Nf3 Nc6 3. Bc4

And can be understood as follows:

If you wish to explore SAN in detail you can go to this chess.com article.

Why and what?

…general methods that leverage computation are ultimately the most effective, and by a large margin.

Richard Sutton, The Bitter Lesson, 2019

This project takes that idea to an extreme. Karvonen (2024) showed that a small GPT trained on move text alone learns the board well enough to be probed for it, at 16 million games and 25M parameters. As far as I know nobody has run that idea at scale: a general model (a standard model with nothing chess-specific added: no board, no search, no extra heads) trained on a massive corpus of human games. One transformer, trained on nearly 1.8 billion human games, about a hundred times that corpus.

Predicting the next move in a game is the same problem an LLM solves predicting the next word, so I borrow the whole apparatus: a decoder-only transformer (the model family behind ChatGPT) trained with the recipe modern LLMs are built with. The interface is tokens in, tokens out, nothing else: the model only ever sees a stream of moves and learns to continue it.

The model must learn to calculate everything else: where every piece sits, whose turn it is, which moves are even legal. It reconstructs all of it from the move stream alone. That is blindfold chess in the most literal sense.

Hardware and compute

This being a personal project, I do not have access to large computational resources. I have a personal computer with an Intel i5-13500 CPU, an NVIDIA RTX 4070 Ti Super (16 GB) GPU, 16 GB of RAM, and under 1 TB of available storage. This will impact several engineering choices made throughout the project. Partway through the project I unexpectedly gained access to a couple of VMs with A100 and H100 GPUs, but by then those choices had already been shaped by the hardware above.

Pre-training

The goal of pre-training our chess autocomplete is to learn the language of chess, the rules of the game. We will measure the performance of a pre-trained model with two metrics:

• Valid move probability mass (VPM): the sum of the probabilities the model assigns to all legal moves in a position, averaged over all positions. In plain terms: what fraction of the model's probability lands on moves that are actually legal. A legal move in this definition includes a piece move or a valid draw claim (threefold repetition). Predicting a terminal state like checkmate incorrectly is also considered an invalid move. A model that has fully learned the rules would score 100%.
• Game-end prediction accuracy (GPA): measures the accuracy of the model when predicting how a game ended (checkmate, stalemate, draw by repetition, fifty move rule). How often does the model correctly predict when and how the game ends.

For move validity, the important number is the valid move probability mass and not the top-1-legal rate. This is because we may sample from the output distribution to choose the next move, and this metric correctly shows the probability of sampling an illegal move.

For game end prediction however, the correct metric is how often the most likely output is the correct game end prediction. Whenever the model output is a game end prediction, we never sample; we always pick the most likely one. That is why accuracy is the right metric here, not probability mass.

These two metrics will give us a way to evaluate how well the model has learned the rules of chess. Our goal is to reach 100% VPM and 100% GPA.

We will also get a sense of the model's playing strength by playing it against the Stockfish 18 chess engine at a range of strength levels. This is not an explicit optimization target: the goal of this project is not to build the highest-rated chess model, only to understand how well a model trained as pure autocomplete ends up playing.

The dataset

The open-source online platform Lichess publishes the games played on their platform as an open database. This database contains (as of May 2026) a total of 7,863,012,346 rated chess games, spanning over 13 years, from complete beginners to grandmasters. This database has a total compressed size of 2.49 TB.

Elo peaks at around 1500, which may be because players start with 1500 Elo on Lichess. The most popular time controls are blitz and bullet, followed by rapid, ultrabullet, and classical.

Data processing

The games in the Lichess open database are stored as zstd compressed PGN (portable game notation) files. A PGN file is a commonly used text format for storing both metadata and moves from one or more games of chess. Below is an example of the PGN of a chess game.

[Event "Troll Masters"]
[Site "Gausdal NOR"]
[Date "2001.01.05"]
[Round "1"]
[White "Edvardsen,R"]
[Black "Carlsen,Magnus"]
[Result "1/2-1/2"]
[WhiteElo "2055"]
[BlackElo ""]
[ECO "D12"]

1.d4 Nf6 2.Nf3 d5 3.e3 Bf5 4.c4 c6 5.Nc3 e6 6.Bd3 Bxd3 7.Qxd3 Nbd7 8.b3 Bd6
9.O-O O-O 10.Bb2 Qe7 11.Rad1 Rad8 12.Rfe1 dxc4 13.bxc4 e5 14.dxe5 Nxe5 15.Nxe5 Bxe5
16.Qe2 Rxd1 17.Rxd1 Rd8 18.Rxd8+ Qxd8 19.Qd1 Qxd1+ 20.Nxd1 Bxb2 21.Nxb2 b5
22.f3 Kf8 23.Kf2 Ke7  1/2-1/2

The moves in a PGN file are stored in SAN. SAN is convenient for chess players, but it is not the most convenient representation for this project, for reasons we get into when choosing the model's input representation.

Binary game representation

I designed a compact 16-bit binary format: every move fits in exactly two bytes, can be decoded on its own without replaying the game, and any game can be read straight out of the middle of a file. The full bit layout (and the two companion files that make individual games randomly addressable) are in the deep-dive below.

The September 2025 Lichess open database file has a total of 87,049,890 games, a compressed size of 28.3 GB, and an uncompressed size of about 189 GB. Encoding it produces an 11 GB .bin, a 0.7 GB map, and a 0.5 GB metadata file, about 12.5 GB in total. This is about a 15x reduction from the uncompressed size, and 2x reduction from the compressed size.

A baseline, we have to start somewhere

The initial goal is to see whether this can work at all. I designed a simple transformer, a simple tokenization strategy and a simple training procedure.

Choosing an input representation for the transformer

The most obvious representation would be to use SAN directly: map every possible SAN move to its own token. I discarded this early, for two reasons.

First, SAN is not self-contained. A move like Nxf4 tells you a knight captured on f4, but not which knight or from where; to recover that you have to replay the game on a board. I wanted a representation that makes the piece, the from-square and the to-square explicit, keeping our options open for the rest of the project.

Second, the same physical move can be written several different ways depending on what else is on the board, and if it gives check, a + is appended, adding yet another spelling like Nxf4+. Mapping SAN straight to tokens would force the model to learn a separate token for each spelling, although they all mean the same move:

For simplicity's sake I opted to start by using our 16-bit binary game representation, where each of the 2^16 possible moves represents its own token. This also comes with the added benefit of not needing a tokenizer, since the binary move representations are our tokens. We only need to add a <|game_start|> token.

A tokenized game ready to be processed by our model looks like:

The model never receives <|unknown|> as a target. This is because <|unknown|> can mean that a player resigned, a draw was agreed, a player timed out, etc. We do not want the model to predict any of these. Who wants a chess engine that resigns?

Model definition and training (v0)

I opted to start with a simple decoder only transformer following the same architecture as GPT-2 with the same hyperparameters as the smallest GPT-2 model with some minor modifications. The model is trained on the first 64 half moves (plies) of each game, for a total of 360k steps: 138 million games, 8.8 billion tokens, 36.7 hours of training.

At the end of the 360k steps the model reached 99.4% VPM and 95.3% GPA on the validation set:

Playing strength over 100 games per opponent, scored as an Elo performance rating (the Elo you would need to score that result against that opponent):

A rating around 1490. The language of chess has been learned, mostly. Now to improve on it.

Improving the baseline model

The baseline gave us a working training pipeline and several places to improve it. I followed the process of creating hypotheses of what could improve the model, then testing these hypotheses with real training runs. Testing different configurations one by one and evaluating their performance is referred to as an ablation sweep. Below are the improvements made.

A vocabulary of impossible moves

Our binary representation gives us 65,536 possible tokens, but the vast majority of them are moves that can never be played: a pawn moving from a1 to h8, a king jumping across the entire board, a rook moving diagonally. If we only keep the moves that can actually occur on a chess board we are left with 4,128 tokens. I call this the realizable vocabulary.

Switching the input to the realizable vocabulary reduced the number of parameters from 186M to 138M. Switching the output to this vocabulary further reduced the number of parameters down to 91M. Over half of the baseline model was spent embedding/decoding tokens that can never appear in a game.

The sweep confirmed it. The realizable input/output combination was the best of every encoder/decoder tested.

Training on full games

The initial model was trained on the first 64 half moves of each game. We consider full games to be up to 200 half moves as the vast majority of games in the dataset are finished long before that. Real games vary a lot in length, so the pipeline has to handle variable-length sequences without wasting compute on padding. The approach I chose packs games of different lengths into a single padding-free stream, so every position the GPU touches is a real move (the mechanics are in the deep dive below). This change never entered the sweep: seeing whole games is a prerequisite for learning full games, not a tuning knob to validate.

flash_attn_varlen_func(
    q, k, v,
    cu_seqlens_q,
    cu_seqlens_k,
    max_seqlen_q,
    max_seqlen_k,
    causal=True,
)

Adding game metadata

A game between two 800 rated players looks very different from a game between two grandmasters, and the same player plays very differently in bullet than in classical. Our initial model sees none of this. It sees only moves.

The PGN headers already contain the ratings of both players and the time control, so we can give them to the model. Three metadata tokens are prepended to every game: the time control, the white player's rating, and the black player's rating. These are ordinary special tokens, the same device every LLM already uses for markers like start-of-text; the model reads them exactly as it reads a move, and nothing about the architecture changes.

But at inference time we may not know these values. To handle this, each metadata token is randomly replaced with a special <|missing|> token 30% of the time during training. The model learns to use the metadata when it is available, and to fall back to a sensible average when it is not.

Verdict: Metadata is a real win: given the ratings and time control, the model beats the no-metadata baseline. The dropout is what makes it safe: without it, the model falls apart whenever a value is missing.

A better optimizer

The baseline used AdamW for every parameter. The biggest single win of the whole sweep came from replacing it on the transformer-block weights with the Muon optimizer, while AdamW keeps the embeddings, the output layer and the norms. (The optimizer is the algorithm that turns each batch's gradients into an actual weight update.)

The first attempt was a disaster: reusing AdamW's learning rate of 6e-4 for Muon left the model about 0.18 nats worse than baseline. Muon wants its own learning rate, more than 10x higher. Unsurprising in hindsight, since Muon orthogonalizes its updates, so its learning rate lives on a different scale. After a proper sweep the best value was 9.5e-3. With Muon carrying the block weights, AdamW's learning rate for the remaining parameters was swept again and also preferred to be higher, landing at 1.9e-3.

Other changes that were considered but not accepted

Most of the architecture knobs turned out not to matter. A deeper, thinner model was clearly worse. A version with more attention heads never separated from baseline either way, so it was dropped without a 4x rerun. A wider, shallower one looked like a tie at the small budget and then lost outright when re-run at 4x compute, as did a higher AdamW learning rate I would otherwise have shipped. RMSNorm landed within noise of LayerNorm, so LayerNorm stays. Two parts of the final recipe rode in without an ablation win: SwiGLU (a now-standard variant of the transformer's feed-forward layer, adopted by convention because it is what modern LLMs use) and the learning-rate schedule, a constant rate with an inverse-square-root warmdown, carried over unchanged from the paper it comes from rather than tuned here. And weight decay bought nothing at this scale, so the recipe inherited none, a choice that caused problems at full scale.

The final model

With the ablation sweep finished, every choice is settled. The final recipe:

The final training run takes this recipe to the full training set: 600,000 steps, about 123B tokens of chess games (600,000 steps × 1,024 sequences × 200 half moves), a single near-complete pass in which almost every game is seen exactly once. It did not go smoothly the first time (the first attempt exploded past step 160,000 and had to be restarted with a small amount of weight decay added) but the rerun trained cleanly all the way through, three and a half days on the H100. The result is chess-autocomplete-v1-91m, the model you can play against at the top of this page.

Deep diveThe final run

The recipe that came out of the sweep carried no weight decay, and the first attempt at the final run did not survive that. At step 160k everything was healthy: validation loss falling, VPM at 100%, gradient norms (the overall size of each update step) around 0.08. At step 165k the gradient norm spiked to 55. By step 172k it had reached 10⁸. The validation loss climbed to 23.8, and VPM collapsed to 1.8%.

I first tried to rescue the run. Restarting from a healthy checkpoint with lower learning rates looked promising for a few thousand steps, but every variant either diverged again or showed the same upward bend in the loss. Whatever this was, lowering the learning rate only delayed it.

Digging through the checkpoints revealed something surprising: the failure was localized. In plain terms, one tiny part of the network started growing without limit and dragged everything else down with it. Specifically, a single channel in the LayerNorm before the attention of block 1 grew from 0.16 to 6.3 between steps 150k and 200k while its paired bias swung to -6.0, and the Muon updates to that block's attention projections concentrated on that same channel. One normalization channel and a handful of weight columns had entered a feedback loop, and they took the rest of the model down with them.

The recipe had inherited one more choice from modded-nanogpt that I never questioned: no weight decay. Nothing in the training was pushing back against a weight that only wants to grow. The fix was a small amount of weight decay (0.005 for AdamW, 0.01 for Muon, values inspired by the NanoGPT speedrun community): a gentle force that shrinks every weight toward zero on each step, so nothing can grow unchecked. Then restart from scratch.

So, can autocomplete play chess blindfolded?

In short, usually. From our original goal of 100% VPM, our model is able to achieve 99.93%, with a 99.99% top-1 valid move accuracy. Game end accuracy was worse, out of our stated goal of 100% GPA our model achieves 99.49%, with a total correct game end probability mass of 99.19%

These numbers are from evaluating the model in a large, balanced, held-out dataset. The dataset consists of 768,000 games it never saw during training: 768 buckets, 16 white ratings (1000-2500) x 16 black ratings (1000-2500) x 3 time controls (bullet, blitz, rapid), 1,000 games per bucket, drawn from 2022-2023. Classical is left out: there are not enough classical games in that window to fill all 768 buckets.

The two deep dives below explore where the remaining 0.07% VPM and 0.51% GPA are.

The value of Elo and time control information

The metadata tokens were meant to let the model adapt to the players in front of it. Do they change how it plays? This is tested by scoring the model twice on the same games: once with all three metadata tokens present, once with every one replaced by <|missing|>. The gain is smallest when both players sit near the 1664 median, where the model already guesses the typical continuation, and largest when the players are far from average:

The pattern shows the model acts on the rating tokens rather than ignoring them. Between two average players there is little to add: the no-metadata guess is already the common move. Tell it instead that a 1000 rated player is facing a 2400, and it shifts toward moves it would otherwise never reach, a pairing nothing in its no-metadata prior accounts for.

The coarse 4×4 heatmap (Figure 18) bins a finer 16×16 grid. The full version is in the appendix: the metadata gain (Figure 23), raw move match (Figure 24), and loss (Figure 25), cell by cell.

Playing strength

To measure strength the model played 46,080 games against Stockfish at five capped levels across openings and all four time controls, with long games adjudicated by a full-strength Stockfish. The model plays greedily: its single most likely legal move, no search. It is conditioned on a time control too, so each figure shows a single time control; this one is classical. Conditioned on a 2500 rating, the top of our grid, it scores:

Each of those scores converts to a performance rating: the Elo you would need to score that much against that one opponent. For the 2500-conditioned model in classical:

The conditioned rating has only a minor effect on the performance rating of the model, and the effect disappears against stronger opponents. The factor that most affects the model's playing strength is its opponent. The stronger the opponent, the better the model plays. Greedy play also sets a floor on how weak the model can be. Its output is a poll of every 1000 rated player it has seen, and they blunder in different ways: the mistakes scatter across many moves while the reasonable move collects the most mass, so always playing the top move amounts to taking the crowd's vote. Even conditioned as a 1000, the model lands around 1600 against the weakest ladder level.

By default each line is one conditioned rating, drawn across the Stockfish ladder. The X axis control flips that: one line per Stockfish level, drawn across the conditioned ratings, with No metadata as a trailing column, so the chart reads two ways, across the ladder or across conditioning. Hover a column to read off every visible line with its wins, draws, and losses. Each point pools 128 games (the no-metadata line 1,152); the All time-control view pools all four controls into 512 (no metadata 4,608). Filtering to one opening family or one color halves the count, both together quarter it, and the whiskers widen to match. The dashed reference marks an even 50% score, or in the rating view the opponent's own Elo (shown only in the default Stockfish-x orientation). The same numbers, exact and cell by cell, are in the strength table (Figure 22).

An important caveat: these are results against specific configurations of Stockfish, not against humans. An engine chooses moves nothing like a person does, so a score against it says how the model performs in that match-up, not how it would do against a human of any given rating.

How does it compare to the state of the art?

There is a line of research focused on chess models that are able to play chess like a human would. Given that our model is trained on an enormous amount of human games, we should expect it to do quite well on this task. The standard benchmark is the test set released with Allie (884,049 Lichess blitz positions) scored by how often a system's top move equals the move the human actually played.

The 700M takes the top spot on half the data: it is the T=300k anneal branch, 61.4B tokens against the 122.9B the other two each saw. The 350M lands third, a tenth of a point under Maia-3's 79M variant. The 91M sits fifth, with four rows above it, two of them our own larger models and two the largest Maia-3 variants (23M and 79M, released in May 2026); it still lands ahead of Allie, GPT-3.5, Maia-2, and the rating-matched original Maia.

That leaderboard is blitz. Maia-2 measures the same skill on rapid, its Maia-1 test set, where the moving player's rating splits the games into Skilled, Advanced, and Master. Both our models lead Maia-2 in every group:

The remaining reproductions, Maia-2's cross-skill grid, Allie's move-legality and move-type tables, and a breakdown of where the 56% comes from, are in the appendix.

Blindfolded, and near the top

The question was whether a model that reads nothing but a stream of moves, with no board in front of it and no rules to consult, could play chess blindfolded. It can.

On our held-out set of games it never saw, 99.93% of its probability lands on legal moves, and it correctly determines when a game has ended 99.49% of the time. It hasn't learned the rules perfectly, but almost.

On the standard human move benchmark it matches 56% of the moves real players chose, behind only the two largest Maia-3 networks and ahead of every Maia, Maia-2, Allie, and GPT-3.5 entry. That is 91M parameters, with none of the machinery the others lean on. These benchmarks each cover one thin slice of chess. The Allie set is blitz, its openings and time-scramble moves thrown out; the Maia-2 set is rapid, split into rating bands. The models behind them are narrow to begin with: Allie and Maia-3 trained on blitz alone, Maia-2 on rapid. Ours saw all of it, four time controls from bullet to classical and every rating, nothing held back, and it still scores near the top on their slice.

And all of this was achieved by simply:

predicting the next token

That board at the top? It's the full model

The board at the top of this page is the real thing: the full 91M parameter model running in your browser through ONNX Runtime with WebGPU. At each move the model produces a probability distribution over moves; illegal moves are masked out, and by default it plays its most likely legal move (you can switch on temperature and top-k sampling in the settings to make it less predictable). The interface handles the FIDE draw rules. By default the model is conditioned as a 2500 rated rapid player, the top rating bucket, and the same 2500 rating the strength numbers above used (those were in classical, this board is rapid). Good luck.

Get the model, dataset, and code

Everything in this post is open:

• The model, in PyTorch, safetensors and ONNX formats: Alfredvc/chess-autocomplete-v1-91m
• The larger models: Alfredvc/chess-autocomplete-v1-350m and Alfredvc/chess-autocomplete-v1-700m-300k
• The processed dataset: Alfredvc/chess-autocomplete-lichess
• The evaluation datasets: Alfredvc/chess-autocomplete-eval-datasets
• The training checkpoints, with optimizer state and training curves: Alfredvc/chess-autocomplete-v1-checkpoints
• The full training and evaluation code: Alfredvc/chess-autocomplete

References

• Lichess open database
• Chessformer: A Unified Architecture for Chess Modeling (Maia-3)
• Maia-2: A Unified Model for Human-AI Alignment in Chess
• Human-aligned Chess with a Bit of Search (Allie)
• Aligning Superhuman AI with Human Behavior: Chess as a Model System (Maia)
• Amortized Planning with Large-Scale Transformers: A Case Study on Chess (Grandmaster-Level Chess Without Search)
• Muon optimizer
• modded-nanogpt
• FlashAttention
• Scaling Laws and Compute-Optimal Training Beyond Fixed Training Durations
• FIDE Rating Regulations (performance-rating conversion table, §8.1.1)
• Language Models are Unsupervised Multitask Learners (GPT-2)

Appendix

The full rating×rating grids

The coarse 4×4 heatmap in The value of Elo and time control information bins a finer 16×16 grid. Here is the full version, all with metadata, white rating down the rows and black rating across the columns: the metadata gain (Figure 23), brightest at the corners; raw move match (Figure 24), which rises with rating because stronger players are more predictable; and the loss (Figure 25), which falls the same way. On a narrow screen the grids scroll sideways.

Playing strength, in full

The playing-strength figures in the main text show one slice: classical games, with metadata, scored for the model (win = 1, draw = ½). The model is conditioned on the time control too, so the same experiment was run across all four (bullet, blitz, rapid, classical). The complete set — every conditioned rating against every Stockfish level, 128 games per cell, for each time control and as raw score, W/D/L, or a performance rating — is in the interactive table, Figure 22: change its Time control and Metric, or add the No-metadata row. The same numbers as a line chart are in Figure 21.

A warning on the rating metric. Against a single fixed opponent a performance rating is just the cell's score re-expressed on the Elo scale, so it is dominated by which opponent was played: scoring 10% against a 3099 rated Stockfish still rates around 2700, because that result is a 2700-level result by the Elo formula. It does not mean the model plays at 2700 strength while losing nine games in ten. Read each column as "how the model performs against this opponent," not as one number for the model; their disagreement across a row (about 1800 against the weak levels, about 2700 against the strong ones) is exactly why no single rating is more than a rough summary. And as everywhere in this section, these are estimates against Stockfish, whose move distribution is not human. See the caveats above. The ± is one standard error throughout.

Constrained moves are the easy ones

The 56% average is not uniform. The more constrained the move, the better the model guesses it. Forced and near-forced moves are far more predictable than a free choice in the middlegame:

Benchmark reproductions

The comparisons in this post are pulled from a larger evaluation suite that reproduces specific tables and figures from the Maia-2, Maia-3 and Allie papers as exactly as the released data allows. This appendix lists each reproduced artifact, the exact paper table or figure it maps to, and a compatibility status: paper-compatible (exact paper inputs, denominators and metric semantics), method-compatible (regenerated by the paper's own method where exact rows are not public), or blocked (a required paper input is unavailable, so the artifact is left unreproduced rather than approximated). Every figure below shows our model given the real metadata; values quoted from the source papers are labeled as such and were not recomputed.

B1. Maia-2 Table 1: move-prediction accuracy

Reproduces Maia-2 Table 1: top-1 move-prediction accuracy on the Maia-1 Testset, grouped Skilled / Advanced / Master with Avg the macro-averaged result (groups per Maia-2 §4.1). Status: paper-compatible, scored on the exact 106,740-row test set (Skilled 56,812, Advanced 41,747, Master 8,181). Our row is computed; the Maia-2 row is quoted verbatim from Maia-2 Table 1 and was not recomputed. The table itself, with our row in context, is in How does it compare to the state of the art?

B2. Maia-2 Figure 2: cross-skill grid

Reproduces Maia-2 Figure 2: move match as a function of the active player's rating (rows) and the opponent's rating (columns). Status: method-compatible: Maia-2 does not release the row-level cross-skill set, so it is regenerated from December 2023 Lichess rapid games (~4.93M scored positions), with per-cell counts targeted to Maia-2 Appendix Table 8. Move-match rises as either player gets stronger, with the active player's own rating the larger lever, the same surface Maia-2 reports.

The same grid as a delta against Maia-2's Figure 2: our move match minus the value Maia-2 prints in each Figure 2 cell, in percentage points. Maia-2 draws Figure 2 on a finer ten-bin rating axis (1900 and 2000+ split apart) than the nine-bin Appendix Table 8 scheme our eval used, so the delta is shown only where the bins coincide exactly: both players rated 1800 or below (44 cells). The 2000+ row and column are left blank rather than compared across mismatched bins. We lead Maia-2 in every comparable cell, by roughly four to five points.

B3. Maia-3 Table 1: move match leaderboard

Reproduces our row of Maia-3 (Chessformer) Table 1: the top-1 human move match leaderboard on the 884,049-position Allie test set. Status: paper-compatible for our entry (move match 56.05, scored locally); every other system in the leaderboard is quoted from Maia-3 Table 1 and was not recomputed. The full ranking, with our row in context, is in How does it compare to the state of the art?

B4. Allie Table 2: move legality

Reproduces Allie Table 2 (§5.1): the share of positions where the top-1 move is legal, on Lichess games and on random out-of-distribution positions, each also restricted to positions where the side to move is in check. Status: the Lichess rows are paper-compatible; the random rows are method-compatible, because Allie does not release its exact random positions (regenerated with seed 42). Allie's column is quoted from Allie Table 2 (reported there with 95% confidence intervals); ours is computed on Lichess 884,049, Lichess in check 63,844, Random 377,500 and Random in check 20,662 positions.

B5. Allie Table 3: move match by move type

Reproduces Allie Table 3 (§5.2): top-1 move match across all moves and the special-move categories, comparing Allie-Policy, Maia⋆ and GPT-3.5. Status: paper-compatible, on the same 884,049-position set. The Allie, Maia⋆ and GPT-3.5 columns are quoted from Allie Table 3 (reported there with 95% confidence intervals); our column is computed. The same move match figures appear in Constrained moves are the easy ones above.