# Info The `info` command can be sent by the engine anytime after UCI initialisation is complete (the [[uciok]] command has been sent). It used to update the GUI about a wide variety of statistics, diagnostics, and benchmarks about the engine. `info` has a *lot* of subcommands. Generally, a given `info` command can have many subcommands, but there are a few subcommands that can interfere with others. If the descriptions of any two subcommands do not obviously conflict with each other, then they can be bundled into a single `info` command by simply putting one after another (though in some cases it may be necessary to pay careful attention to the order). --- ## Subcommands ### Depth `depth <x>` The current search depth in [[Fullmoves, Halfmoves, & Plies|plies/halfmoves]]. Should be bundled with [[#pv Pv|pv]]. --- ### Seldepth `seldepth <x>` The [[selective search depth]] in [[Fullmoves, Halfmoves, & Plies|plies]]. Should be bundled with [[#pv Pv|pv]]. --- ### Time `time <x>` The time searched, in milliseconds. Should be bundled with [[#pv Pv|pv]]. --- ### Nodes `nodes <x>` The number of nodes searched. Should be bundled with [[#pv Pv|pv]]. > [!info] > The original specification says this should be sent "regularly". It does not define what regularly means. Existing implementations vary on their interpretation. I suggest just sending this whenever it's convenient. --- ### PV `pv <move1> ... <movei>` Short for "principle variation", which is a fancy way to say "preferred path" or "preferred line". `<move1> ... <movei>` is the sequence of moves the engine wants to follow. --- ### MultiPV `multipv <x>` For [[option#MultiPV|MultiPV mode]], indicates the rank of the [[#pv PV|PV]] currently being sent, with `1` being the best. In mulipv mode, the engine keeps track of more than one preferred path, usually ranked so that, for example, the second best move could sometimes be played instead of the best move. Multipv mode appears to be optional. --- ### Score `score cp <x>` `score mate <y>` `score upperbound cp <x>` `score upperbound mate <y>` `score lowerbound cp <x>` `score lowerbound mate <y>` Score is a subcommand that has it's own subcommands! Indicates the engine's evaluation of the position, either in [[centipawns]] or the number of [[Fullmoves, Halfmoves, & Plies|fullmoves]] until the engine predicts forced checkmate, optionally indicating that the score is either a lower or upper bound. Should be bundled with [[#pv Pv|pv]]. --- ### Currmove `currmove <move>` Currmove indicates the [[Fullmoves, Halfmoves, & Plies|halfmove]] the engine is currently evaluating. --- ### Currmovenumber `currmovenumber <x>` Currmovenumber indicates the number of [[Fullmoves, Halfmoves, & Plies|halfmoves]] that will have been made from the current position if the move the engine is currently evaluating is played. In other words, the number of [[Fullmoves, Halfmoves, & Plies|halfmoves]] deep the move indicated by [[#currmove Currmove|currmove]] is in the search tree. Should be bundled with [[#currmove Currmove|currmove]]. --- ### Hashfull `hashfull <x>` How full the engine's hash table is as a permill[^permill]. --- ### NPS `nps <x>` Short for "nodes per second". It is ambiguous how long of a time frame the average number of nodes per second should be calculated. Therefore, it is up to the implementation to decide. --- ### TBHits `tbhits <x>` Short for "Table-Base Hits". Indicates the number of evaluated positions which were found in the [[endgame tablebases]]. --- ### SBHits `sbhits <x>` Short for "Shredder Table-Base Hits". Identical to [[#TBHits]], except specifically separating out the Shredder Endgame Databases hits. Considering that the standard appears to have been [originally published *by* Shredder Chess](https://www.shredderchess.com/chess-features/uci-universal-chess-interface.html), I think it is safe to say that this is just some weird decision to try to promote Shredder Chess, and there's no real reason engines need to implement it, especially considering that the [Syzygy Endgame Tablebase](https://syzygy-tables.info/) for WDL with 6 or fewer pieces offers equivalent information in only 67.8 [[Units of Data|GiB]] (compared to 1153 [[Units of Data|GB]]). GUIs should implement it, however, at least enough to still parse the remainder of an info command containing it. --- ### CPULoad `cpuload <x>` The current CPU use of the engine in permill[^permill]. --- ### String `string <str>` After the `string` subcommand, the entire rest of the line is interpreted as a string to display to the user. --- ### Refutation `refutation <move1> <move2> ... <movei>` Should be used if the engine supports refutations and the special option `UCI_ShowRefutations` is set to `true`. Indicates that the line `<move2> ... <movei>` refutes `<move1>` (i.e., if the opponent plays `<move1>`, the engine would like to play the sequence of moves `<move2> ... <movei>` in response (for as long as the opponent continues to follow that line.)). The original standard does not actually say what the GUI should do with this information. Technically, that is the case for all of these subcommands, but this one is the least obvious to me. --- ### Currline `currline [<cpunumber>] <move1> ... <movei>` Indicates that the engine is currently calculating the line `<move1> ... <movei>`. If the engine is using multiple CPU cores to search multiple lines simultaneously, then the `<cpunumber>` parameter should indicate which CPU core is searching this line. If the engine is not using multiple CPU cores, `<cpunumber>` should either be `1`, or omitted entirely. The specification does not define what to do if the engine does not know which CPU cores are doing what. [^permill]: Permill is like percent, but out of 1000, rather than out of 100. So, 67.2% is equivalent to 672 permill. Note that UCI only uses integers, so 672.5 permill would need to be rounded to 672 or 673. [^GiB]: