YaneuraOu: a shogi engine whose search core is reused by other programs

An engine that plugs into a GUI rather than a program you launch

YaneuraOu is described in the project as the world's strongest shogi engine, an AI player, a WCSC29 first place winner, educational and USI compliant. The claims about being the strongest are the project's own framing, and the tournament record is listed separately in the project documentation.

The important architectural fact is the last word of that description. USI compliance means the engine is a protocol server, not an application. It exposes a standard interface, and a separate graphical program speaks to it over a pipe or a socket. That is why the project has a wiki page titled installation instructions for the engine and another one titled installation instructions for FukauRaOu, rather than a single application download, and why the project documentation's list of wiki articles includes recommended engine settings, engine options, frequently asked questions, hidden features and USI extended commands.

The engine's own capabilities are listed in a way that is worth reading closely, because the list is a specification of what a modern shogi engine has to do. It is a thinking engine compliant with the USI protocol. It handles tsume declarations of victory and try rules. It supports Ponder, which is thinking on the opponent's turn, and StochasticPonder, which is probabilistic pondering. It supports MultiPV, outputting several candidate moves at once. It handles many time controls including byoyomi and Fischer rules. It supports very parallel search on the scale of 256 threads.

For a developer, that list is a checklist of the hard parts of writing a shogi engine, and each line is a subsystem the project has already solved. That is the real appeal of the project for a programmer, and it is why it is described as educational.

The search core is a separate thing other engines can drive

The repository contains a second engine, FukauRaOu, and its description explains the relationship in terms that matter for reuse.

FukauRaOu is a dlshogi compatible engine. It supports the YaneuraOu thinking engine options, adopts the YaneuraOu standard opening book format, and supports reading the opening book on the fly rather than loading it into memory wholesale. And it provides DirectML and TensorRT versions, so it works without a GPU.

So the structure is a search core with a standard set of options, a standard opening book format, and a standard protocol, and then front ends that expose it in different ways. FukauRaOu's job is to be usable from dlshogi, a Python shogi library, and to run on hardware that does not have a CUDA device, which is what the DirectML and TensorRT builds are for.

This is the difference in approach between a self-contained engine and an engine core. A self-contained engine is a program you run and it does its own I/O, its own evaluation function loading and its own GPU dispatch. A reusable core is the search and evaluation machinery with the interfaces kept stable so that other programs can call it. The second shape is harder to build and it is what makes a research program possible, because you can swap the hardware backend, the protocol layer or the evaluation function without touching the search.

The licensing makes that reuse possible. The project is GPL-3.0, and the code is a public C++ solution, YaneuraOu.sln, with a source/ directory, a script/ directory, a docs/ directory, a docker/ directory and a .github/ directory for its contribution rules.

The build matrix is the honest description of the project's reach

The project documentation opens with a row of continuous integration badges, and they describe the supported targets better than any prose could.

There is a Make CI for MSYS2 on Windows, one for MinGW on Windows, one for Ubuntu Linux, one for macOS, one for WebAssembly, an NDK CI for Android, and two separate DeepLearning CI workflows, one for Windows and one for Ubuntu Linux. The two deep learning workflows are separate from the ordinary builds, which tells you that the neural network path has its own dependency stack and its own build treatment.

So the engine is built and tested on Windows through two toolchains, on Linux, on macOS, on WebAssembly and on Android, and the deep learning variants are built separately on Windows and Linux.

The published releases follow the same split. The v9.40 tag from 2026-06-03 is a set of Windows executables with the runtime bundled, the v9.10-fukauraou tag from 2025-11-24 is a set of Windows executables for the DirectML version, and the v9.01git tag from 2025-10-31 is a set of Windows executables for the TensorRT version. The naming convention in the tags is a lesson in itself: the same engine, the same version, packaged for a different hardware backend.

The consequence for a user is that there is not one download that suits everybody. A Windows user without a CUDA GPU takes the DirectML or TensorRT build, a Linux user builds from source or takes the ordinary build, a browser user is served the WebAssembly build, and an Android user has the NDK path. The wiki's install instructions and recommended engine settings pages are where the specific choice per platform is made, and the project documentation points at the FAQ and the build instructions pages for that.

Evaluation functions, opening books and a 33TB substitution table

Three subsystems deserve a mention, because they are where a shogi engine's real work sits.

The evaluation function is the neural network that judges positions, and the project supports several families: KPPT, KPP_KKPT, NNUE in various forms, and SFNN in various forms. These are separate downloads rather than being compiled in, and the sponsorship page explains that supporters receive a newsletter with the download URLs for the development versions of the engine for Windows x64, x86 and ARM, for macOS, for the evaluation function files and for the latest opening book files.

