Lc0: A UCI Chess Engine That Runs on a Neural Network Backend
Open source neural network chess engine with GPU acceleration and broad hardware support.
At a glance
- What is it?
- Lc0 is a UCI-compliant chess engine that evaluates positions through a neural network rather than handcrafted evaluation. It supports CUDA, ROCm, ONNX, Metal and BLAS backends, but building it requires a backend library and a C++20 compiler.
- Who is it for?
- Adopt Lc0 if you already have a supported GPU stack and need a UCI engine whose strength scales with network quality rather than handcrafted evaluation. Skip it if you want a self-contained binary with no backend library, or if you cannot install a C++20 compiler and Meson.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Lc0 solves: chess evaluation without handcrafted features
Traditional chess engines encode evaluation as a set of handcrafted features: material, pawn structure, king safety, mobility. Those features are written by humans and tuned over years. Lc0 takes a different route. The README describes it as a UCI-compliant chess engine designed to play chess via neural network, specifically those of the LeelaChessZero project. The engine does not contain a handcrafted evaluation function in the classical sense. It loads a neural network file and asks that network to evaluate positions. The intended audience is not casual players looking for a desktop app. It is people who want to run a UCI engine inside an existing GUI or match manager, generate selfplay games, or experiment with network-based chess evaluation. The README explicitly recommends the latest release/version branch for essentially all purposes, including selfplay game generation and match play. That phrasing tells you the project is used as infrastructure, not as a standalone product.
How Lc0 works: UCI front end, backend library, network file
The architecture visible in the README has three parts. First, a UCI front end. Lc0 speaks the Universal Chess Interface, so any GUI or match manager that speaks UCI can drive it. Second, a backend library that evaluates the neural network. The README lists the supported backends: any CBLAS-compatible library for CPU usage, with OpenBLAS or Intel's DNNL as the main ones; CUDA with optional cuDNN for Nvidia GPUs; HIP/ROCm for AMD GPUs; various flavors of onnxruntime; Apple's Metal Performance Shaders; and experimental SYCL support for AMD and Intel GPUs. Third, a neural network file. The README says to download a neural network in the same directory as the binary, with no need to unpack it. So the data flow is: UCI command arrives, the engine searches, and each position evaluation is dispatched to the selected backend, which runs the network file. The build system picks the backend at compile time through Meson options. That is a compile-time coupling, not a runtime plugin system. If you build with CUDA, you get a CUDA binary. Switching to ROCm means rebuilding. The README also notes that the training server enforces game quality using the versions output by the client and engine, which means the engine version and the network are not fully independent: mismatched versions can affect whether generated games are accepted.
Getting Lc0 running: build.sh, build.cmd, and backend selection
On Linux the README gives a short sequence. Install a backend (CUDA, ROCm, SYCL, or OpenBLAS/DNNL), install ninja-build and meson, optionally libgtest-dev, go to the lc0 directory, run ./build.sh, and the binary lands in lc0/build/release/. Then download a neural network into the same directory as the binary. For Ubuntu 20.04 the README gives a concrete apt and pip sequence: apt-get update; apt-get -y install git python3-pip gcc-10 g++-10 zlib1g zlib1g-dev; pip3 install meson; pip3 install ninja; then CC=gcc-10 CXX=g++-10 INSTALL_PREFIX=~/.local ./build.sh. To use a different compiler you pass CC and CXX, for example CC=clang CXX=clang++. On Windows the flow is build.cmd, which generates an MSVS project and produces build/lc0.exe. If CUDA_PATH is not set, you edit build.cmd and set it. If you want cuDNN, you set CUDNN_PATH. On Mac you install meson and ninja via pip3, then run ./build.sh -Dgtest=false. There is also a CUDA-specific build option, -Dnvcc_ccbin=g++-11, which tells nvcc to use a different compiler than the system one. The README explains why: CUDA uses the system compiler and stops if it does not recognize the version, even if newer. For ONNX backends, the build options onnx_libdir and onnx_include point to the onnxruntime libraries and include directories. Starting with v0.32.0, the project also offers a pre-compiled version downloadable from the release page.
Build friction: C++20, Meson subprojects, and the network download
The README is candid that building should be easier now than it was in the past, and asks users to report problems. That wording implies build friction has been a recurring issue. The requirements are not trivial. Lc0 needs Meson, at least one backend library, and a compiler supporting C++20. The README lists minimal tested versions: g++ v10.0, clang v12.0, and Visual Studio 2019 version 16.11. If your system does not already have the backend libraries, Meson generates its own copy as a subproject, which requires git to be installed separately from cloning the lc0 repository. Meson also requires python and Ninja. So a machine that can clone the repo is not necessarily a machine that can build it. The network file is a separate download from the lczero.org bestnets page, and it must sit in the same directory as the binary. There is no bundled network. That means a fresh install is two artifacts from two sources, and the README does not describe an integrity check or version pinning between them. The training server version enforcement mentioned earlier is the closest thing to a compatibility signal, and it applies to selfplay game generation rather than local play.
Where Lc0 is the wrong tool
Lc0 is a poor fit when you want a single self-contained executable with no external backend library. Every supported path requires either a CBLAS library, CUDA, ROCm, onnxruntime, Metal, or SYCL. There is no pure-C++ fallback that runs without one of those. It is also a poor fit on hardware that lacks a supported backend. The README describes SYCL as experimental for AMD and Intel GPUs, so Intel GPU users are on a path the project itself labels experimental. CPU-only users can run through OpenBLAS or DNNL, but the README presents those as the CPU option rather than the recommended one, and the project's identity is GPU acceleration. Another limitation is the compile-time backend choice. If you want to compare CUDA against ONNX on the same machine, you build twice. There is no runtime backend switch described in the README. Finally, the network file is not optional and not bundled. An Lc0 binary without a network in the same directory cannot evaluate positions. That is a deployment detail that matters for anyone packaging Lc0 into a container or installer.
Alternatives: Stockfish and the handcrafted evaluation approach
The obvious alternative is Stockfish, which does not require a neural network file and is distributed as a self-contained binary. The difference in approach is fundamental. Stockfish evaluates positions through a handcrafted evaluation function plus search, and it does not need CUDA, ROCm, onnxruntime, or a separate network download to run. Lc0 evaluates positions through a neural network and therefore needs a backend library capable of running that network efficiently. The trade-off is that Lc0's strength is tied to the network file, which is updated separately from the engine, while Stockfish's strength is tied to the engine build itself. If your environment cannot install a GPU runtime or a BLAS library, Stockfish is the lower-friction choice. If your interest is specifically in neural network evaluation, selfplay generation, or the LeelaChessZero network ecosystem, Lc0 is the project that provides that. The README's own framing supports this: it recommends the release branch for selfplay game generation and match play, which are tasks where the network-based approach is the point rather than an implementation detail.
Licence and maintenance cost
Lc0 is licensed under GPL-3.0. That matters if you plan to redistribute the binary or link it into another product. The GPL-3.0 obligations apply to distribution, and the README does not discuss commercial licensing or exceptions. This is not legal advice; check the licence text and your own distribution model. On maintenance, the versioning follows Semantic Versioning with major, minor, and patch sections, and the README recommends tracking the release/version branch rather than master for essentially all purposes. That is a lower-churn path than tracking master, but it still means periodic rebuilds when a new release branch appears. The build depends on Meson, Ninja, Python, git, a C++20 compiler, and a backend library, so an upgrade can break if any of those move. The README's note about CUDA stopping on unrecognized compiler versions is a concrete example: a system compiler upgrade can break the build until you pass nvcc_ccbin. The network file is a separate upgrade axis. A new network may require a newer engine version, and the training server enforces version compatibility for selfplay. For local play the README does not specify a hard compatibility rule, so the safe practice is to upgrade engine and network together rather than independently.
Editorial conclusion
Adopt Lc0 if you already have a supported GPU stack and need a UCI engine whose strength scales with network quality rather than handcrafted evaluation. Skip it if you want a self-contained binary with no backend library, or if you cannot install a C++20 compiler and Meson. Before committing, verify that your chosen backend (CUDA, ROCm, ONNX, Metal or BLAS) is detected by the build, and confirm that the network file you download matches the engine version you built, since the training server enforces game quality using the versions output by the client and engine.
Community notes