Hi there,
I’d like to introduce a new open-source chess engine called Pastèque: https://github.com/vshcherbyna/pasteque
I originally started working on Pastèque in 2018. Development stopped later that year when I shifted most of my attention to Igel.
Recently, while looking through an old hard drive, I found some uncommitted Pastèque source code. That gave me enough motivation to clean things up a little and finally make the project public rather than leave it sitting on a disk.
The first release is Pastèque 0.0.0 - binaries for windows are here.
At this stage, the evaluation function is initialized with random weights, so the engine does not play good chess yet. The search is functional, though, and the engine is already capable of playing complete games.
For now, this release is mostly about publishing and preserving the work that was done back in 2018. I may continue developing it further, depending on time and motivation.
In case of any questions/suggestions please ask them in the main Pastèque thread at viewtopic.php?p=997657#p997657
New engine releases 2026 H2
Moderator: Ras
-
voffka
- Posts: 302
- Joined: Sat Jun 30, 2018 10:58 pm
- Location: Ukraine
- Full name: Volodymyr Shcherbyna
-
CJDC
- Posts: 12
- Joined: Wed Oct 19, 2022 4:54 pm
- Full name: Christopher Crone
Re: New engine releases 2026 H2
Greetings,
Yakka v1.6 released.
https://github.com/CJDalrymple/Yakka
Implemented support for Syzygy table bases and MultiPV.
Yakka supports multi-thread search and pondering.
Modest strength increase over last release due to parameter tuning and bug fixes.
Regards to all.
Yakka v1.6 released.
https://github.com/CJDalrymple/Yakka
Implemented support for Syzygy table bases and MultiPV.
Yakka supports multi-thread search and pondering.
Modest strength increase over last release due to parameter tuning and bug fixes.
Regards to all.
-
Andres Valverde
- Posts: 624
- Joined: Sun Feb 18, 2007 11:07 pm
- Location: Almeria. SPAIN
- Full name: Andres Valverde Toresano
Re: New engine releases 2026 H2
Saludos, Andres
-
FlavusSnow
- Posts: 93
- Joined: Thu Apr 01, 2010 5:28 am
- Location: Kansas City, MO
- Full name: James Coit
Re: New engine releases 2026 H2
Introducing FunComp 1.0
https://github.com/Moxnar/FunComp
Strength: About 3030 on the CCRL Blitz scale: 3031 ± 14 from a
gauntlet of 2,040 games at 10+0.1
Hobby engine. I'm hoping to have the next version out around Christmas time.
I'd love to see it on CCRL if anyone has the power to do that. I'm really enjoying getting back into computer chess and plan to keep updating this thing going forward.
https://github.com/Moxnar/FunComp
Strength: About 3030 on the CCRL Blitz scale: 3031 ± 14 from a
gauntlet of 2,040 games at 10+0.1
Hobby engine. I'm hoping to have the next version out around Christmas time.
I'd love to see it on CCRL if anyone has the power to do that. I'm really enjoying getting back into computer chess and plan to keep updating this thing going forward.
-
NichtElias
- Posts: 6
- Joined: Fri Jun 05, 2026 7:14 pm
- Full name: Elias Niemann
Re: New engine releases 2026 H2
Erinn 2 just released.
Testing against Stash 30 suggests a rating of around 3150 Elo at tc 10+0.1
Try it out here: https://github.com/NichtElias/Erinn/releases/tag/v2
Testing against Stash 30 suggests a rating of around 3150 Elo at tc 10+0.1
Try it out here: https://github.com/NichtElias/Erinn/releases/tag/v2
-
CMCanavessi
- Posts: 1150
- Joined: Thu Dec 28, 2017 4:06 pm
- Location: Argentina
Re: New engine releases 2026 H2
After taking a bit of time off, time for a new release. This time there's no 400+ elo improvement, only a modest +130, apparently. It's getting hard to extract elo from single thread HCE.
Facón 1.7 - Filo
https://github.com/CMCanavessi/facon/releases/tag/v1.7
Approximately +130 Elo over 1.6 (Ordo ~2930, Gauntlet 4 n=1040). Direct self-play vs 1.6: +139.1 Elo (n=10000) at 10+0.1.
Where 1.6 was an evaluation overhaul and 1.5 was one critical bug fix, 1.7 is split almost evenly between search and evaluation, and no single change dominates. The search gained a family of history tables, a static evaluation that is always available and cached in the transposition table, singular extensions, ProbCut, and a pawn-structure cache. The evaluation gained threat terms broken down by attacker and victim -- the largest single feature of the cycle -- plus endgame scaling that resolves a limitation carried since 1.5, and a re-fitted weight set.
Development was incremental and strict: every feature was added alone, measured in self-play against the previous accepted build, and kept only if it measured positive. Six were implemented in full and dropped. Two long checkpoint matches against 1.6 were run mid-cycle to keep the accumulated total honest, since summing individual gains overstates it.
Search -- move ordering
Two-sided history heuristic: the butterfly history table now applies a penalty as well as a bonus. A quiet move that causes a cutoff is rewarded; every quiet move searched before it at the same node is penalized by the same amount. Both updates use a gravity form that decays entries toward a fixed asymptote instead of saturating them. About +15 Elo.
Continuation history: a second history table conditioned on the opponent's previous move -- how good a move has been as a reply to that specific move, the generalization of the countermove heuristic. Combined one-to-one with the butterfly table. Persists across searches within a game. About +25 Elo.
Search -- evaluation channel and pruning
Static evaluation always available, cached in the transposition table: every position outside check now has a static evaluation, taken from the transposition table when the position was seen before, computed otherwise, and refined by a usable stored score bound. Entries carry it at no size cost: the stored move was packed into its natural 16 bits, freeing exactly the two bytes needed, and entries remain exactly 16 bytes. About +20 Elo, and it made the next three items possible.
Improving detection: with an evaluation at every node, the search can tell whether its position has been getting better since its previous move and modulate three pruning decisions accordingly -- in opposite directions, deliberately. Reverse futility prunes more when improving, move-level futility prunes less, and late move pruning tightens when not improving.
Singular extensions: when the transposition table knows a node's best move to serious depth, the node re-searches itself with that move excluded against a window just below the stored score. If everything else falls short, that move is the only good one and is searched one ply deeper. About +5 Elo.
ProbCut: at non-principal-variation nodes of sufficient depth, a shallow search of a sound capture that already beats beta by a solid margin cuts the node immediately. Slightly positive over 17,000 games; kept because it costs no speed and shrinks the tree markedly at depth.
Search -- speed
Pawn structure cache: the pawn-structure part of the evaluation depends on nothing except where the pawns are. The board now maintains a second Zobrist key covering pawn placement alone, updated incrementally by the same code that maintains the main key, and the result is cached under it. Since pawn structure changes rarely during a search, most evaluations retrieve that work instead of repeating it. The cached values are identical to the computed ones by construction, so the benchmark signature is unchanged -- which is what proves the cache correct. About +20 Elo from the speed alone.
Evaluation
Threat evaluation: what each side is attacking, broken down by attacker and victim rather than as one generic term -- pawns hitting minor pieces, pawns hitting rooks or queens, minor pieces hitting rooks or queens, rooks hitting the queen, enemy pieces attacked without being defended, and pawn advances that would create a threat from their new square. The attack maps this needs are the ones the mobility calculation already builds, so they are gathered there rather than recomputed, keeping the cost to about half a percent of search speed. About +50 Elo -- the single largest gain of the release, and measured before the new terms were fitted.
Endgame recognition and scaling: the final evaluation is multiplied by a factor chosen from the material signature -- heavily reduced when the stronger side cannot force mate at all, moderately reduced for a rook against a single minor with no pawns, partly reduced for opposite-coloured bishops with a pawn difference of at most one. Combinations that genuinely win are untouched. The factor is never zero: an outright override to zero was tried in 1.5 and cost about 30 Elo, most likely because it erased the difference between keeping a piece and giving it away. About +8 Elo.
Re-fitted weight set: all 946 evaluation weights re-optimized against a corpus of 7.15 million labelled positions after the threat terms were added with hand-chosen starting values. The correction concentrated where expected: the twelve threat weights moved about seven times more than the average of the rest, and moved coherently -- middlegame values up, endgame values down, matching what a threat is worth in each phase. About +6 Elo.
Robustness
Hash option hardened, single-blend evaluation with a bit-exact trace, unlimited game history, maximum search ply raised to 256, and search depth clamped to the supported range. See the changelog for details; all measured neutral in self-play, as intended.
Features attempted and not shipped
Capture history: roughly neutral over 16,250 games. The existing capture ordering was apparently already good enough that a learned refinement had nothing to add.
History pruning: killed by instrumentation before any games were played. With efficient move ordering, genuinely bad quiet moves are rarely searched at all, so the penalty falls mostly on good-but-not-best moves; pruning on it made the tree grow rather than shrink.
Principal variation search, two forms: both measured negative. Before the change every move at a principal-variation node produced an exact score for the transposition table; scouting replaces most of those with bounds, and the lost information costs more than the saved nodes return.
Correction history: learning where the static evaluation is systematically wrong. Its expected range was ruled out early and it never separated from zero.
Known limitations resolved
Drawn pawnless endings evaluated as material, carried from 1.5 and 1.6: resolved by the endgame scaling above. King and bishop against a lone king now evaluates near zero instead of near the value of a bishop.
Checksums (SHA1)
451890efd943e30113fd221f84eee0e229b98041 facon-1.7
0b39fa81e9326b4b172a61c71dccf12183940f01 facon-1.7.exe
https://github.com/CMCanavessi/facon
Facón 1.7 - Filo
https://github.com/CMCanavessi/facon/releases/tag/v1.7
Approximately +130 Elo over 1.6 (Ordo ~2930, Gauntlet 4 n=1040). Direct self-play vs 1.6: +139.1 Elo (n=10000) at 10+0.1.
Where 1.6 was an evaluation overhaul and 1.5 was one critical bug fix, 1.7 is split almost evenly between search and evaluation, and no single change dominates. The search gained a family of history tables, a static evaluation that is always available and cached in the transposition table, singular extensions, ProbCut, and a pawn-structure cache. The evaluation gained threat terms broken down by attacker and victim -- the largest single feature of the cycle -- plus endgame scaling that resolves a limitation carried since 1.5, and a re-fitted weight set.
Development was incremental and strict: every feature was added alone, measured in self-play against the previous accepted build, and kept only if it measured positive. Six were implemented in full and dropped. Two long checkpoint matches against 1.6 were run mid-cycle to keep the accumulated total honest, since summing individual gains overstates it.
Search -- move ordering
Two-sided history heuristic: the butterfly history table now applies a penalty as well as a bonus. A quiet move that causes a cutoff is rewarded; every quiet move searched before it at the same node is penalized by the same amount. Both updates use a gravity form that decays entries toward a fixed asymptote instead of saturating them. About +15 Elo.
Continuation history: a second history table conditioned on the opponent's previous move -- how good a move has been as a reply to that specific move, the generalization of the countermove heuristic. Combined one-to-one with the butterfly table. Persists across searches within a game. About +25 Elo.
Search -- evaluation channel and pruning
Static evaluation always available, cached in the transposition table: every position outside check now has a static evaluation, taken from the transposition table when the position was seen before, computed otherwise, and refined by a usable stored score bound. Entries carry it at no size cost: the stored move was packed into its natural 16 bits, freeing exactly the two bytes needed, and entries remain exactly 16 bytes. About +20 Elo, and it made the next three items possible.
Improving detection: with an evaluation at every node, the search can tell whether its position has been getting better since its previous move and modulate three pruning decisions accordingly -- in opposite directions, deliberately. Reverse futility prunes more when improving, move-level futility prunes less, and late move pruning tightens when not improving.
Singular extensions: when the transposition table knows a node's best move to serious depth, the node re-searches itself with that move excluded against a window just below the stored score. If everything else falls short, that move is the only good one and is searched one ply deeper. About +5 Elo.
ProbCut: at non-principal-variation nodes of sufficient depth, a shallow search of a sound capture that already beats beta by a solid margin cuts the node immediately. Slightly positive over 17,000 games; kept because it costs no speed and shrinks the tree markedly at depth.
Search -- speed
Pawn structure cache: the pawn-structure part of the evaluation depends on nothing except where the pawns are. The board now maintains a second Zobrist key covering pawn placement alone, updated incrementally by the same code that maintains the main key, and the result is cached under it. Since pawn structure changes rarely during a search, most evaluations retrieve that work instead of repeating it. The cached values are identical to the computed ones by construction, so the benchmark signature is unchanged -- which is what proves the cache correct. About +20 Elo from the speed alone.
Evaluation
Threat evaluation: what each side is attacking, broken down by attacker and victim rather than as one generic term -- pawns hitting minor pieces, pawns hitting rooks or queens, minor pieces hitting rooks or queens, rooks hitting the queen, enemy pieces attacked without being defended, and pawn advances that would create a threat from their new square. The attack maps this needs are the ones the mobility calculation already builds, so they are gathered there rather than recomputed, keeping the cost to about half a percent of search speed. About +50 Elo -- the single largest gain of the release, and measured before the new terms were fitted.
Endgame recognition and scaling: the final evaluation is multiplied by a factor chosen from the material signature -- heavily reduced when the stronger side cannot force mate at all, moderately reduced for a rook against a single minor with no pawns, partly reduced for opposite-coloured bishops with a pawn difference of at most one. Combinations that genuinely win are untouched. The factor is never zero: an outright override to zero was tried in 1.5 and cost about 30 Elo, most likely because it erased the difference between keeping a piece and giving it away. About +8 Elo.
Re-fitted weight set: all 946 evaluation weights re-optimized against a corpus of 7.15 million labelled positions after the threat terms were added with hand-chosen starting values. The correction concentrated where expected: the twelve threat weights moved about seven times more than the average of the rest, and moved coherently -- middlegame values up, endgame values down, matching what a threat is worth in each phase. About +6 Elo.
Robustness
Hash option hardened, single-blend evaluation with a bit-exact trace, unlimited game history, maximum search ply raised to 256, and search depth clamped to the supported range. See the changelog for details; all measured neutral in self-play, as intended.
Features attempted and not shipped
Capture history: roughly neutral over 16,250 games. The existing capture ordering was apparently already good enough that a learned refinement had nothing to add.
History pruning: killed by instrumentation before any games were played. With efficient move ordering, genuinely bad quiet moves are rarely searched at all, so the penalty falls mostly on good-but-not-best moves; pruning on it made the tree grow rather than shrink.
Principal variation search, two forms: both measured negative. Before the change every move at a principal-variation node produced an exact score for the transposition table; scouting replaces most of those with bounds, and the lost information costs more than the saved nodes return.
Correction history: learning where the static evaluation is systematically wrong. Its expected range was ruled out early and it never separated from zero.
Known limitations resolved
Drawn pawnless endings evaluated as material, carried from 1.5 and 1.6: resolved by the endgame scaling above. King and bishop against a lone king now evaluates near zero instead of near the value of a bishop.
Checksums (SHA1)
451890efd943e30113fd221f84eee0e229b98041 facon-1.7
0b39fa81e9326b4b172a61c71dccf12183940f01 facon-1.7.exe
https://github.com/CMCanavessi/facon
My chess engine Facón: https://github.com/CMCanavessi/facon
-
Spunc595
- Posts: 38
- Joined: Mon Jul 06, 2026 12:15 am
- Full name: Daniele Marpino
Re: New engine releases 2026 H2
Luna v4.0.0 released (Custom NNUE, cross-platform ARM64/x86_64)
Hi everyone,
I'm pleased to announce the release of Luna v4.0.0, a major update to my UCI chess engine.
This release introduces a new custom-trained NNUE evaluation network, showing a significant jump in playing strength compared to previous versions.
Key Highlights & Technical Details
Evaluation: Custom NNUE network (768 \times 4 \to 1024 architecture with SCReLU activation and king-buckets, adapted/derived from akimbo).
Training Pipeline: Trained using the bullet framework on ~1 billion positions (derived from Linrock's Lc0 bullet dataset) over 8 epochs, with output scaling (SCALE = 358) tuned to match the WDL ramp.
Platforms Supported: Compiled binaries are available for Windows (x86_64), Linux (arm64), and Android (arm64).
Early internal testing and mobile trial runs show very promising results over v3.1.7.
Downloads & Repository
Release page: https://github.com/Spunc595/Luna-Chess- ... tag/v4.0.0
GitHub Repository: https://github.com/Spunc595/Luna-Chess-Engine
Any feedback, bug reports, or test results (especially from rating lists or mobile testing queues) are greatly appreciated!
Best regards,
Spunc595
Hi everyone,
I'm pleased to announce the release of Luna v4.0.0, a major update to my UCI chess engine.
This release introduces a new custom-trained NNUE evaluation network, showing a significant jump in playing strength compared to previous versions.
Key Highlights & Technical Details
Evaluation: Custom NNUE network (768 \times 4 \to 1024 architecture with SCReLU activation and king-buckets, adapted/derived from akimbo).
Training Pipeline: Trained using the bullet framework on ~1 billion positions (derived from Linrock's Lc0 bullet dataset) over 8 epochs, with output scaling (SCALE = 358) tuned to match the WDL ramp.
Platforms Supported: Compiled binaries are available for Windows (x86_64), Linux (arm64), and Android (arm64).
Early internal testing and mobile trial runs show very promising results over v3.1.7.
Downloads & Repository
Release page: https://github.com/Spunc595/Luna-Chess- ... tag/v4.0.0
GitHub Repository: https://github.com/Spunc595/Luna-Chess-Engine
Any feedback, bug reports, or test results (especially from rating lists or mobile testing queues) are greatly appreciated!
Best regards,
Spunc595
-
Andres Valverde
- Posts: 624
- Joined: Sun Feb 18, 2007 11:07 pm
- Location: Almeria. SPAIN
- Full name: Andres Valverde Toresano
Re: New engine releases 2026 H2
Saludos, Andres
-
Andres Valverde
- Posts: 624
- Joined: Sun Feb 18, 2007 11:07 pm
- Location: Almeria. SPAIN
- Full name: Andres Valverde Toresano
Re: New engine releases 2026 H2
There was a problem with the file. Now it must be solved. (hopefully)Andres Valverde wrote: ↑Sun Oct 04, 2026 8:12 pm Caligula 8.0 released
https://sites.google.com/view/dirtychess/dirtychess
Saludos, Andres
-
FlavusSnow
- Posts: 93
- Joined: Thu Apr 01, 2010 5:28 am
- Location: Kansas City, MO
- Full name: James Coit
Re: New engine releases 2026 H2
After adding an initiative term to the evaluation, Syzygy tablebase support, and a full SPSA tune, the Elo gain was large enough that I felt it earned a new version number:
FunComp 2.0
https://github.com/Moxnar/FunComp
About 3280 +/- 10 on the CCRL Blitz scale, roughly +245 over 1.0. That's my own estimate from a single-threaded gauntlet of 2,880 games against 24 rated engines, not an official CCRL rating. FunComp 2.0 also supports Lazy SMP now for those who run multithreaded. Windows binaries are provided for AVX2/BMI2 CPUs and for any x86-64 CPU.
Next step is NNUE, which will take a while since I'm generating my own training data.
FunComp is written using AI tools, specifically Claude Code. Now that I've coded both with and without them, I want to say this plainly: writing software today is not the same as writing software even a year or two ago. I started in computer chess back in the mid '90s and wrote my first move generator (poorly) in Perl, so I know the difference AI has made. The people who came before me wrote their engines by hand, and I have not. I want to recognize their craftsmanship and say openly that it's a craft I don't have. I've been out of the hobby for more than ten years, and I'm sure there have been (and maybe still are) intense debates about using AI to code. I don't want to hide from that debate, and part of that means being open about the tools I use.
That said, I genuinely hope FunComp contributes to this community. I've pledged no copying and no training on others' data. I have ideas I want to try, and no one's going to try them for me, so buckle up Claude and let's burn some serious CPU hours. This is FunComp.
FunComp 2.0
https://github.com/Moxnar/FunComp
About 3280 +/- 10 on the CCRL Blitz scale, roughly +245 over 1.0. That's my own estimate from a single-threaded gauntlet of 2,880 games against 24 rated engines, not an official CCRL rating. FunComp 2.0 also supports Lazy SMP now for those who run multithreaded. Windows binaries are provided for AVX2/BMI2 CPUs and for any x86-64 CPU.
Next step is NNUE, which will take a while since I'm generating my own training data.
FunComp is written using AI tools, specifically Claude Code. Now that I've coded both with and without them, I want to say this plainly: writing software today is not the same as writing software even a year or two ago. I started in computer chess back in the mid '90s and wrote my first move generator (poorly) in Perl, so I know the difference AI has made. The people who came before me wrote their engines by hand, and I have not. I want to recognize their craftsmanship and say openly that it's a craft I don't have. I've been out of the hobby for more than ten years, and I'm sure there have been (and maybe still are) intense debates about using AI to code. I don't want to hide from that debate, and part of that means being open about the tools I use.
That said, I genuinely hope FunComp contributes to this community. I've pledged no copying and no training on others' data. I have ideas I want to try, and no one's going to try them for me, so buckle up Claude and let's burn some serious CPU hours. This is FunComp.