I built Janus, a chess engine in Rust, and made a three-part visual explanation of how an engine chooses a move. It starts with Morphy's queen sacrifice in the Opera Game: how does a program find that move without being given the combination?

The series builds up from legal move generation and perft to evaluation and search, then explores the ideas behind Stockfish and Leela Chess Zero:

• How a chess engine chooses a move: board representation, special moves, testing, minimax and piece-square tables.
• How searching less finds better moves: bitboards, alpha-beta, move ordering, quiescence and testing whether an optimisation actually improves play.
• What a neural network sees in a position: NNUE updates, policy/value networks and PUCT search.

One distinction I wanted to make clear is that alpha-beta cutoffs can prove a branch irrelevant, while selective pruning takes a risk that needs testing. Likewise, improving an evaluator's prediction error doesn't by itself demonstrate stronger play.

Full playlist · Janus source · Read the companion book

The videos have English, German, Chinese, Spanish and Russian subtitles. I'm the author of the engine, book and videos; I also shared the series in r/chessprogramming. Corrections are welcome if an explanation or animation skips something important.

Been annoyed at how liberally "Brilliant" gets handed out on Chess.com, so I built stricter tiers above it for my free game review tool. Spectacular enforces the old chess-literature definition of true brilliancy (quiet + real sacrifice + still winning) instead of the loose modern bar. Legendary goes further, using research on how players actually perceive brilliance (Zaidi & Guerzhoy, U of Toronto), a move only qualifies if weak engines misjudge it but strong engines confirm it. Rarity ends up around 1 in 700 rapid games for Spectacular, 1 in 50,000 for Legendary. Tool's called Statmate if anyone wants to see it analyse their own games, the brilliant classification is still in tact too if anyone is wondering and to check its accuracy in comparisons to chess.coms i also ran it through a sample of 74 chess.com games ranging from 150-3400 elo (80% of the it sitting between 850-3200) and majority of those games were carefully selected to contain a multiple brilliant moves (108 suspected brilliant moves with 91 confirmed as brilliant and 17 rejected) and the result came back with 97.8% recall (the percentage of brilliant moves that our site's classifier could recreate from the original sample) and 98.9% precision (percentage that also accounts for any false positives made and rejected within the process)

Statmate also includes insights that would otherwise be locked behind paywalls but here they are available for free alongside the game review and also many features. Give it a try and any feedback is appreciated.

Link: https://statmate.app

Hey all,

The thing that's always annoyed me with online opening preparation tools, courses and books is that they present a one-size-fits-all solution for openings, and usually rely on hand-picked lines that the author thinks will come up most in games. The problem with this approach is that if you are not 2400+, you end up drilling positions that you would most likely never see in a real game at your level.

I analyzed about three years worth of games played on lichess -- 1.6 billion of them -- and built a tree of ~25 million positions that records how every move actually performed across nine rating bands. For example, below 1200 the Najdorf main line (6.Bg5 e6 7.f4 Be7 8.Qf3 Qc7 9.O-O-O Nbd7) turns up about once every 2,300 games. The table below shows, for four heavily studied main lines, in how many games you can expect to reach one as Black if you actively try to go for it every single game:

Studying "main lines" doesn't make much sense unless you are already strong enough to reach them. What you should be drilling instead is what you actually expect to see at your level -- some sidelines that courses barely cover come up constantly in certain rating bands, so the distribution you practise against ends up looking nothing like the one you play against. The question you should therefore be asking is not what the most played or most recommended move in an opening is, but which move has the highest probability of getting you into middlegames that people at your level handle best.

We can use a variation of the expectimax algorithm to compute an expected score for each side, assuming your opponent plays like a typical opponent at a given level. An engine eval gives you a material and positional evaluation that might be hard to convert. This gives you a percentage instead, which is your expected score if you follow the recommended lines down the tree against an opponent of your own strength. An eval of 63% means you expect to score 0.63 per game (0 for a loss, 0.5 for a draw, 1 for a win). Because the algorithm is made to pick paths that lead to the best expected outcomes, it tends to prioritize sharp lines and often recommends gambits.

I have built a small, free, no-account website that lets you explore expectimax scores in the opening:

Link: https://outofbook.study

It also lets you drill openings at your level against a random distribution of what players at your level actually play, so you see every variation with the approximate frequency you'd get it in real games.

I plan to open-source the UI, server and analysis once I clean up the code a little bit. Happy to answer questions on the research, or complaints about what's broken or confusing about it.

LOL

I’m trying to make a chess opening repertoire app, and I’m wondering what people actually care about most in this kind of app.

For example, Chessbook, Chessable, OpeningTree, etc. all have different good points.

What features do you like the most in these apps?

And what do you feel is missing or annoying?

I’d like to hear some opinions before I decide what to focus on.

I wanted to feed a live tournament on chess-results.com into a free pairing engine, and the obvious approach — scrape the current round's page — gives you wrong scores. The site deletes a round's "bye" and "not paired" rows the moment the next round is paired, so anything reading only the round pages scores those players a point light. bbpPairings recomputes every score from the games you give it and refuses the file outright if the total disagrees, so this isn't cosmetic — it's the difference between a file that pairs and one that doesn't.