The opening book is the second. The project adopts its own standard opening book format, and it supports reading the database on the fly, which the documentation describes as not reading it all into memory. That matters for a strong engine, because a large book is a large file and loading it entirely is a memory cost you either accept or design around. The project also supports a range of maintenance commands for the opening book database, and there is a wiki page on how to create an opening book, which tells you the format is something users are expected to produce themselves rather than only consume.

The third is the substitution table, whose maximum size the documentation puts at 33TB, described as effectively unlimited. That is a table of board positions to their evaluations, used to recognise repeated positions, and the number tells you the scale of endgame tablebases the design contemplates.

The rest of the engine's feature list is about correctness and rules: tsume declarations of victory, try rules, byoyomi and Fischer time controls, and 256-thread search. And the last line of that list is a platform statement, support for Windows, Ubuntu, macOS, ARM and various other platforms.

The competition record, and what it does and does not prove

The project documentation carries a long tournament record, and reading it carefully tells you something specific about how this project is used.

The pattern is that YaneuraOu is frequently not the entry that won, but the search engine inside the entry that won. The 2019 WCSC29 entry was YaneuraOu with Otafuku Lab 2019, and the note under it says that all of the top eight teams in the final used the YaneuraOu thinking engine. In 2024 the WCSC34 winner used the search part of YaneuraOu V8.20 GitHub version. In 2025 the WCSC35 winner used the search part of YaneuraOu V8.60 modified. In 2023 the Denryu tournament final was won by the YaneuraOu entry, with the note that YaneuraOu participated as a team member.

The more recent entries show the same pattern with other engines. The 2026 World Computer Shogi Championship WCSC36 placed a different engine, Suisho, fourth, using the search part of YaneuraOu V9.30 modified. The 2026 Denryu tournament first division was won by a different engine using a combination of NNUE and deep learning with the YaneuraOu search part, and the second division was won using the search part of YaneuraOu V9.60.

That is a meaningful record, and it is a different claim from being the best engine. It says the search component is a reliable foundation that other, commercially and competitively successful programs build on. For a reader evaluating the project, that is the more relevant fact, because it means the core is tested against the strongest opposition in the world continuously, by people who had every incentive to replace it if it were the weak part.

The 2019 note is the sharpest version of the same point: the top eight teams in that final all adopted this search engine, which is the closest thing in the record to a controlled comparison.

Where YaneuraOu is the wrong tool

The first limit is that this is an engine and not a game. There is no interface for a person to sit down and play, and no way to configure a match without a USI-capable client. A hobbyist who wants to play against a strong shogi engine is picking up a GUI, an engine configuration and an evaluation function download, and that is a different task from installing a chess engine with a binary that contains everything.

The second limit is the dependency chain. Even the simplest use requires three separate artefacts: the engine binary for your platform, the evaluation function file, and an opening book if you want the book behaviour. The evaluation function in particular is a large neural network that is downloaded rather than built, and choosing between KPPT, KPP_KKPT, the NNUE variants and the SFNN variants is a decision with real performance and hardware implications, not a checkbox.

The third is that the build is not one recipe. The release artefacts are Windows binaries in several flavours, and the CI covers Linux, macOS, WebAssembly and Android, but the project documentation does not document a single build command for each of those, it points at wiki pages per platform. A contributor or a packager is expected to read the build instructions page rather than follow a documented one-liner.

The fourth is the licensing, which is a genuine constraint for some users. GPL-3.0 is the right choice for an engine that other programs embed, and it is what makes the reuse in other engines legitimate, but a commercial product that wants to ship the engine inside a closed product cannot do so without the corresponding obligations. A school or a commercial shogi application is a realistic case where that matters.

The fifth is the scale of the configuration surface. The wiki has pages for recommended engine settings, engine options, the USI extended commands, the parameter auto-tuning framework, the search part measurement data, evaluation function training, self-play between USI engines, running on AWS, and the removed commands and options from previous versions. That is a large operational surface for what is nominally one binary, and the maintenance cost of following it belongs to whoever deploys it.

Editorial conclusion

YaneuraOu is worth a look for a shogi programmer who wants a strong, well documented engine to learn from or to build on, because the project documents its installation, its engine options, its evaluation function training and its parameter tuning in a public wiki, and because the search core is separated enough that other programs, such as the dlshogi compatible FukauRaOu, can drive it with different hardware backends. It is the wrong choice for someone who wants a single installer for an ordinary desktop, and the wrong choice if you need a fully GPU-native build without a DirectML or TensorRT variant. Before you use it, check the three things the project tells you: that you need a USI-capable GUI, since the engine is a protocol server rather than an application; that the evaluation function is a separate download, with the KPPT, KPP_KKPT, NNUE and SFNN options each needing its own file; and that the opening book is a separate artefact in the project's own format, with the database able to be read on the fly rather than loaded into memory.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. yaneurao/YaneuraOu on GitHub