Kestrel 3.2

Kestrel 3.2

A smoother time management (+9 ± 5 Elo against 3.1 at short time controls) and four small changes: huge-page advice for the hash table (Linux), a memory limit for Hash (macOS), a time reserve that grows with the thread count, and release builds that no longer pay for switched-off options. The network, the search and the evaluation are those of 3.1: whenever a search is limited by depth, nodes or move time, Kestrel 3.2 plays exactly like 3.1 (the same depth-12 bench, 859,322 nodes; 24 test positions searched to depth 14 and with go nodes 30000 give identical nodes, scores, best moves and principal variations); only a search with a clock (go wtime ...) can differ.

What is new compared with 3.1

• Smoother time management. After every iteration of its iterative deepening the engine decides whether to start the next one. 3.1 used three fixed thresholds (60 % of the planned time for a normal move, 90 % when the best move had just changed or the score fell, 40 % when the best move had been the same for four iterations). 3.2 multiplies the planned time by factors that change continuously: it falls with every iteration that keeps the best move (150 %, 130 %, 110 %, 90 %, 70 %, 60 % ... of the base of 60 %), it grows when the score of this iteration is lower than the one before and when it is lower than the score of the previous move of the game, and it is shortened by 20 % when the best move got more than 90 % of the nodes of the iteration. The planned time itself (about 1/28 of the remaining time plus 3/4 of the increment) and the hard limits are unchanged. Packaged 3.2 against packaged 3.1 with one thread (the Windows x86-64-v3 builds, Hash 64, no book): +11.2 ± 6.2 Elo at 3 s + 0.03 s per game (4,000 games) and +6.2 ± 7.5 at 5 s + 0.1 s (2,000 games). Together +9.2 ± 4.8 Elo (6,000 games). The speed is that of 3.1 (the same depth-12 bench in the same time), so this is the effect of the time management; the same executable with the new rule on or off scored +7.3 ± 6.1 and +0.9 ± 7.5 in two development matches. Games lost on time: 3 s + 0.03 s: 3.2 5, 3.1 9; 5 s + 0.1 s: 3.2 0, 3.1 0. With a fixed move time, a depth or a node limit nothing changes.
• Linux: transparent huge pages for the hash table. Tables of 256 MB or more are advised (madvise) to use 2 MB pages, so that the random probes of many threads miss the TLB less often. It is only an advice and ignored where huge pages are off. I could not measure its effect (I have no Linux machine); Stockfish does the same.
• macOS: the limit of a Hash request. A request above three quarters of the installed memory is cut to that size (with an info string line), as in 3.1 on Windows and Linux; 3.1 did not know the memory size on macOS.
• Release builds compile the switches as constants. The development options (K22Flags, K31Flags, K32Flags, V31Flags, CorrFlags, T_...) are compile-time constants in the release source, so the compiler removes every switched-off idea from the search: with the new switches as ordinary variables the 3.2 exe was 4 % slower than 3.1 in the depth-12 bench (720 ms against 690 ms), with constants it is as fast as 3.1 and 0.5 MB smaller. The options that earlier versions accepted but did not list in uci are now ignored.
• Many threads and Move Overhead. The time that is held back for the communication with the GUI grows by 1 ms for every 8 threads above 8 (15 ms with 128 threads), on top of the Move Overhead option, because stopping dozens of threads takes longer. With 8 threads or fewer nothing changes.

What did not change

The network (the file of 3.0 and 3.1), the search, the evaluation, Syzygy support, every option and the strength with a fixed number of nodes. With one thread and a fixed depth, node count or move time Kestrel 3.2 and 3.1 give the same moves. The strength of 3.0 against 2.3 (+130 ± 8 Elo) and the gain of more threads (+108 to +123 Elo with 8 threads against 1) hold for 3.2; see the notes of 3.0 and 3.1.

Ideas that were tested and are not in 3.2

A history indexed by the pawn structure, a correction history indexed by the previous move, and skipping ProbCut when the transposition table says it cannot work were tested at 20,000 nodes per move against the same build without them (1,300 to 1,700 games each, stopped early): -1.4 ± 13.3, -1.9 ± 14.0 and -7.8 ± 12.5 Elo. The code of the first two and of more correction histories (by the minor and by the major pieces) is in the source as switched-off options of the development builds. A build with Zig/clang was 7 % slower than the g++ build.

Which file do I need?

File	For
Kestrel-3.2-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-3.2-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-3.2-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-3.2-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-3.2-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-3.2-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-3.2-linux-arm64.tar.gz	Linux ARM64
Kestrel-3.2-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-3.2-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it and switch OwnBook on if you want it). kestrel_net_3_2.bin is the network alone (the same file as kestrel_net_3_0.bin and kestrel_net_3_1.bin; needed only to build from source or to load with EvalFile).

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower.

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (859,322 nodes), so the plain code and the AVX2 code agree exactly, and the x86-64-v3 build plays exactly like the build of the same source with 8 search copies and, for searches without a clock, like the 3.1 build with one thread (24 positions to depth 14, and with go nodes 30000: identical nodes, scores, best moves and principal variations). Both black-box audits pass (83 of 83 and 31 of 31). All 20 test scripts of the repository (tests/) pass on the packaged x86-64-v3 exe, among them tests/breakers.py (807 checks) with 1, 8 and 64 threads and with 16 threads and tablebases (1207 checks), and tests/stress_stop.py with 16, 64 and 128 threads; tests/depth1_test.py passes too (128 threads, go movetime 60: every search searches, no stalemating move). The Syzygy test against python-chess (3-4-5 men): 1,500 positions, 0 mismatches; root filter 1,483 positions, 0 problems; search 60 positions, 0 problems; conversion 30 of 30 won endgames. The sanitizer verification of the release source (GCC and clang AddressSanitizer + UBSan builds, also with 4 threads) passed 30 of 30 checks; an AddressSanitizer + UBSan build of the release source with up to 128 threads passed 16 of 17 steps (thread stress at 2 to 128 threads, hash tests, the UCI fuzzer, tests/breakers.py --quick with 8 and 64 threads, ...); the one step that stops, tests/edge_test.py, stops at the two FEN-parser spots listed under Known limits.
• Linux and macOS: compiled with Zig and checked for file format, but not run where they were made (I have no machine to run them on). The workflow in .github/workflows/verify-release.yml runs the published files on GitHub's Linux, macOS and Windows machines (bench, a UCI session, 128 threads with a 2 GB hash, the Syzygy test with the 3- and 4-men files, on Linux the whole test suite including 64 and 128 threads) and builds the source with AddressSanitizer and UBSan; the 3.1 files passed all 15 jobs there. The macOS Intel build is run by the workflow on GitHub's Intel Mac machine after the release is published (I have no Mac myself).
• The exe is about 82 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Known limits

