CECP - Chess Engine Communication Protocol

CECP

Definition

CECP stands for Chess Engine Communication Protocol. It is the text-based protocol used by the XBoard/WinBoard graphical user interfaces (GUIs) to communicate with chess engines. You will also see it called the “XBoard/WinBoard protocol.” CECP defines how a GUI and an engine exchange moves, time controls, options, analysis, and results.

What it is used for

CECP is the “language” that lets a chess engine play a game through a GUI or on an Internet Chess Server via a GUI relay. Typical uses include:

• Connecting a chess engine (e.g., GNU Chess, Crafty) to XBoard/WinBoard so it can play vs. humans or other engines.
• Running engine-vs-engine tournaments and automated testing in compatible GUIs (XBoard/WinBoard, Arena, Cute Chess, Scid vs. PC).
• Supporting analysis mode (infinite analysis), ponder (thinking on the opponent’s time), and a broad set of chess variants.
• Relaying games to and from Internet Chess Servers (FICS/ICC) through the GUI, which then speaks CECP to the engine.

History and significance

CECP emerged in the 1990s with Tim Mann’s XBoard for Unix and WinBoard for Windows. It became the de facto standard for open engines well before UCI (introduced around 2000) existed. H. G. Muller later extended and maintained the protocol and XBoard.

CECP’s historical importance is large: it enabled a common playing field for engines, popularized GUI–engine separation, and encouraged engine development in academia and hobbyist communities. It also natively supports many chess variants (e.g., crazyhouse, suicide, losers, and Fischer Random/Chess960), which made it the go-to for variant researchers and enthusiasts.

How a CECP session looks (handshake and flow)

Communication is line-oriented text. A minimal, typical sequence is:

• GUI → Engine: xboard
• GUI → Engine: protover 2
• Engine → GUI: feature ping=1 setboard=1 usermove=1 san=0 myname="MyEngine 1.0" variants="normal,fischerandom,crazyhouse" done=1
• GUI → Engine: new (start a fresh game)
• GUI → Engine: level 40 5 0 (40 moves in 5 minutes, 0 increment)
• GUI → Engine: post (enable thinking output) or nopost (disable)
• GUI → Engine: force (engine should not move until told)
• GUI → Engine: usermove e2e4 (human or opposing engine played 1. e4)
• GUI → Engine: go (engine should start playing the side to move)
• Engine → GUI: move c7c5 (engine replies with 1...c5)
• GUI ↔ Engine: time/otim updates, ping/pong checks, draw offers, etc.
• GUI → Engine: result 1-0 {White mates} (or draw / 0-1 with reason)

Common CECP commands (essentials)

• xboard: Initiates CECP mode.
• protover N: Requests feature negotiation (N=2 is standard). Engine replies with feature ... done=1.
• feature ...: Engine advertises capabilities (e.g., setboard=1, usermove=1, variants="...", ping=1, san=0/1, myname="..."). Must end with done=1.
• new: Start a new game from the standard initial position.
• variant NAME: Switch to a supported variant (e.g., fischerandom, crazyhouse, suicide, losers).
• setboard FEN: Set an arbitrary position via FEN.
• edit/force: Legacy methods; force tells the engine not to move (input moves only).
• go: Engine starts playing the side to move.
• usermove e2e4: GUI provides a move in coordinate notation; preferred when feature usermove=1.
• time T / otim T: Remaining time (in centiseconds) for side-to-move and opponent, respectively.
• level M T I: Time control (e.g., “40 5 0” for 40 moves in 5 minutes, no increment). Also st N (seconds per move), sd D (search depth).
• hard/easy: Enable/disable pondering (thinking on opponent’s time).
• ping N / pong N: Synchronization and sanity checks.
• analyze / exit: Enter/leave analysis mode (engine prints evaluations instead of making moves).
• draw / result / resign: Draw offers, game results, and resignations.
• post/nopost: Toggle search info output.

Move notation and examples

In CECP, moves are normally in coordinate notation (e2e4, g1f3). If san=1 is negotiated, SAN may be used, but most engines use coordinate moves to avoid ambiguity.

