fail-high in chess engine search

fail-high

Definition

In chess computer search, a fail-high occurs when an alpha–beta search returns a score greater than or equal to the current beta bound (the upper limit of the search window). This means the node “fails” on the high side of the window, indicating that the position is at least as good as the beta threshold—a lower bound on the true evaluation. In practical terms, a fail-high triggers a beta cutoff: the engine stops exploring sibling moves at that node because it has already found a move good enough to refute the opponent’s options.

How it is used in chess

Fail-high is a core concept of alpha–beta pruning used by modern engines like Stockfish and Komodo. You’ll see its effects when analyzing games in a GUI or console:

• Beta cutoff: The engine prunes the rest of the moves in that branch after a fail-high, saving time and searching deeper elsewhere.
• Aspiration windows: Engines often search with a narrow window around the previous iteration’s score (e.g., [alpha, beta] = [+0.10, +0.30]). If the new score blows past beta (e.g., +1.80), the engine “fails high” and immediately re-searches with a wider window to get an exact score.
• UCI output flags: In UCI, a fail-high is commonly reported as a bound, for example: info score cp 180 lowerbound (lowerbound means “at least this good”). A fail-low analog appears as upperbound.
• PV volatility: After a fail-high, the principal variation (PV) can change dramatically on the re-search—quiet lines may be replaced by a forcing tactic or even a mating sequence.

Why fail-high matters

Efficient pruning is essential to reach high search depths. Inducing many safe fail-highs (via strong move ordering, killer-move heuristics, history heuristics, and good transposition tables) dramatically reduces the number of nodes searched. This efficiency translates into stronger practical play, better tactic detection, and faster convergence to the Best move.

For practical analysts, recognizing a fail-high in the output explains sudden jumps in Eval or CP values. It also warns that the currently displayed score is only a lower bound until the engine completes a re-search with an expanded window.

Concrete example: aspiration window and re-search

Suppose an engine’s previous iteration reported +0.20. The next iteration uses an aspiration window [alpha, beta] = [+0.10, +0.30]. During the search, it finds a tactical shot worth roughly +1.80. Because +1.80 ≥ beta, the node fails high. The engine then immediately re-searches with a wider window (e.g., [−1.50, +2.50]) to resolve the exact score and PV.

In a simple miniature, a blunder can provoke an instant fail-high because the evaluation jumps to a forced mate:

After 1. e4 e5 2. Qh5 Nc6 3. Bc4, if Black blunders with 3... Nf6??, then 4. Qxf7# is mate. An engine using a narrow aspiration window near 0.00 will “fail high” when it detects the mating line and will re-search to confirm the exact mate score.

Try the sequence:

Interpreting engine output during analysis

• Lowerbound ≈ at least this good: When you see lowerbound in UCI output, treat the value as a minimum; the true score may be higher after re-search.
• PV stability: Don’t overreact to a PV shown at the moment of a fail-high; wait for the re-search to stabilize the line.
• MultiPV caution: With MultiPV enabled, a fail-high on one line can temporarily distort rankings until each line is re-searched with an appropriate window.
• Mate scores: Fail-highs are common when a forced mating net appears; the numeric score jumps beyond the window, then resolves to a “mate in n.”

Historical and technical notes

• Alpha–beta pruning dates back to early computer chess research in the mid-20th century; fail-high and fail-low terminology became standard with iterative deepening and bounded-window searches.
• Engines like Crafty, Fritz, Rybka, and Stockfish all leverage fail-high behavior with sophisticated move ordering to maximize pruning. Engine heuristics such as killer moves, history tables, counter-move heuristics, and null-move pruning increase the likelihood of safe beta cutoffs (fail-highs).
• Contrast with MCTS: Systems like AlphaZero and Leela use Monte Carlo Tree Search rather than alpha–beta; the fail-high/low terminology is specific to alpha–beta frameworks, though analogous ideas (bounds, pruning, and policy/value guidance) still apply.
• During the famous Kasparov vs. Deep Blue, 1997 match, alpha–beta search with aggressive pruning produced many beta cutoffs—classic environments where fail-highs drive deep tactical insights.

Practical tips for players and analysts

• Notice sudden eval spikes: A sharp rise often means a fail-high was triggered by a tactical resource—look for forcing moves, checks, captures, and threats (Tactic, Blunder, Swindle potential).
• Let the engine settle: After a fail-high, wait for the re-search to complete before trusting the numeric score or PV, especially in razor-sharp positions.
• Use MultiPV sparingly: Too many lines can make re-searches noisy. Start with a small MultiPV and expand as needed.
• Cross-check with human judgment: If an engine “finds everything,” ensure it’s not a narrow-window artifact. Consider broadening the window or increasing depth for confirmation—a good habit when distinguishing a brilliant Computer move from a speculative idea.

Related terms

• Fail-low: The opposite event—returning a score ≤ alpha (an upper bound) that triggers a re-search on the low side.
• Beta cutoff: The pruning event caused by a fail-high.
• Engine eval and CP: How engines numerically measure positions.
• Best move, Book move, and TN: Move selection and theory interactions with engine search behavior.
• Tablebase: Endgame oracles that avoid fail-high/low ambiguity by providing exact results.
• Sac: Tactical sacrifices often provoke fail-highs by blasting through the search window with forcing play.

Interesting facts

• Many engine “epiphanies” you see on the eval bar—instant surges from equality to a winning edge—are fail-highs caused by a newly discovered forcing line.
• Good move ordering that places strong forcing moves first increases fail-high frequency, reducing node counts dramatically at the same depth.
• Some GUIs expose UCI’s bound flags; if you see “lowerbound,” you’re literally witnessing the aftermath of a fail-high in real time.