• The threads are started and stopped for every search (a thread pool is not implemented): with 128 threads on a 22-processor laptop go movetime 60 took 50 ms in the median but once 328 ms in 60 searches, and about 0.8 s (median) when 24 other programs kept all processors busy; on a computer with 128 processors starting 127 threads takes about 14 ms. With a clock and many threads use a Move Overhead of at least 100 ms.
• The hash size is a power of two (rounded down). Tables of 32 GB and more (2^31 entries) could not be run on the 31 GB computer where this was made; the index arithmetic is 64-bit everywhere.
• Windows before Windows 11 / Server 2022 confines a process to one group of at most 64 logical processors; on a computer with more, threads beyond 64 would share those 64. Not tested. Windows large pages are not used.
• Two undefined-behaviour spots of the FEN parser exist in 3.0 to 3.2 (a FEN with a rank that does not add up to eight files; a halfmove clock of 2^31 or more); they are not changed and matter only to a sanitizer build fed with malformed input.

Building from source

src/kestrel_3_2.cpp (4.6 MB, 128 copies of the search) is generated from src/kestrel_3_2_base.cpp (the file to read: 8 copies) by scripts/make_threads.py; g++ -O3 needs about two and a half minutes and 1.1 GB for it. It embeds the network with .incbin "kestrel_net.bin", which the assembler looks up in the current directory: download kestrel_net_3_2.bin from this release, save it as kestrel_net.bin in the folder where you run the compiler, then for example

g++ -std=c++17 -O3 -march=x86-64-v3 -static -pthread -DNDEBUG -o kestrel.exe path/to/src/kestrel_3_2.cpp

