My underlying question here is: What is depth?

I know depth is supposedly the number of half-moves or plies from the starting position that it has calculated, in at least one line. But I feel this explanation is not congruent with the result you're seeing here:

  1. I'd expect mate in 7 to be found at depth 14, but I understand it didn't search every line so okay it found it when it had already searched somewhere to depth 21. So far so good.
  2. But, now it finds M13, or mate in 25/26 ply, at depth 21, where it should be at at least depth 25. How?
  3. Furthermore, the depth keeps increasing after finding mate in 13 (ply 26). Why would it keep searching in sequences that are longer than the mate it already found? All subsequent analyses should stay below 26 ply right?

enter image description here

  • 2
    Please could you add the FEN of the position in plain text?
    – Rosie F
    Commented Nov 7, 2021 at 11:27
  • 3
    The reason why the computer doesn't find the mate at depth 14 is because of pruning; it will not search all possible variatons 14 plies deep, but only look at the most "reasonable" ones according to its algorithm. As to why it finds the mate at depth 35 I guess it has to do with the computer increasing its depth by one step for each iteration of the algorithm, and it needs 35 such iterations before it actually finds the quickest mate. Since I'm no expert I'm waiting for someone who knows more about this to give a complete answer.
    – Scounged
    Commented Nov 7, 2021 at 22:42
  • 1
    The short answer is that depth is an implementation detail
    – Sopel
    Commented Nov 8, 2021 at 21:07
  • Incidentally my SF15.1+NNUE declares mate in 6 in a few seconds, depth circa 24. In this case I don't think it's lying, but it's human checkable. Line it gives is 1.Bxc2+ Kxc2 2.h7 h1=Q 3.b7 Rd1 4.Kc6 Qd6 5.Kb5 Rb1+ 6.Kc4 Qh4# Commented Feb 18 at 18:02
  • 1
    Hash size makes a lot of difference. Mine is set to 3GB. Commented Feb 18 at 18:07

3 Answers 3


StockFish at its core uses alpha-beta pruning, as explained in this post. Alpha-beta pruning by itself always gives a correct move according to perfect play, assuming the final position evaluation heuristics are correct. However, SF uses not only alpha-beta pruning, but also many other pruning heuristics that may not be correct unlike alpha-beta pruning, but will greatly increase the final depth that the search can reach. That final depth is what SF means by "depth 35". It does not mean that SF searched every line to depth 35, because it would prune off the vast majority of lines. So if those pruning heuristics are incorrect, then SF may prune off the branch with the depth-7 forced checkmate sequence at lower final search depth.

In particular, the default setting of SF is not to find the fastest checkmate sequences alone but to find the best move in general, because it is much more computationally expensive to prove a checkmate sequence. Whenever SF says #k after a fixed-depth search (such as on Lichess analysis), as far as I can tell it does imply that it searched all the branches necessary to prove that a checkmate can be guaranteed in ≤k moves. But since SF is (wisely) designed not to search for the fastest checkmate sequence (which makes it much faster), it sometimes fails to see the optimal line because it had already checked other lines that looked more promising according to the sometimes incorrect heuristics, and those lines already yielded a successful forced checkmate.

That said, I don't know why you say it needed depth 35. Lichess analysis clearly shows that it already found the #7 in the default depth-20 search.

