KataGo basics · 04
KataGo is more than a model: a five-layer map
Separate the engine, neural-network model, search, protocol, and interface before deciding what to download, connect, or debug.
The model supplies intuition, not transport
A model is a trained set of neural-network weights. It estimates move policy, outcome, and score for a position, but it does not parse SGF, listen on WebSockets, or draw a board. Model choice changes speed, strength, style, and memory demand.
The model is one layer of the system. Putting a .bin.gz file in a GUI does not by itself start an analysis service. The engine wraps the model in tree search
The KataGo executable loads a model and configuration, then repeatedly evaluates candidates through Monte Carlo tree search. Visits, threads, and GPU settings belong to this runtime layer; one model can produce answers of different stability at different search budgets.
The network evaluates positions; search turns those evaluations into candidates, principal variations, win rate, score lead, and ownership. Protocols move data; apps shape the experience
GTP, Analysis Engine JSON, REST, and WSS are different interaction boundaries. Apps such as Sabaki, KaTrain, and Read19 use one of them to send positions and turn results into boards, graphs, and variation trees. Choose the interface first, then confirm its protocol.
Responsibility flows from model to board. A protocol does not create playing strength, and a GUI is not the model.
Read next
Four questions to settle
- Which model architecture and size
- Which KataGo version and configuration
- Which protocol the client uses
- Whether the goal is play, review, or batch analysis