• From the initial position, after White plays 1. e4, the GUI sends: usermove e2e4. The engine might reply: move c7c5 (choosing the Sicilian Defense).
• Visualizing the board in that line: after 1. e4 c5, White has a pawn on e4, Black has a pawn on c5; central light squares are contested, queenside counterplay is signaled by Black.

You can contrast those with standard algebraic notation: 1. e4 c5. The CECP messages would be aligned as usermove e2e4 and move c7c5, respectively.

Example mini-line for clarity:

• GUI: new; level 40 5 0; go
• Engine: move e2e4 (if it’s playing White)
• GUI: usermove e7e5
• Engine: move g1f3 (2. Nf3)
• GUI: usermove b8c6 (2...Nc6)
• Engine: move f1b5 (3. Bb5, entering the Ruy Lopez)

Variants and features

One of CECP’s strengths is native variant support. Engines declare which variants they can play via features; GUIs then send variant commands and appropriate rules.

• Common features: setboard=1 (accept FEN), usermove=1 (use usermove prefix), san=0/1, ping=1, colors=0/1, myname="...", variants="...".
• Chess960/Fischer Random: variant fischerandom with FEN that encodes special castling rights; GUI ensures legal castling semantics.
• Crazyhouse/Bughouse: drop moves are represented in an engine- and GUI-agreed notation (often via variant conventions).

CECP vs. UCI (at a glance)

• Style: CECP centers on simple line commands with ad-hoc feature negotiation; UCI uses a more rigid, self-describing command set.
• Starting handshake: CECP uses xboard/protover/feature; UCI uses uci/uciok/isready/readyok.
• Moves: CECP typically usermove e2e4 and engine move e7e5; UCI uses position/startpos/fen with go wtime btime, and bestmove e7e5.
• Variants: CECP has long-standing variant support; UCI’s variant support is comparatively limited and GUI-dependent.
• Interoperability: Adapters like Polyglot bridge UCI engines into CECP GUIs (and vice versa), enabling broad compatibility.

Implementation tips (for engine authors)

• Parse input line by line; ignore unknown commands to remain future-proof.
• Always end feature negotiation with done=1; don’t emit prompts or extra text before that.
• Support setboard FEN and usermove to simplify GUI parsing and setup positions.
• Time management: respect time/otim, level/st/sd; compute remaining time in centiseconds.
• Respond promptly to ping with pong using the same token; flush output to avoid buffering delays.
• Implement analyze mode and post/nopost for usability; provide depth, score (in centipawns or mate distance), and PV lines.
• Handle result, resign, and draw gracefully; stop searching when told (force, new, quit).

Notable engines and GUIs supporting CECP

• Engines: GNU Chess, Crafty, Phalanx, Fairy-Max/Stockfish (via Polyglot adapter), Sjeng (classic), TSCP (teaching example).
• GUIs: XBoard (Unix/Linux), WinBoard (Windows). Also supported by Arena, Cute Chess, and Scid vs. PC.
• Adapters: Polyglot is widely used to run UCI engines under CECP GUIs.

Interesting facts and anecdotes

• CECP helped fuel the early online engine scene by interfacing cleanly with Internet Chess Servers through XBoard/WinBoard.
• Crafty—one of the most influential open engines—popularized and stress-tested CECP in countless tournaments and test suites.
• H. G. Muller’s work on XBoard extended CECP to many fairy-chess variants, making it a favorite among variant enthusiasts.
• While modern top engines often publish UCI-native builds, many still run flawlessly in XBoard/WinBoard via CECP adapters, preserving decades of tooling and workflows.

Related terms

• UCI (Universal Chess Interface)
• XBoard/WinBoard (the GUIs that defined CECP)
• Polyglot (UCI↔CECP adapter)
• ICS (Internet Chess Server), FICS/ICC
• PGN and FEN (game and position formats used alongside CECP)

Quick illustrative PGN (moves referenced above)

This PGN shows a line like those the engine and GUI exchange via CECP (in coordinate form under the hood):