# Pachi is a Go engine you can read, with a UCT core and optional neural nets > Pachi is a C program that plays Go, Baduk or Weiqi through the GTP protocol, built around a Monte Carlo tree search with RAVE and pattern playouts, and it adds a policy network as an optional guide. The source is a few thousand lines of readable C, and the build is a Makefile with switches for the deep learning support. **pasky/pachi** — A fairly strong Go/Baduk/Weiqi playing program - Repository: https://github.com/pasky/pachi - Website: http://pachi.or.cz/ - Stars: 558 · Forks: 116 - Language: C - License: GPL-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/pasky-pachi ## Two things in one name The README opens by splitting the project into two, which is the key to understanding what Pachi is. Pachi can refer to a simple modular framework for programs playing the game of Go, Weiqi or Baduk, and to a reasonably strong engine built within this framework. So there is a framework with a set of interchangeable components, and the engine that ships on top of it, and the engine is the part most people use. The strength figures are given concretely, which is more than most Go programs offer. The default engine plays by Japanese or Chinese rules and should be about 7d KGS strength on 9x9. On 19x19 it can hold a KGS 3d rank on modest hardware, such as a Raspberry Pi with dcnn, or a faster machine such as a six-way Intel i7 without dcnn. Using a large cluster of 64 machines with 20 cores each, it maintains KGS 5d and has won, for example, a 7-stone handicap game against Zhou Junxun 9p. Those numbers place the program. It is not the strongest thing available, and the README does not pretend otherwise. What it is is a program that runs on modest hardware, whose internals a programmer can follow, and whose structure invites you to replace the pieces. The engine core is described in one paragraph. By default Pachi uses the UCT engine that combines a Monte Carlo approach with tree search. The UCB1AMAF tree policy using the RAVE method is used for the tree search, while the Moggy playout policy using 3x3 patterns and various tactical checks is used for the semi-random Monte Carlo playouts. MM patterns and deep learning are used to guide the tree search. That is the interesting part for a reader: the playouts and the tree search are separate policies, so you can change one without rewriting the other, and the RAVE method means results from inside the tree feed back into the UCB1 selection. The project is C, GPL-2.0 licensed, and the releases are pachi-12.90 from 2026-04-15, pachi-12.88 from 2025-12-11 and pachi-12.86 from 2025-02-22, with the last push on 2026-08-05. ## Installing it, and what the build switches control There are three routes, and the third is where the real information is. On Linux and Windows you download a binary release and follow the instructions inside. On Mac and Linux you can install with homebrew, `brew install pachi`, and the README adds that full build is now supported, many thanks to the homebrew team. For build instructions see INSTALL.md. The Makefile at the repository root is where the design of the program shows through, because every capability is a compile-time switch with a comment explaining the trade-off: ```make # Generic build ? # If binary will be distributed you need this ! # Otherwise you may do without to enable more aggressive optimizations # for this machine only. # GENERIC=1 # Do you compile on Windows instead of Linux ? # Please note that performance may not be optimal. # To compile in msys2 with mingw-w64, uncomment the following line. # See Makefile.msys2 for further configuration. # MSYS2=1 # Do you compile on MacOS/X instead of Linux? # Please note that performance may not be optimal. # MAC=1 ``` That is an unusually honest build file. The generic build is required if you intend to distribute the binary and can be skipped for a machine-local build that enables more aggressive optimisations. The Windows and Mac builds carry the same warning about performance not being optimal. The deep learning section is the part that decides whether you get a plain Monte Carlo program or a neural network guided one: ```make # Compile Pachi with dcnn support ? # You'll need to install Boost and Caffe libraries. # If Caffe is in a custom directory you can set it here. DCNN=1 # CAFFE_PREFIX=/usr/local/caffe # Supported networks: # Comment out those you don't need for speed. DCNN_DETLEF=1 DCNN_DARKFOREST=1 ``` So `DCNN=1` turns on the network support and pulls in Boost and Caffe as dependencies, and then you can comment out the individual networks you do not want, which the comment says is for speed. That is the practical reason the program can ship with a network and still build on a machine without one: the switch is there. The same file has a `BOARD_SIZE=19` option, described as enabling more aggressive optimizations if you only play on 19x19, at the cost that Pachi will not be able to play on other board sizes. And the `JOSEKIFIX` build adds the module that fixes joseki lines the network plays poorly, gives more varied fusekis as black and lets the program play modern josekis with the `--modern-joseki` option, using KataGo as the joseki engine, whose CPU version is built by default. The Makefile header notes that options can be passed to make itself, `make MAC=1 DOUBLE_FLOATING=1`, or that you can use the short aliases such as `make fast` and `make generic`. ## GTP is the interface, and the parser is not safe The `pachi` binary is a GTP client. You use it with your favourite Go program interface, the README naming GoGui, Sabaki and Lizzie, or with kgsGtp to connect it to KGS. GTP, the Go Text Protocol, is the right design choice for this kind of program because it means every frontend can talk to every engine. It also means the engine does not need a graphical layer, which is why the same binary runs behind Sabaki on a desktop and behind a headless bot on a server. The README puts a warning immediately after the setup section, and it is the one line in the document you should not skip: > DO NOT make the GTP interface accessible directly to untrusted users since the parser is not secure - see HACKING for details. A GTP parser is a text parser handling a protocol that was designed for two processes talking to each other on one machine, and exposing it on a network means untrusted input reaches code that was never written to survive it. The project says so plainly and points at a HACKING document for the details, which is the responsible way to handle it. The practical rule is that the GTP port belongs on a local socket or a pipe, and any remote access goes through something you trust. That constraint shapes where Pachi fits. It is a program you run next to a board interface, not a service you expose. The README also notes that Pachi takes many parameters and that the defaults should be fine for initial use. The options are passed on the command line after the move, and the main options are described by running: ```bash pachi --help ``` Time settings are the ones most people need. Pachi can deal with a variety of time settings, with canadian byoyomi recommended to maximize efficient time allocation, although most of these are accessible only via GTP, meaning the frontend keeps track of time, for example KGS or GoGui. They can also be forced from the command line, where GTP time settings are then ignored. The forms are a fixed number of seconds per move, the `_` prefix for sudden death, and an equals sign for a playout budget, with a colon separating a minimum from a maximum. ## Strength, time and memory, as separate dials The options section is where the program becomes tunable, and there are three dials that control strength. The first is playouts. The `-t` option takes either a time per move, the `_` prefix for sudden death, or the `=` prefix for a fixed number of playouts per move, and a colon form that sets a minimum and a maximum, so the engine thinks more when it needs to. Fused with a separate fuseki time setting, you can cap how much thinking happens in the opening. The second is the network. The `-t` and `--dcnn=df` combination is documented as KGS 4d with the darkforest network, the plain time-based form as KGS 3d, and the `--nodcnn` variant as KGS 2k with MCTS only. That set of three gives you the exact strength cost of turning the network off, which is the single most useful number in the document for anyone deciding whether the Caffe dependency is worth it. The third is threads and memory. The documented combination `pachi -t 30 threads=4 max_tree_size=500 pondering` plays with 30 seconds per move on 4 threads, using at most 500Mb of memory for the tree search, and it also thinks during the opponent's turn. The heavier variant `pachi -t _1200 --nodcnn threads=8 max_tree_size=3072` plays without dcnn with 20:00 sudden death on 8 threads, taking up to 3Gb of memory. So `max_tree_size` is the memory dial and it is measured in megabytes, `threads` is the parallelism dial, and `pondering` is the responsiveness dial, since thinking during the opponent's turn makes your moves arrive faster but uses the same budget. There is also a plain speed setting: by default Pachi runs on all cores and takes a little under 10 seconds per move with no pondering. Two smaller options are worth knowing. `resign_threshold=0.25` resigns when the winrate drops below 25%, against a default of 20%. And `reportfreq=1s` shows search progress every second instead of the default of every 1000 playouts, which is the option to use when you want to see what the engine is doing. ## The neural network, and the joseki problem it creates The deep learning section is short and honest about what the network does and does not do. Pachi uses a neural network as a source of good moves to consider, which is the policy network role. With dcnn support Pachi can play at dan level on modest hardware. For a large number of playouts this makes it about 1 stone stronger and makes the games more pleasant to watch. A raw dcnn engine is also available for pure dcnn play, and the README says it is not recommended for actual games because Pachi will not know when to pass or resign. That last sentence is the clearest statement of the trade in the whole document. A pure policy network is good at picking moves and knows nothing about the endgame conventions of the game, so it is a demonstration rather than a player. The hybrid, where the network guides the search and the game logic handles passing and resigning, is the configuration worth using. The network commands are two flags: `pachi --list-dcnn` lists the supported networks, and `pachi --dcnn=name` chooses which one to use. Releases come with Detlef's 54% dcnn by default, and other networks are published separately in the Pachi Networks release. The README also notes that currently dcnn is used for the root node only, which explains the modest gain: the network is consulted at the top of the tree rather than throughout it. That root-node-only limitation is also what creates the joseki problem the project solves with a separate module. The josekifix module provides fixes for joseki lines that the network plays poorly, gives more varied fusekis as black and lets Pachi play modern josekis with the `--modern-joseki` option, and it uses KataGo as the joseki engine. It requires dcnn to be enabled as well. The `--modern-joseki` option itself carries a warning in the README: KataGo plays first moves in each corner, which is significantly stronger, but can make Pachi a pretty unbalanced player which plays godly josekis and does not have the strength to follow up on them, and it needs more testing. The authors are telling you the option is experimental in the strongest sense, since it improves the opening and can leave the rest of the game weaker. This is the part of Pachi that is a research program rather than a finished engine, and it is also the part that makes it interesting to read. ## Playing through a board interface, and what the source offers The analysis features are tied to a specific frontend. When running Pachi through GoGui, with version 1.4.12 recommended, a number of graphic tools are available through the Tools then Analyze commands window: best moves, score estimate, and DCNN ratings. It is also possible to visualize best moves and the best sequence while Pachi is thinking, using the live gfx commands. That is the practical analysis story. The engine can expose its current opinion of the position, its score estimate and its preferred continuation, and the frontend draws it. The Lizzie route is for exploring variations. The README describes it as a way to explore variations, analyse games or visualise what Pachi is doing while it is thinking, and the setup is: install Lizzie, get Pachi and extract it in the Lizzie folder, then configure the engine in the interface under Menu, Settings, Engine, adding Pachi as Engine 1 with the command line: ```bash Engine 1: pachi/pachi.exe -o pachi.log ``` Lizzie starts with Leela-zero and KataGo as the first two engines, and you switch with Menu, Engine, Engine 1, with the window title showing the current engine. The `-o pachi.log` argument is the interesting part, because it sends Pachi's log to a file. That logging is the other half of the analysis story. Pachi logs details of its activity on stderr, which can be viewed through the GTP Shell in GoGui, and the README says tons of details about winrates, memory usage and score estimate can be found there. So the debugging path for a surprising move is the log, not the source, and you can capture it to a file while playing. The repository layout reflects a program with a long history and a lot of small pieces. At the top level there are the core files such as `board.c`, `move.c`, `engine.c`, `network.c`, `chat.c` and `gtp.c`, with headers beside them, and then directories for the parts that vary: `dcnn/`, `distributed/`, `engines/`, `gtp/`, `joseki/`, `josekifix/`, `kgs/`, `media/`, and the `distributed/` directory in particular is where the multi-machine play described in the strength section lives. There are also `PERFS`, `TODO`, `CREDITS`, `HACKING`, `MORE.md` and `INSTALL.md` at the root, plus several Makefiles, one for Linux, one for Mac and one for msys2. ## Conclusion Adopt Pachi when you want a Go program whose source you can actually read, when you want an engine that speaks GTP to GoGui, Sabaki or Lizzie, and when you want the same code to run without a neural network at all. Do not adopt it if you need the strongest play available, since KataGo and the Leela Zero family are the reference points here, and do not expose its GTP interface to untrusted users, because the README says the parser is not secure. Verify first that your frontend is GTP compatible, that you have chosen the right time settings for the board size, that the `DCNN=1` build has Boost and Caffe installed if you want the network support, and that the version you take is pachi-12.90, released on 2026-04-15, with the last push on 2026-08-05. ## FAQ ### What is Pachi and how strong is it? Pachi is a Go, Baduk or Weiqi playing program written in C, available as a framework for such programs and as a reasonably strong engine built within it. The default engine plays by Japanese or Chinese rules, should be about 7d KGS strength on 9x9, and can hold a KGS 3d rank on 19x19 on modest hardware or with a larger cluster. ### How do I install Pachi? On Linux and Windows you download a binary release and follow the instructions inside. On Mac and Linux you can install with homebrew using `brew install pachi`, and the README says full build is now supported. For building from source, the instructions are in INSTALL.md and the root Makefile holds the configuration switches. ### How does Pachi use a neural network? The network is used as a policy, a source of good moves to consider, and it guides the tree search. With dcnn support Pachi can play at dan level on modest hardware, and for a large number of playouts it makes the program about 1 stone stronger. Releases include Detlef's 54% dcnn by default, and currently dcnn is used for the root node only. ### Is it safe to expose the Pachi GTP interface to the network? No. The README warns in capitals not to make the GTP interface accessible directly to untrusted users, since the parser is not secure, and points at the HACKING document for details. The GTP port belongs on a local socket or pipe between the engine and its frontend. ### How do I control Pachi's playing strength? Through the time and thread options. The README maps the combinations to ranks: `-t =5000:15000 --dcnn=df` is KGS 4d with the darkforest network, the same time settings without a network is KGS 3d, and `--nodcnn` with a smaller budget is KGS 2k with MCTS only. `max_tree_size` sets the memory cap in megabytes and `threads` the parallelism. ## Sources - [License: GPL-2.0](https://github.com/pasky/pachi/blob/master/LICENSE) - [pasky/pachi on GitHub](https://github.com/pasky/pachi) - [Project website](http://pachi.or.cz/) - [README](https://github.com/pasky/pachi/blob/master/README.md) - [Releases](https://github.com/pasky/pachi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pasky-pachi