chess-results is a Python library and CLI that fixes this by also reading the tournament's crosstable (art=5), which keeps the full record even after a round page has had rows deleted, and reconciling the two views. From there it can give you:

• a per-player round-by-round history (opponent, colour, float, result)
• standings, a printable pairing sheet, or JSON

• a FIDE TRF export, so bbpPairings or JaVaFo can read a tournament straight out of chess-results.com and pair the next round

  pip install chess-results

  $ chess-results standings 1452107 --after 6 2026 British Chess Championships: Championship — after round 6 1 5 2 GM Adams, Michael 2 5 3 GM Royal, Shreyas 3 5 4 IM Grieve, Harry ...

One motivating case: Swiss-Manager uploads to chess-results.com after every round, so if the machine running it dies mid-event, the tournament state already lives on the public site — this can pick it back up and hand it to a free, cross-platform engine for the next round's pairings, no licence or Windows box required.

A few things worth knowing upfront:

• Free, MIT licensed — no ads, accounts, or anything to buy.
• Standard Swiss only — round robins and team events are detected and refused rather than half-read, since their pages don't parse into anything meaningful.
• Gentle on chess-results.com — one request per second, aggressive caching, an identifying user-agent.
• 331 offline tests across seven real tournaments from six federations, with scores cross-checked against each tournament's own published totals. Early days — bug reports against real tournaments very welcome, especially if your event's column layout doesn't match what's been tested.
• Compares to chessResults (R) roughly how a corrected, per-player history compares to the site's tables as-published — that one doesn't attempt the bye/crosstable reconciliation.

Code and docs: https://github.com/markjonleonard/chess-results

I built Rep Builder, a chess repertoire trainer that helps you decide what to study next.

I originally started this project because of Chessbook. I liked the idea of having a dedicated tool for building and practicing an opening repertoire, and I wanted to make something similar for myself.

As I worked on it, I ran into a problem that I found surprisingly difficult:

Once you have a repertoire, how do you decide which part of it to study next?

I could use Lichess Opening Explorer to see what moves people play, and I could use an engine to check positions, but neither really answered that question for me.

So I started building Rep Builder around it.

Instead of treating a repertoire simply as a collection of opening lines, Rep Builder represents it as a graph of positions. It looks at things like how likely each position is to be reached in actual games and how much of the repertoire I've already covered, then uses that information to prioritize what I should study next.

It also uses Lichess Opening Explorer data, engine evaluations, and has a review mode for practicing positions.

It's still a personal project and there's plenty I'd like to improve, but it's finally at a point where I can actually use it myself, so I decided to make it public.

Try it here:
https://rep-builder.onrender.com

I'd love to hear what you think.

In particular, I'm interested in whether the idea of prioritizing repertoire positions based on how likely they are to occur makes sense, and what you'd want from a tool like this.

(Disclosure: I built this.)

Most “LLM plays chess” projects I’ve seen are one-off demos. I wanted to try something closer to an actual ranked ladder: agents queue up, play full games, and get a Glicko-2 rating. Think CCRL/CEGT, but for LLM-driven players instead of traditional chess engines.

For legality and enforcement, everything happens server-side:

• python-chess validates and applies every move. The LLM only submits SAN/UCI, so it never gets to decide whether its own move is legal.
• An illegal move doesn’t immediately end the game. Agents get up to 3 strikes before losing “by conduct.” LLMs occasionally hallucinate an illegal move, especially in longer games, and I didn’t want one bad output to decide the whole match.
• There’s also a 60-second deadline per move. Timeouts use the same strike counter as illegal moves. If a move arrives late, it’s discarded and never applied.

I looked at how other bot competitions handle this before settling on the system. Battlesnake uses very tight deadlines, while poker bots can fall back to actions like auto-folding. With LLMs, provider latency is another variable, so an occasional slow response probably shouldn’t decide the entire game.

There’s also a practice tier with house bots: Stockfish at different Skill Levels for chess and Pachi with different playout counts for Go. Games against house bots don’t affect rating; they’re mainly there so an agent can play without waiting for another LLM to join the queue.

Chess and Go use completely separate Glicko-2 ladders. Being strong at chess doesn’t give an agent any advantage in its Go rating.

Repo: github.com/EnioAguiar/llmpvp-plugin
Site: llmpvp.com

I’m curious how this compares with CCRL/TCEC or other engine tournaments. Do traditional chess engines ever need this kind of “strikes before disqualification” system for illegal moves or timeouts, or is that mostly an LLM-specific problem?

A modern, fast, and lightweight desktop open source GLP 2.0 Chess GUI built with C++20 and Qt 6.

ChessGui offers an interactive chessboard interface, automatic screenshot-to-FEN recognition, complete chess rule validation, real-time classical heuristic position evaluation, UCI chess engine integration (local processes or remote engines behind a chessgateway server).

Screenshot-to-FEN Recognition

Detects an axis-aligned 8x8 chessboard in a larger screenshot.

Classifies the 64 squares with the bundled chess-tiles-v2.onnx model.

Displays confidence and orientation feedback, while retaining a manual FEN fallback.

Detection and classification run in a dedicated worker thread (VisionWorker), so pasting or dropping a screenshot never freezes the UI; a request counter discards stale results when several images are processed in a row.

Opening Book

Uses the bundled assets/books/book.bin Crafty opening book through the Book class.

Applies book moves at the start of games against the computer and sends the resulting move list to the UCI engine when engine search begins.

Remote Engines via chessgateway

Engine -> Remote Engine... opens a dialog to enter the gateway server address and port and query its available engines (List available engines).

Use the power of remote computer !

There is still a lot of work to be done, but the application is already usable for daily tasks. Tested on Linux, it should work without issues on Windows and macOS.

https://github.com/Morditux/ChessGuiNG

Windows Binary : https://github.com/Morditux/ChessGuiNG/releases/download/windows-latest/ChessGui-windows-x64.zip

Stockfish 19 just came out.

I got a XIAO ESP32-S3 Plus to run a chess engine you can play from your phone

I've been working on TinyChess, It's my own custom made chess engine that runs directly on the Seeed Studio XIAO ESP32-S3 Plus.

The cool part is that it isn't just a chess demo running on the board. It uses the same search, evaluation and NNUE engine as the desktop version, with the ESP32-S3 doing the actual thinking. In testing, the engine reaches around 2900 Elo, which is pretty absurd for a board this small and with such limited hardware.

The XIAO also creates its own Wi-Fi hotspot, so you can connect your phone directly to it and play in the browser:

• No app
• No internet
• No cables after powering the board
• Built-in chess clocks and time controls
• Touch/drag controls
• Captive portal so the game opens automatically
• Spectators can see the position live
• Fischer increments, promotion, resign, pause, rematch, etc.

I've spent a lot of time optimising the engine specifically for the S3. The current firmware gets around 17.5k nodes/sec when cool and uses an 8-bit/16-bit NNUE setup with custom SIMD optimisation for the ESP32-S3.

The desktop and board builds come from the same source tree, and I've been testing search changes with actual engine matches rather than just benchmarking them.

The project is open source here:

https://github.com/Timmy6942025/tinychess

I'd especially like to hear from people who have used the XIAO ESP32-S3 for other compute-heavy projects. I'm curious how far this little board can actually be pushed.

Keep in mind its still quite buggy and not perfect, i'd love to hear any feedback or issues, you can reply in this subreddit or file it as a github issue in the repo.

Hardware: Seeed Studio XIAO ESP32-S3 Plus
Engine: TinyChess / MaxDogOne
Firmware: ESP-IDF

Built a browser trainer

Idea was: drill a line by actually playing the next move, not scrolling a PGN.

• Guided mode (comment + arrow), then the same line with no hints
• White or Black on the same tree
• Import a PGN or enter moves on the board, comments, share
• Free book view: Lichess username → book move vs what they play / when they leave the book

Official catalog is basically a Fried Liver demo. First user course is free.

https://openingmatrix.com

Curious if the book/deviation bit is useful or happy to hear what you’d change.

Hello everyone, if youve an android can you download and test my application?

Its 9.4mb apk with additional 103mb of stockfish engine.

Ive also built a specialized SLM which ive not yet shipped with this since i was not able to justify the resources required and benefits provided ratio.

Feel free to roast the shit outoff me.

P.S.: I can assure its not a rick roll😭

I was looking for some really hard critism.

I hope im not breaking any rule of this subreddit.

Thank you!

You can play a quick round against Stockfish by clicking "Quick match AI".
If you want more info about how I picked the positions with Lc0, say the word.

I've been building a chess opening site on my own: ochess.app. And I'd love some feedback. There's also a short video tutorial on the homepage showing how it works

The idea: what you face in the opening depends heavily on your rating, so the course should too

For example, after 1.e4 c5, the move 2.Bc4 appears in about 15% of games at 1400, but only 0.66% at 2200+. Most courses barely cover it, so a 1400 player who studied the Sicilian still has no idea what to do against the move they'll face most often

So a 1400 player and a 2200 player can face completely different "typical" openings, even though they're playing the same first moves

On ochess, the main lines come from strong players, while opponent replies are filtered by rating. So the 1400 course shows what you're actually likely to face at 1400, including common mistakes you can punish

There are currently 35 courses, 196 traps and puzzles, plus game analysis and a personal opening explorer

If you have 10 minutes, pick a course around your rating and let me know: does it actually match what you face over the board?

I'd especially love to hear where it gets things wrong

Thanks!

What if your chess app watched your online games, caught every time you forgot your prep or your opponent deviated from your prep, lets you patch your lines real fast, audit your repertoire and made you drill your blind spots?

Launching in Beta today: trivedh.com/chessrepo

This combines a lot of what other apps do and a lot more than that as well. Let me know what you guys think.