The network is not stored in the git history (76 MB ...

Kestrel 3.1

Kestrel 3.1

More search threads and a much larger hash, for computers with many cores. The network, the search, the evaluation and the time management are those of 3.0: with one thread Kestrel 3.1 plays exactly like 3.0 (the same depth-12 bench, 859,322 nodes; 24 test positions searched to depth 16 (13.1 million nodes), and with go nodes 30000, give identical nodes, scores, best moves and principal variations in the release builds of both).

What is new compared with 3.0

• Threads up to 128 (3.0: 8). The search code is compiled once per thread, so every thread owns its tables (history, correction history, position, ...) as in 3.0; there are now 128 copies, made from the 3.0 source by scripts/make_threads.py, which checks that all copies are identical. The default is still 1 thread. A launcher thread starts the helper threads (about 50 - 100 microseconds each, 6 - 14 ms for 127 helpers) while the main search already runs: the first info line comes after 0.6 ms (median) with 128 threads, as with one thread (0.5 ms). After stop the 127 helpers need 11 ms (median, 20 ms at most) to finish.
• Hash up to 1,048,576 MB (3.0: 4096). The table size is still a power of two (a request is rounded down: 24,000 MB gives a table of 16,384 MB). On Windows and Linux a request above three quarters of the installed memory is cut to that size, with an info string line, so that a mistyped value cannot page the computer to death; if the operating system refuses an allocation the engine still falls back to smaller tables and now says so. Big tables are cleared by many threads: 16 GB are allocated and zeroed in about 1 s and ucinewgame clears them in about 1 s (one clearing thread: 4.6 s and 4.4 s on the same computer).
• A node limit counts the main thread only. go nodes N and UCI_LimitStrength used to stop as soon as any thread had searched N nodes. With several threads the first helper got there before the main thread had finished depth 1, and the best-ordered move was played (in a won queen-and-knight against king ending, the stalemating move: 3.0 with 8 threads in 37 of 40 tries). Now only the main thread's count ends the search; the nodes of the info lines (all threads) can be larger than N. For a limited-strength engine use one thread.
• Short move times with many threads. In 3.0 think() started all helper threads before the main search began: 127 threads take 6 - 14 ms on a computer with enough processors and 35 - 100 ms and more with fewer processors than threads or a busy computer, which with a hard limit of 45 ms (go movetime 60) was most or all of the time, and the first time check of a thread runs at node 0, so a search whose hard limit had passed by then ended without any result and the best-ordered legal move was played. On a quiet 22-processor laptop, in a won queen ending in which a quiet king move is stalemate (visible from depth 2 on), 31 of 60 such searches with 128 threads (5 of 60 with 64 threads) ended before depth 1; with only a rule that a time limit cannot end a search before depth 1 has completed, 18 of 60 stopped at depth 1 and played the stalemating move (64 threads: 3 of 60). Now a launcher thread starts the helpers and the main search begins at once, and a time limit cannot end a search before depth 1 has completed: 0 of 60 at 64 and at 128 threads, last depth 12 (median), and 0 of 30 with 24 busy programs competing for the processors. The code of 3.0 is the same, but 3.0 starts at most 7 helpers. stop and node limits are not affected, and with one thread nothing changes. tests/breakers.py --threads 64 found the problem; new test: tests/depth1_test.py.
• Windows: starting the helpers when there are more threads than processors. The launcher thread runs at a higher priority than the search. With more threads than processors the helpers that were already running kept it waiting: starting 127 helpers took 2.6 s (median) on a 22-processor laptop and up to 20 s in a build without this, 35 ms (108 ms at most) with it, and the main search no longer waits for it at all.
• Smaller memory footprint at few threads. ucinewgame clears the tables of the search copies that were started since the last clear only; the pawn table of every copy starts as zeros and is no longer stored in the executable. The Windows x86-64-v3 exe is 81.6 MB (3.0: 88.4 MB). Every search copy reserves 6.3 MB of address space, so the process commits about 0.84 GB when idle against 79 MB for 3.0; a one-thread game uses about the same resident memory as in 3.0 (97 MB against 67 MB with a 16 MB hash).

Strength with more threads

On my laptop (22 logical processors) 8 threads score +123 ± 24 Elo against 1 thread of the same build at 10 s + 0.1 s per game (200 games with a development build: 85 won, 17 lost, 98 drawn) and +108 ± 38 Elo with the release exe (100 games: 38 won, 8 lost, 54 drawn); all games finished normally. More threads than the computer has processors do not help: 64 and 128 threads on the same 22 processors scored +11 ± 71 and +11 ± 57 against 1 thread (32 games each), and the 128-thread engine lost one game on time. Use at most as many threads as there are logical processors, and raise Move Overhead to 50 - 100 ms with 64 or more threads. I could not test a computer with many more processors.

Lazy SMP does not scale linearly. On this laptop (6 performance cores with two threads each, 8 efficiency cores, 2 low-power cores; 76 MB of network weights that all threads read) the nodes per second grow 2.9 times with 8 threads and 3.7 times with 20, and the time to reach a fixed depth does not shrink, because every thread runs slower when the others are busy. Counted in nodes, the search needs 1.4 / 1.8 / 3.0 / 3.7 / 4.4 times as many nodes in total to finish depth 20 with 2 / 4 / 8 / 16 / 20 threads, and 5.1 / 7.3 / 9.2 times with 32 / 64 / 128 threads (these three on 22 processors); if every thread ran as fast as a thread of the one-thread search, the time to depth would shrink by about 1.4 / 2.3 / 2.6 / 4.4 / 4.5 / 6.3 / 8.8 / 14 times with 2 / 4 / 8 / 16 / 20 / 32 / 64 / 128 threads. Raw results: logs/threads_3_1.txt.

What did not change

The network (the file of 3.0), the search, the evaluation, the time management, Syzygy support and every other option. The strength of 3.0 against 2.3 (+130 ± 8 Elo, one thread) holds for 3.1 with one thread; see the notes of 3.0.

Which file do I need?

File	For
Kestrel-3.1-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-3.1-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-3.1-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-3.1-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-3.1-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-3.1-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-3.1-linux-arm64.tar.gz	Linux ARM64
Kestrel-3.1-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-3.1-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it and switch OwnBook on if you want it). kestrel_net_3_1.bin is the network alone (the same file as kestrel_net_3_0.bin; needed only to build from source or to load with EvalFile).

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower.

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (859,322 nodes), so the plain code and the AVX2 code agree exactly, and the x86-64-v3 build plays exactly like the 3.0 build with one thread (24 positions to depth 16, 13.1 million nodes, and with go nodes 30000: identical nodes, scores, best moves and principal variations). Both black-box audits pass (83 of 83 and 31 of 31). All 20 test scripts of the repository (tests/) pass on the packaged x86-64-v3 exe, among them tests/breakers.py (807 checks) with 1, 8 and 64 threads and with 16 threads and tablebases (1207 checks), and tests/stress_stop.py with 16, 64 and 128 threads; the new tests/depth1_test.py passes too (128 threads, go movetime 60: every search searches, no stalemating move). The Syzygy test against python-chess (3-4-5 men): 1,500 positions, 0 mismatches; root filter 1,483 positions, 0 problems; search 60 positions, 0 problems; conversion 30 of 30 won endgames. The sanitizer verification of the release source (GCC and clang AddressSanitizer + UBSan builds, also with 4 threads) passed 30 of 30 checks; an AddressSanitizer + UBSan build of the release source with up to 128 threads passed 16 of 17 steps (thread stress at 2 to 128 threads, hash tests, the UCI fuzzer, tests/breakers.py --quick with 8 and 64 threads, ...); the one step that stops, tests/edge_test.py, stops at the two FEN-parser spots listed under Known limits.
• Linux and macOS: compiled with Zig and checked for file format, but not run (I have no machine to run them on). The workflow in .github/workflows/verify-release.yml runs the published files on GitHub's Linux, macOS and Windows machines (bench, a UCI session, 128 threads with a 2 GB hash, the Syzygy test with the 3- and 4-men files, on Linux the whole test suite including 64 and 128 threads) and builds the source with AddressSanitizer and UBSan; the thread code of 3.1 runs on those systems for the first time there. The macOS Intel build is run by the workflow on GitHub's Intel Mac machine after the release is published (I have no Mac myself).
• The exe is about 82 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Known limits

• The thr...

Kestrel 3.0

Kestrel 3.0

A much stronger network, and Syzygy tablebases. Against 2.3 it scores +130 ± 8 Elo over six time controls (3,800 games, one thread), and +104 ± 11 at 5 s + 0.1 s per game or longer (1,600 games).

What is new compared with 2.3

