KaTrain ships KataGo 1.18.1 inside app version 1.20.0, and its Python cap stops at 3.13 for wheels

App 1.20.0 bundles KataGo 1.18.1, on Metal if you are on Apple Silicon

The release names carry two numbers. v1.20.0 is titled KaTrain v1.20.0: KataGo v1.18.1 and minor improvements, v1.19.0 is titled only KaTrain v1.19.0, and v1.18.1 came earlier in the year. So the application version is not the engine version, and a release can bump one without the other.

Out of the box the package carries a working KataGo for Windows, Linux and Mac, built on OpenCL, with one exception: on Apple Silicon it uses the Metal backend. That single difference decides what works on a laptop without any setup. The model bundled with it is `b10c384h6nbt`, described as stronger per visit than the strongest 18 block models while being about as fast, which is the reason the default is a transformer rather than a large network.

Swapping either is a UI action. Models are managed in General and Engine Settings, opened with F8, where Download models gives a dropdown. The alternative backends live on the KataGo release site rather than here: CUDA and TensorRT for NVIDIA GPUs, ROCm for AMD, and ONNX for Intel GPUs or NPUs through OpenVINO, or any DirectX 12 GPU through DirectML. The trade is stated plainly. These may offer much better performance than OpenCL, but they are harder to set up, and the ONNX version additionally requires setting `onnxProvider` in `KataGo/analysis_config.cfg`.

The engine command line can be replaced wholesale

Beyond the model and the binary dropdowns, the entire command used to start the analysis engine can be overridden, and the documentation gives the reason: it can be useful for connecting to a remote server. That is the escape hatch for a machine without the GPU you want, or for a shared analysis box, and it is the reason the engine is treated as a separate process rather than a library call.

One detail matters more than it looks. KaTrain uses the analysis engine of KataGo and not the GTP engine, so a command override has to point at the analysis binary and speak its protocol. Copying a GTP command line from a KataGo setup guide will not work. INSTALL.md is where the longer form of this story lives, including the instructions for setting KataGo up to use multiple GPUs and the troubleshooting notes for Windows, Linux and macOS.

One dot carries two readings: mistake size and whether it was punished

The teaching feedback is the part of this application that is hardest to copy from a plain engine GUI. The dots on the move indicate how many points were lost by that move, and they encode two separate facts. The colour indicates the size of the mistake according to KataGo. The size of the dot indicates whether the mistake was actually punished, ranging from fully punished at maximal size to no actual effect on the score at minimal size.

That distinction is the point. A large red or purple dot is what a weaker player should mostly focus on, because the move cost real points on the board. A smaller dot marks a mistake that the engine considers an error and the game did not punish, which is where stronger players get their information. Both readings can be turned off: colours can be hidden on the board, and details can be omitted from SGF output, under Teaching and Analysis Settings.

The automatic response is part of the same design. In a teaching game KaTrain analyzes your moves and automatically undoes those that are sufficiently bad. When playing against AI, the Undo button undoes both the AI's last move and yours, which is a different operation and is documented as such.

The AI menu is calibrated, and one entry is always the full strength engine

In the AI settings, the options that have been tested and calibrated sit at the top in a lighter colour, and changing them shows an estimate of rank. The documentation is careful about the limits of that estimate: it should be reasonably accurate as long as you have not changed the other settings, which makes the rank number a reading of the current configuration rather than a property of the engine.

Two entries are named. KataGo is the full engine, above professional level, and the analysis and the feedback are always based on this full strength KataGo regardless of who you are playing. The Calibrated Rank Bot was calibrated on various bots, with GnuGo and Pachi at different strength settings named as examples, to play a balanced game from the opening to the endgame without making serious blunders at double digit kyu level. The feature list also points at playing against a wide range of weakened versions of the engine with various styles.

Three install routes with three update cadences

The installation section names three routes and the differences matter. The releases page carries downloadable executables for Windows and macOS. `pipx install katrain` installs the latest version from PyPI on any 64-bit operating system in an isolated environment, which is the only route that covers Linux in one line. On macOS there is also a `brew install katrain` cask, and the documentation warns in the same sentence that it can lag several versions behind the releases page.

That warning is the practical part: a cask user and a releases page user can be several versions apart without either being wrong. The packaging file lists classifiers for Microsoft Windows and POSIX Linux and a Development Status of Production/Stable, while the recorded homepage for the repository is empty even though the packaging file names the GitHub repository as Homepage.

Two dependencies are mutually exclusive by platform

The dependency list contains a platform split that is easy to miss. `pygame~=2.0` is marked `platform_system == 'Darwin'` and `screeninfo>=0.8.1,<0.9` is marked `platform_system != 'Darwin'`, so a macOS install gets one and everything else gets the other. Both are unversioned against each other, which means the two platforms are not being tested against the same audio and display stack.

The rest is unconditional: `chardet>=5.2.0,<6`, `docutils>=0.21.2`, `ffpyplayer>=4.5.1`, `urllib3>=2.2.2`, `kivy>=2.3.1`, `websocket-client>=1.9.0`, `certifi>=2026.2.25` and `pysgf>=1.0.0,<2`. The packaging file also carries a note explaining that ffpyplayer is a direct dependency for audio and that kivy does not pull it, which is there precisely because the transitive path does not exist.

The interpreter cap is about wheels, not about the language

`requires-python = ">=3.11,<3.14"` looks like a language decision and is not. The comment above it explains: the cap tracks binary wheel availability of kivy and ffpyplayer, because no cp314 wheels exist yet. Kivy 3.14 support is merged to master but unreleased, and ffpyplayer 3.14 is still in progress, with both upstream issue numbers written into the comment and an instruction to raise the cap once both ship cp314 wheels.

Two smaller traces of the same policy sit nearby. The development group still lists `tomli>=1.2.0 ; python_version < '3.11'`, a marker the lower bound of 3.11 makes unreachable, and the linter is pinned with `target-version = "py311"` and a comment saying it is fixed to the minimum supported version so the CI matrix of 3.11, 3.12 and 3.13 stays consistent. The lockfile at the root is a uv lockfile, and the default dependency group is the development one.

The license is recorded three ways and they do not agree

The recorded license for this repository is not asserted, while the packaging file states `license = "MIT"`, the badge row in the documentation links a page describing the MIT license, and a LICENSE file sits in the root. Those four signals do not line up, and picking one of them is a judgement call for whoever depends on this project rather than something the repository settles.

The rest of the tree explains the packaging story. There are two entry points, `katrain.py` at the root and `katrain.__main__:run_app` in the package, plus `spec/` and `test_katrain.spec` for the PyInstaller builds that produce the release executables. Translations and appearance have their own files, `i18n.py`, `THEMES.md` and `themes/`, a `.pre-commit-config.yaml` and a `.python_version` file sit at the root, and the contribution guide is named `CONTRIBUTIONS.md` rather than the conventional `CONTRIBUTING.md`.

Editorial conclusion

KaTrain fits a player who wants mistake feedback from a full strength engine on their own machine, and it fits a teacher who wants generated SGF reviews of a student's worst moves. Before installing, pick the route on purpose: the release executables, pipx from PyPI, and the Homebrew cask update on different schedules and the cask is the one documented to lag. If you need a GPU backend other than OpenCL or Metal, expect to read INSTALL.md and, for the ONNX build, edit the KataGo analysis configuration yourself. And settle the license question yourself, because the repository, the packaging file and the recorded metadata do not agree on it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. sanderland/katrain on GitHub