[Edit: With the current Lichess interface it seems that the search is limited by "search time" with default being 4 s, meaning that it is not fixed-depth. I still believe that fixed-depth SF search should yield correct conclusion for forced checkmate.]

  • Aah, I hadn't considered the additional computation needed to prove something is a checkmate sequence. So the Bf1, Qb2+ sequence is very strong but it later proved that with Bb3, Nxh3+ mate was also inescapable and faster. My feeling remains that depth doesn't not mean what one would think it does.
    – Herman
    Commented Oct 31, 2022 at 19:00
  • Actually, when SF says #k, it may be just lying. It says it for depths it couldn't possibly have fully considered a complete half tree and sometimes changes its mind to #k+r or drops the mate announcement and gives a maximal score instead. (I'd count that as a bug.) Commented Jan 12 at 13:49
  • @MartinRattigan: Please show an example. I have never seen SF lie when it says #k, and I don't believe that it does. If it does, I would agree with you that it is a bug. Don't forget that SF has an endgame tablebase, so it can potentially find #k for rather large k!
    – user21820
    Commented Jan 12 at 14:01
  • @user21820 I haven't kept any examples, unfortunately, but I've seen it several times, as have others on the chess.com forum. I'll post an example when I next see one. My SFs don't have an EGT btw. I think they only take Syzygy, which wouldn't generally give you a distance to mate. Commented Jan 12 at 14:35
  • 1
    @MartinRattigan: That's not at all convincing. (1) As the last commenter said, you can only criticize the engine if it concludes something that is actually false. (2) The previous point applies only for the final conclusion, not any intermediate claims SF makes. The reason is that we cannot assume that its intermediate outputs actually mean anything at all. If it is halfway computing the search tree, it may conceivably show you the value of the partial tree even if it is possibly far from the value of the full tree. Why might it do that? Of course so that you don't complain that it lags!
    – user21820
    Commented Feb 14 at 16:11

Because it is not thinking to depth 35 for all moves. These newer engines have multiple levels of thinking. When it says level 35, that means the level of deep thinking. It may only be thinking of 1 or 2 lines to ply 35. Then it works backwards in the tree to look for better moves at an earlier ply. Probably at depth 35 it found a theme which it could used earlier in the tree but had rejected at an earlier depth. Ultimately, when it says depth 35, it is really at that depth anyway. It uses 2 numbers like 24/35. That means that it is thinking of moves at ply 24 but it extends the lines of thinking to ply 35 to calculate the evaluation better. Still, it can only accept so many moves up to ply 24 in order to solve in a reasonable time so it has to sometimes backtrack later when it learns of a new move. For example, there could be a deflection involved. Deflections are not moves the engines normally consider. However, smart engines will discover the deflection later as it serves a purpose to prevent some later move from happening. It then works backwards to find the deflection. This is effectively how humans find deflections, also.


SF doesn't find mates. When it announces +Mn it's generally lying. See the examples in Arena here and here.

See also comments following @user21820's post.

The thread title should really be, "Why does it take stockfish depth 35 to announce mate in 7?". But if it announces mate in 7 you cannot then assume there is a mate in 7 unless you either find such a mate yourself or check all alternative lines from different moves for the losing side in the example SF provides. SF hasn't necessarily checked them.

To be more precise SF returns info commands that may contain score ±Mn with "lowerbound" or "upperbound keys and most GUIs present these in a way that users will generally take as mate announcements. So it's the GUIs that are lying, not strictly speaking SF. SF is effective at hiding exactly what the contents of the info commands are in readily available documentation. Appealing to the UCI specification gets you no further - the price of a new set of false teeth for the programmer's granny in American cents appears to be UCI compliant as a score, with or without the "M". It's only necessary that if the price changes during an analysis another info command is returned.

Edit: Arena flags the lowerbound and upperbound lines with a "+" or "-" following the depths field. In the second link above there are +Mn scores shown in Arena with n increasing with time and no "+" or "-" following the depths field, so it would seem SF does lie as well as the GUIs.

  • You should ask a new question about why this behavior occurs. In your link you disabled NNUE, but most of Stockfish's evaluation relies on that nowadays.
    – qwr
    Commented Mar 3 at 17:22
  • But I've seen the same behaviour with NNUE enabled. It'm simply pointing out that the idea that SF finds mates is a misconception. Commented Mar 4 at 6:40
  • @qwr I believe the chess.com GUI doesn't disable NNUE and another user has also noted the same behaviour there. I'm not particularly interested in correcting this behaviour so I won't ask a new question. You may like to do so yourself, but Stack Exchange may not be the best place. I thought it best to post an answer pointing it out because it means OP's question is misconceived - but it's a widespread misconception. Commented Mar 4 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.