• A new network, trained on about nine times as many positions of the same kind. It has the shape of the 2.x network (39.1 million parameters, 24,576 inputs per side, 1,536 neurons, 16 -> 32 -> 1 with 8 output buckets). The 2.x network was trained on 238 million positions of the Lichess evaluation database and overfitted: after about 50 hours the error on held-out positions stopped falling while the error on the training positions kept falling (0.0129 against 0.0089), because the database had no more positions to offer. Every evaluation in that database comes with the best lines that Stockfish found (up to 5 lines of 10 moves). 3.0 also learns from the positions along those lines: the positions after 1 to 9 moves of the best line and after 1 to 6 moves of the other lines, each labelled with the evaluation of its line; only quiet positions (not in check, no capture or promotion as the next move), duplicates removed, and the held-out test positions and the positions of the older training set left out. That gives 2.36 billion new positions (mined in two batches of 1.08 and 1.28 billion), and with them the overfitting is gone. The network was trained in two stages on one laptop CPU: 650,000 steps of 16,384 positions (54 hours) and a continuation of 90,000 steps (8 hours) on the second batch; the shipped network is the best snapshot of the second stage. On held-out positions its error is 17 % lower than the 2.3 network's on Lichess positions and 32 % lower on positions from Kestrel's own games. Stockfish is used only as the teacher of the data; no Stockfish code or network is included.
• Syzygy tablebases. Set the new option SyzygyPath to the folders with the .rtbw / .rtbz files (the 3-4-5-men files are 940 MB; larger sets use the same code but were not tested). Inside the search a position with at most as many men as the largest table is looked up right after a capture or a pawn move; at the root, the DTZ files choose the moves that keep the best result and make progress under the fifty-move rule. New options SyzygyProbeDepth, Syzygy50MoveRule, SyzygyProbeLimit; info lines carry tbhits. Without tablebase files nothing changes. Details and tests: docs/SYZYGY.md. The probing code is Fathom (MIT licence, Ronald de Man, basil00, Jon Dart); it is part of the single source file and its licence is in THIRD_PARTY_NOTICES.txt.
• Speed. The network is as large as before, so the cost of a node is almost the same (1.07 million nodes per second in the depth-12 bench against 1.13 million for 2.3), but the stronger network makes the search tree smaller: the bench needs 859,322 nodes instead of 1,051,844 and takes about 808 ms instead of 935 ms. On Windows the engine now asks the system not to treat it as a background process (efficiency mode): a GUI that starts the engine hidden could make Windows slow it down; opting out gave +13 to +17 % nodes per second at 2 to 8 threads in a test. info nodes and info nps no longer add the stale counters of idle helper threads when MultiPV is above 1 or fewer threads than requested could be started.

Strength

Kestrel 3.0 against Kestrel 2.3, packaged x86-64-v3 builds, fastchess, 1 thread, 64 MB hash, no book, no learning, no adjudication, the same openings for both sides (colours swapped); Elo with its 95 % interval.

Time per game (base + increment, seconds)	Elo of 3.0 against 2.3	Won	Lost	Drawn
1 + 0.01	+192 ± 23	379	77	144
2 + 0.02	+150 ± 23	350	106	144
3 + 0.03	+146 ± 17	563	166	271
5 + 0.1	+105 ± 14	475	181	344
10 + 0.1	+102 ± 22	181	67	152
20 + 0.5	+102 ± 28	92	35	73

Pooled over all time controls: +130 ± 8 Elo against 2.3 (3,800 games, inverse-variance weights). The gain is largest at the shortest time controls and levels off with more time: from 5 s + 0.1 s per game on it is +104 ± 11 Elo (1,600 games). The gain comes from the network alone: the search and the time management are those of 2.3, and in a match of the two networks inside the same engine at 20,000 nodes per move the 3.0 network is +138 ± 11 Elo ahead (2,000 games). The network has the same size as before, so the cost of one node is almost the same (1.07 million nodes per second in the depth-12 bench on a performance core against 1.13 million for 2.3, 5 % fewer), but the stronger network makes the search tree smaller: the bench needs 859,322 nodes instead of 1,051,844 and takes about 808 ms instead of 935 ms (14 % less time).

In my own round robin against 100 other engines (5 s + 0.1 s per game, one thread, this laptop, every engine at full speed) 3.0 scored 76.0 of 200 games; fitted onto the CCRL Blitz scale through the engines whose ratings did not change that is about 3576 (95 % bootstrap interval 3552 to 3597), which would put it 71 of 101 in that table. This is an estimate under my own conditions, not a rating-list result.

Raw results: logs/fast_matches_3_0.txt.

What did not change

The search, the time management and the options of 2.3 are the same, and so is Lazy SMP with up to 8 threads. No rating list has tested Kestrel.

Which file do I need?

File	For
Kestrel-3.0-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-3.0-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-3.0-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-3.0-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-3.0-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-3.0-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-3.0-linux-arm64.tar.gz	Linux ARM64
Kestrel-3.0-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-3.0-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it and switch OwnBook on if you want it). kestrel_net_3_0.bin is the network alone (needed only to build from source or to load with EvalFile). The 3.0 builds can also load the network of 2.x with EvalFile (the same format, width 1,536); that is how the two networks were compared.

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower.

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (859,322 nodes), so the plain code and the AVX2 code agree exactly. Both black-box audits pass (83 of 83 and 31 of 31; one check of the second was relaxed for 3.0, see the changelog). The 30-check verification with GCC and clang AddressSanitizer + UBSan builds (also with 4 threads) passed 30 of 30. The Syzygy test against python-chess (3-4-5 men): 1,500 positions, 0 mismatches; root filter 1,483 positions, 0 problems; conversion 30 of 30 won endgames.
• Linux and macOS: compiled with Zig and checked for file format. The workflow in .github/workflows/verify-release.yml runs the published files on GitHub's Linux, macOS and Windows machines (bench, a UCI session, the Syzygy test with the 3- and 4-men files, and on Linux the whole test suite) and builds the source with AddressSanitizer and UBSan; before the release the same workflow ran on this version's source (built with the 2.3 network) and passed everywhere; its run on the published 3.0 files is on the Actions page. The macOS Intel build is run by the workflow on GitHub's Intel Mac machine after the release is published (I have no Mac myself).
• The exe is about 88 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Building from source

src/kestrel_3_0.cpp embeds the network with .incbin "kestrel_net.bin", which the assembler looks up in the current directory: download kestrel_net_3_0.bin from this release, save it as kestrel_net.bin in the folder where you run the compiler, then for example

g++ -std=c++17 -O3 -march=x86-64-v3 -static -pthread -DNDEBUG -o kestrel.exe path/to/src/kestrel_3_0.cpp

The network is not stored in the git history (76 MB per version); see docs/BUILDING.md for the other targets.

Kestrel 2.3

Kestrel 2.3

A bug-fix release for two defects that were present since 2.0. Strength and speed are unchanged: the depth-12 bench gives the same 1,051,844 nodes in the same time.

What was fixed

• An integer overflow in the evaluation of endgames. The second layer of the network adds up 1,536 products in a 32-bit integer. For a few strongly negative ("dead") neurons of the output bucket that is used with 5 pieces or fewer, the exact sum can fall below -2^31; the 32-bit sum then wraps around to a large positive number and the neuron is read as fully on instead of fully off. A sanitizer run on GitHub Actions found it (UBSan: signed integer overflow), and an instrumented run counted it in the depth-12 bench: 9 of 797,651 evaluations, all in endgames with at most 5 pieces, always the same two neurons of one output bucket. The plain C++ code and the AVX2 code wrapped in the same way, so every platform and every build was affected equally. The sums are now accumulated in 32-bit floats: they cannot overflow, they are exact whenever the sum lies in the range where the neuron is not clipped, and the AVX2 and the plain code still agree exactly (the same bench on all builds). The effect of the old error on play is expected to be very small (it did not change the node count of the bench), but the evaluation of these endgame positions was wrong.
• Options with wrong defaults (this was the first fix of the day and is the whole of the unpublished 2.2). Kestrel 2.0 and 2.1 still declared options of the 1.x engines. NNBlend was declared with default 70 although the engine runs at 100, so a chess program that sends the declared default of every option (for example after "reset to defaults") made the engine mix the old hand-written evaluation into the search: scores changed by 20 to 25 % and some best moves changed. In a 600-game match at 3 + 0.03 that setting scored -6 +/- 17 Elo against the real default. NNBlend, Net2Share, UseNet2 and the development options (LazyMargin, EvalFlags, QsTT, CorrFlags, EvalCache, V31Flags, V31HistPrune, V31CutR, V31DE) are no longer declared, and the release builds ignore NNBlend. The 17 options that remain are listed in docs/OPTIONS.md. A new test (tests/options_test.py) sends every declared default and requires an identical search; 2.0 and 2.1 fail it, 2.2 and 2.3 pass.

What did not change

With the same settings, 2.3 and 2.2 search exactly alike in 16 of 18 test positions (one thread, 300,000 nodes each: best move, depth, score, node count and principal variation identical). The other two are endgames with few pieces, where the corrected evaluation changes the node count (a rook ending, same best move and score) or the score (a pawn ending: -584 instead of -544 centipawns, same best move), as expected from the fix. A 400-game match at 5 + 0.1 (one thread, the same openings for both sides) 2.3 against 2.2 scored +7 +/- 21 Elo (117 wins, 109 losses, 174 draws, all games ended normally). The depth-12 bench takes the same time (median of five runs: 770 ms for 2.3, 771 ms for 2.2). For the strength of this engine see the 2.0 release notes: about +37 +/- 11 Elo ahead of Kestrel 1.1 and +48 +/- 13 ahead of 1.0 over six time controls. No rating list has tested Kestrel.

Search ideas that did not help

I used a weekend of match time to test new search ideas and old switches against the same engine (3 + 0.03, one thread, 1,200 to 4,000 games each). None gave a measurable gain, so none is switched on; the table is in logs/fast_matches_2_2.txt. The code for the ideas stays in the source, switched off. It also turns the search constants into options (K22Flags and T_...), declared only in development builds (-DKESTREL_TUNE_OPTIONS). The multi-thread speed-up is modest (time to depth 14 with 2 / 4 / 8 threads: 1.11 / 1.20 / 1.35 times faster than with one), which is something to improve later.

Which file do I need?

File	For
Kestrel-2.3-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-2.3-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-2.3-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-2.3-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-2.3-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-2.3-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-2.3-linux-arm64.tar.gz	Linux ARM64
Kestrel-2.3-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-2.3-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it and switch OwnBook on if you want it). kestrel_net_2_0.bin is the network alone (the same file as in 2.0, 2.1 and 2.2; needed only to build from source or to load with EvalFile).

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower.

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (1,051,844 nodes), so the plain code and the AVX2 code agree exactly. On the x86-64-v3 exe the two black-box audits of 1.1 were repeated: 83 of 83 protocol and robustness cases and 31 of 31 rule checks against python-chess pass. The longer test suite of 1.1 was re-run on the 2.3 source as well: a GCC build and a clang AddressSanitizer + UBSan build (each also with 4 threads by default) pass 27 of 27 checks (accumulator self-test over 186,000 positions, perft, perft against python-chess, evaluation mirror symmetry, PV legality, UCI fuzzers, go infinite / stop races, MultiPV and ponder checks, bench), and the options test passes. The plain (non-AVX2) code is covered by the sanitizer job of the GitHub Actions workflow, which found the overflow. The logs are in logs/ of the repository.
• Linux and macOS: compiled with Zig and checked for file format. The files of 2.1 were run on GitHub Actions machines (Linux x86-64, Linux ARM64, macOS Apple silicon: same bench, a UCI session, and for the Linux x86-64-v3 build the whole test suite); the workflow in .github/workflows/verify-release.yml can be started for the tag v2.3, and it also builds the source with AddressSanitizer and UBSan on Linux. The macOS Intel build has not been run.
• The exe is about 88 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Building from source

src/kestrel_2_0.cpp (the file name is unchanged) embeds the network with .incbin "kestrel_net.bin", which the assembler looks up in the current directory: download kestrel_net_2_0.bin from this release, save it as kestrel_net.bin in the folder where you run the compiler, then for example

g++ -std=c++17 -O3 -march=x86-64-v3 -static -pthread -DNDEBUG -o kestrel.exe path/to/src/kestrel_2_0.cpp

The network is not stored in the git history (76 MB per version); see docs/BUILDING.md for the other targets.

Kestrel 2.1

Kestrel 2.1

A small release on top of 2.0: the same engine, the same network, the same moves. Only the default settings and the version label change, so that Kestrel starts the way chess-engine testers expect.

What changed

Setting	2.0	2.1
Hash	64 MB	256 MB
OwnBook (opening book)	on	off
Experience (position learning)	on	off

• If you want the opening book or position learning, switch OwnBook / Experience on. Chess programs that set Hash themselves are not affected by the new default.
• The experience file (kestrel_experience_v2.dat) is now only read and written when Experience is on.
• The depth-12 bench now gives 1,051,844 nodes (2.0: 934,326). The search did not change: the difference comes from the new defaults (every bench position is searched now, none is answered from the book, and the hash is larger).
• The engine reports itself as Kestrel 2.1. The network is the one from 2.0 (and 2.0 beta 1); the network file keeps its name, kestrel_net_2_0.bin.

I found no bug in 2.0 (see below), so this is not a bug-fix release in the strict sense.

Same moves as 2.0

With the same settings, 2.1 and 2.0 search exactly alike: on 18 test positions (one thread, 300,000 nodes each) the best move, depth, score, node count and principal variation were identical, with 2.1 on its default settings and 2.0 with Hash 256, OwnBook false and Experience false set by hand. In a 400-game match at 5 + 0.1 (one thread, the same openings for both sides) 2.1 on its defaults scored -3 +/- 19 Elo against 2.0 with those settings given explicitly (110 wins, 113 losses, 177 draws, all games ended normally): no difference, as expected.

Strength

Unchanged from 2.0, which played the same moves. Measured with 2.0 (fastchess, 1 thread, 32 MB hash, no book, no experience file): pooled over six time controls 2.0 is about +37 +/- 11 Elo ahead of Kestrel 1.1 (1,900 games) and about +48 +/- 13 ahead of Kestrel 1.0 (1,500 games); at 5 + 0.1 (600 games each) +38 +/- 20 against 1.1 and +64 +/- 21 against 1.0. At about 20 ms per move (1 + 0.01) it is roughly level with 1.1. The full table is in the 2.0 release notes. No rating list has tested Kestrel yet.

Which file do I need?

File	For
Kestrel-2.1-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-2.1-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-2.1-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-2.1-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-2.1-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-2.1-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-2.1-linux-arm64.tar.gz	Linux ARM64
Kestrel-2.1-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-2.1-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it and switch OwnBook on if you want it). kestrel_net_2_0.bin is the network alone (needed only to build from source or to load with EvalFile).

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower.

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (1,051,844 nodes), so the plain code and the AVX2 code agree exactly. On the x86-64-v3 exe the two black-box audits of 1.1 were repeated: 83 of 83 protocol and robustness cases and 31 of 31 rule checks against python-chess pass. The longer test suite of 1.1 was re-run on the 2.1 source as well: a GCC build and a clang AddressSanitizer + UBSan build (each also with 4 threads by default) pass 27 of 27 checks (accumulator self-test over 186,000 positions, perft, perft against python-chess, evaluation mirror symmetry, PV legality, UCI fuzzers, go infinite / stop races, MultiPV and ponder checks, bench). Before this release the 1.1 test battery was also run against 2.0 to look for bugs: 303 edge cases, Chess960 against python-chess, clock safety (480 cases, no overrun), thread stress with 4 and 8 threads, a memory soak test and python-chess interoperability all pass, and no bug was found. The logs are in logs/ of the repository.
• Linux and macOS: compiled with Zig and the file format checked, but not run (no such machine was available). Please open an issue if one does not start.
• The exe is about 88 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Building from source

src/kestrel_2_0.cpp (the file name is unchanged) embeds the network with .incbin "kestrel_net.bin", which the assembler looks up in the current directory: download kestrel_net_2_0.bin from this release, save it as kestrel_net.bin in the folder where you run the compiler, then for example

g++ -std=c++17 -O3 -march=x86-64-v3 -static -pthread -DNDEBUG -o kestrel.exe path/to/src/kestrel_2_0.cpp

The network is not stored in the git history (76 MB per version); see docs/BUILDING.md for the other targets.

Kestrel 2.0

Kestrel 2.0

The first Kestrel with one large neural network instead of two small ones plus a hand-written evaluation. In the matches below it scores above Kestrel 1.1 and 1.0 at every time control tested, at the price of an exe of about 88 MB, because the network is stored inside it.

The network is the one from 2.0 beta 1. The training run was stopped after about 70 of its 106 planned hours: of the snapshots saved every 3 hours, the 10th (after about 49 hours of training) and the 13th were the best on held-out positions (equal within 0.03 %), and the later ones were slightly worse (about 1 % higher loss; the training positions had been seen dozens of times, and the Lichess database has no more to offer). A 10-hour fine-tune of the end-of-run network on 1.5 million positions from fresh Kestrel games, with the learning rate lowered to zero, did not help either: against snapshot 10 it scored -6.7 +/- 11.2 Elo in 1,600 equal-node games, so snapshot 10 stays. The beta-1 and the 2.0 programs play the same moves; only the name the engine reports differs.

What is new compared with 1.1

• One network of 39 million parameters, stored inside the exe: 24,576 inputs per side (12 piece kinds x 64 squares x 32 horizontally mirrored king buckets), 1,536 integer accumulators per side, a pairwise-product activation, then 16 -> 32 -> 1 neurons with 8 output buckets chosen by the number of pieces. The hand-written evaluation and the second network of 1.x are gone: the evaluation is the network only.
• Trained on about 238 million positions of the Lichess evaluation database (Stockfish evaluations, CC0) plus 12 million positions from Kestrel's own games labelled by Stockfish, on the CPU with Adam. Stockfish is used only as a teacher; no Stockfish code is included.
• Fast evaluation code to pay for the size: the second layer skips the zero inputs (only about 10 % are non-zero), the first layer is updated only for positions that are really evaluated (about half of the positions the search makes never are), king moves use a refresh cache, weight rows are prefetched, and a go copies much less data. Together 1.95 times faster than the first version of 2.0, with exactly the same moves and scores (checked: same node counts, 186,000 accumulator checks against a from-scratch rebuild, Chess960 castling, multi-threaded search). In the depth-12 bench the AVX2 build does about 830,000 nodes per second on a performance core of the test laptop (Kestrel 1.1: about 1.2 million on a busy machine, so roughly 30 % fewer nodes per second).
• New UCI options: EvalFile (load another network file of the same format) and EvalScale (percent, 50 to 200, default 100: multiplies the network's output). Everything else is as in 1.1 (Chess960, WDL, analysis mode, MultiPV, bucketed hash table, up to 8 threads, optional book and experience file, no tablebases).

Strength

fastchess, 1 thread, 32 MB hash, no book, no experience file, 300 games per entry (600 for 5 + 0.1), the same openings for both sides. Elo is the 2.0 build against the older Kestrel; the value after +/- is fastchess's 95 % interval.

Time per game (base+increment, seconds)	against Kestrel 1.1	against Kestrel 1.0
1 + 0.01	+15 +/- 32	+28 +/- 33
2 + 0.02	+13 +/- 28	+51 +/- 31
3 + 0.03	+64 +/- 29	+31 +/- 28
5 + 0.1	+38 +/- 20 (600 games)	+64 +/- 21 (600 games)
10 + 0.1	+51 +/- 30 (240 games)	not measured
20 + 0.5	+41 +/- 36 (160 games)	not measured

Pooled over all time controls, 2.0 is about +37 +/- 11 Elo ahead of 1.1 (1,900 games) and about +48 +/- 13 ahead of 1.0 (1,500 games). Single entries at the shortest time controls (1 + 0.01 and 2 + 0.02 against 1.1, 1 + 0.01 against 1.0) are inside their error margins: at about 20 ms per move the large network is roughly level with 1.1. The 5 + 0.1 line was played with the packaged x86-64-v3 exe of this release; the others with the same program before it was renamed. These are matches on one laptop, and no rating list has tested Kestrel.

EvalScale was checked at 60, 80, 125 and 160 against the default 100 (600 games each at 5 + 0.1): -19 +/- 17, +1 +/- 16, +9 +/- 16 and -41 +/- 16 Elo. The curve is flat between 80 and 125, so the default stays 100.

Which file do I need?

File	For
Kestrel-2.0-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-2.0-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-2.0-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-2.0-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-2.0-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-2.0-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-2.0-linux-arm64.tar.gz	Linux ARM64
Kestrel-2.0-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-2.0-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it, or turn OwnBook off). kestrel_net_2_0.bin is the network alone (needed only to build from source or to load with EvalFile).

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower in the depth-12 bench (522,000 against 832,000 nodes per second).

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (934,326 nodes), so the plain code and the AVX2 code agree exactly. On the x86-64-v3 exe the two black-box audits of 1.1 were repeated: 83 of 83 protocol and robustness cases and 31 of 31 rule checks against python-chess pass. The longer test suite of 1.1 was re-run on the 2.0 source as well: a GCC build and a clang AddressSanitizer + UBSan build (each also with 4 threads by default) pass 27 of 27 checks (accumulator self-test over 186,000 positions, perft, perft against python-chess, evaluation mirror symmetry, PV legality, UCI fuzzers, go infinite / stop races, MultiPV and ponder checks, bench), and a fuzz campaign (about 8,900 random UCI command sequences on four builds, 550 random FEN positions, perft against python-chess on 450 positions to depth 4 and 4,500 to depth 3) found no problem. The logs are in logs/ of the repository.
• Linux and macOS: compiled with Zig and the file format checked, but not run (no such machine was available). Please open an issue if one does not start.
• The exe is about 88 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Building from source

src/kestrel_2_0.cpp embeds the network with .incbin "kestrel_net.bin", which the assembler looks up in the current directory: download kestrel_net_2_0.bin from this release, save it as kestrel_net.bin in the folder where you run the compiler, then for example

g++ -std=c++17 -O3 -march=x86-64-v3 -static -pthread -DNDEBUG -o kestrel.exe path/to/src/kestrel_2_0.cpp

The network is not stored in the git history (76 MB per version); see docs/BUILDING.md for the other targets.

Kestrel 2.0 beta 1 (pre-release)

Kestrel 2.0 beta 1 (pre-release)

The first Kestrel with one large neural network instead of two small ones plus a hand-written evaluation. This is a pre-release: the network is a snapshot from about the middle of the planned training run (about 49 of about 106 CPU training hours, learning rate not yet lowered). Training continues, and the final 2.0 will use the finished network.

What is new

• One network of 39 million parameters, stored inside the exe (so the exe is about 88 MB): 24,576 inputs per side (12 piece kinds x 64 squares x 32 horizontally mirrored king buckets), 1,536 integer accumulators per side, a pairwise-product activation, then 16 -> 32 -> 1 neurons with 8 output buckets chosen by the number of pieces. The hand-written evaluation and the second network of 1.x are gone: the evaluation is the network only.
• Trained on about 238 million positions of the Lichess evaluation database (Stockfish evaluations, CC0) plus 12 million positions from Kestrel's own games labelled by Stockfish, on the CPU with Adam. Stockfish is used only as a teacher; no Stockfish code is included.
• Fast evaluation code to pay for the size: the second layer skips the zero inputs (only about 10 % are non-zero), the first layer is updated only for positions that are really evaluated (about half of the positions the search makes never are), king moves use a refresh cache, weight rows are prefetched, and a go copies much less data. Together 1.95 times faster than the first version of 2.0, with exactly the same moves and scores (checked: same node counts, 186,000 accumulator checks against a from-scratch rebuild, Chess960 castling, multi-threaded search). In the depth-12 bench the AVX2 build does about 830,000 nodes per second on a performance core of the test laptop (Kestrel 1.1: about 1.2 million on a busy machine, so roughly 30 % fewer nodes per second).
• New UCI options: EvalFile (load another network file of the same format) and EvalScale. Everything else is as in 1.1 (Chess960, WDL, analysis mode, MultiPV, bucketed hash table, up to 8 threads, optional book and experience file, no tablebases).

Strength so far

fastchess, 1 thread, 32 MB hash, no book, no experience file, 300 games per entry, the same openings for both sides. Elo is the new network build against the older Kestrel; the value after +/- is fastchess's 95 % interval.

Time per game (base+increment, seconds)	against Kestrel 1.1	against Kestrel 1.0
1 + 0.01	+15 +/- 32	+28 +/- 33
2 + 0.02	+13 +/- 28	+51 +/- 31
3 + 0.03	+64 +/- 29	+31 +/- 28

Only some of these are clearly above zero (3+0.03 against 1.1; 2+0.02 and 3+0.03 against 1.0). At 1+0.01 (about 20 ms per move) the large network is about level with 1.1. Longer time controls are being measured; the larger network should gain more with more time. These are short matches on one laptop, and no rating list has tested Kestrel.

Which file do I need?

File	For
Kestrel-2.0-beta1-windows-x86-64-v3.zip	Windows 64-bit, AVX2 + BMI2 CPUs (recommended)
Kestrel-2.0-beta1-windows-x86-64-v2.zip	Windows 64-bit, SSE4.2 + POPCNT CPUs
Kestrel-2.0-beta1-windows-x86-64.zip	Windows 64-bit, any CPU
Kestrel-2.0-beta1-linux-x86-64-v3.tar.gz	Linux x86-64, AVX2 + BMI2 CPUs
Kestrel-2.0-beta1-linux-x86-64-v2.tar.gz	Linux x86-64, SSE4.2 + POPCNT CPUs
Kestrel-2.0-beta1-linux-x86-64.tar.gz	Linux x86-64, any CPU
Kestrel-2.0-beta1-linux-arm64.tar.gz	Linux ARM64
Kestrel-2.0-beta1-macos-x86-64.tar.gz	macOS, Intel Macs
Kestrel-2.0-beta1-macos-arm64.tar.gz	macOS, Apple Silicon (M1 and newer)

The three Windows builds are also attached as plain .exe files (same program as in the zips; a plain exe has no opening book: put claude_book.txt next to it, or turn OwnBook off). kestrel_net_2_0_beta1.bin is the network alone (needed only to build from source or to load with EvalFile).

Only the x86-64-v3 builds have the AVX2 evaluation code (CPU with AVX2 and BMI2: most PCs since 2015). The v2 and generic builds work on older CPUs but are about 37 % slower in the depth-12 bench (522,000 against 832,000 nodes per second).

Status of each build

• Windows: all three builds were run here; each gives the same depth-12 bench (934,326 nodes), so the plain code and the AVX2 code agree exactly. On the x86-64-v3 exe the two black-box audits of 1.1 were repeated: 83 of 83 protocol and robustness cases and 31 of 31 rule checks against python-chess pass. The longer test suite of 1.1 (sanitizer verification, fuzz campaign) has not been re-run for 2.0 yet.
• Linux and macOS: compiled with Zig and the file format checked, but not run (no such machine was available). Please open an issue if one does not start.
• The exe is about 88 MB and is not code-signed; some virus scanners are suspicious of big unsigned programs (1.0 had a false positive, see docs/BUILDING.md).

Building from source

src/kestrel_2_0.cpp embeds the network with .incbin "kestrel_net.bin", which the assembler looks up in the current directory: download kestrel_net_2_0_beta1.bin from this release, save it as kestrel_net.bin in the folder where you run the compiler, then for example

g++ -std=c++17 -O3 -march=x86-64-v3 -static -pthread -DNDEBUG -o kestrel.exe path/to/src/kestrel_2_0.cpp

The network is not stored in the git history (76 MB per version); see docs/BUILDING.md for the other targets.

Kestrel 1.0

Kestrel 1.1 (development version 40.1): bug-fix release

K+N+N v K evaluates 0, 8 MB search-thread stacks off Windows, book and experience file found next to the real executable on Linux and macOS,
source builds for every CPU target without a patch (scripts/patch_source.py removed). Networks, book and search unchanged.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>