Any Cube Falls in 20 Moves. Why Do Experts Use About 57?

Every scrambled 3x3 cube can be solved in 20 moves or fewer. The current world average is 3.51 seconds [2]. Put the two facts together and a tempting story appears: people are slow because they are far from 20. I think that story is mostly wrong. The 20-move result tells you how short a solution can be. It says nothing about how a person finds one. The gap between 20 and the roughly 57 moves of a typical CFOP solve is the price of looking ahead and recalling algorithms. Hands are a smaller part of that price than people say.

The question

How many seconds does the move gap cost, and which lever moves solve time most: fewer moves, or faster turns?

Data and where it came from

I did not run code for this post. Every sum below uses a published figure and a formula you can redo with a calculator.

• God's number. Rokicki, Kociemba, Davidson and Dethridge proved in July 2010 that every position needs 20 moves or fewer. The work split the cube space into 2,217,093,120 sets, cut that to 55,882,296 using symmetry and set covering, and used about 35 CPU-years of idle Google computer time [1].
• Distance 20 is rare. The same page says distance-20 positions are rarer than one in a billion, yet probably number more than one hundred million. The page shows about 490,000,000 in its table. The team found roughly twelve million of them [1].
• Human move counts. The Speedsolving wiki gives CFOP an average of 57.5 moves, Roux 48, and ZZ about 45 (with EOLine) to 53 (with EOCross) [3][4][5]. Feliks Zemdegs reconstructed his own average as 58 in slice turn metric and 62 in execution turn metric [6].
• Turn speed. Feliks estimates the upper limit for CFOP at 11 to 12 turns per second (TPS) on average, assuming near-perfect lookahead [6].
• Records. As listed on 2026-10-02, the 3x3 single is 2.76 seconds (Teodor Zajder) and the average is 3.51 seconds (Yiheng Wang) [2].

Two caveats. First, move metrics differ. The wiki numbers, the forum numbers and Feliks's 58 and 62 do not all use the same metric. Second, the wiki averages describe typical solves, not record solves. Treat all human counts as plus or minus 5 moves.

Method

I check each claim by counting. For a move count $m$ and a turn rate $r$ in TPS, execution time is

$t = m / r$

All times below are execution time only. They leave out pauses, which is where lookahead lives.

The proof sketch, in five lines

1. The cube has about 4.3 x 10^19 states (standard figure, not from the sources above).
2. Take the subgroup H generated by U, D, R2, L2, F2, B2. It has 19,508,428,800 elements (8! x 8! x 4! / 2, standard).
3. Divide: 4.3252 x 10^19 / 1.9508 x 10^10 is about 2.217 x 10^9 cosets, matching the 2,217,093,120 on the project page [1].
4. Symmetry cuts this to 55,882,296 sets. For each set, a computer shows every position in it has a solution of 20 moves or fewer [1].
5. Every position lies in some set, so every position needs 20 moves or fewer. The check cost about 35 CPU-years [1].

Step 4 is the heavy part. It is proven, but by exhaustive computation, not by a clever argument. I love the five lines. I do not pretend the fifth line is cheap.

Result

The move gap in seconds

Method	Average moves	Algorithms to learn	Source
Optimal (worst case)	20	not applicable	[1]
ZZ (EOLine)	about 45	20 to 514	[5]
Roux	48	9 to 42	[4]
ZZ (EOCross)	53	20 to 514	[5]
CFOP	57.5	78 for full last layer	[3]

Now convert to time at Feliks's ceiling of 11.5 TPS (the middle of his range) [6]:

• 20 moves: 20 / 11.5 = 1.74 seconds.
• 48 moves (Roux): 48 / 11.5 = 4.17 seconds.
• 57.5 moves (CFOP): 57.5 / 11.5 = 5.00 seconds.

So the 37.5-move gap costs 3.26 seconds of pure turning at the ceiling. That is a real cost. Yet no human can pay it back by learning the optimal solver, because the optimal solver is a search. Finding a 20-move solution means exploring a space the size of the cosets above. A hand cannot do that in 15 seconds of inspection.

The human shortcut is a method. A method breaks the cube into steps with small tables of cases. CFOP needs 78 last-layer algorithms [3]. That is a recall cost, paid once, in exchange for never searching. Roux trades a bigger single set (42 CMLL cases) for fewer moves and a more intuitive finish [4]. ZZ goes from 20 to 514 algorithms depending on how much recall you accept [5]. Fewer moves, more cases. This is the price list.

Does the record fit the model?

Here the numbers disagree, and I will say so. If a 3.51 second average used 57.5 moves, the turn rate would be 57.5 / 3.51 = 16.4 TPS. That is above Feliks's ceiling of 11 to 12 [6]. At 11.5 TPS, 3.51 seconds allows only 3.51 x 11.5 = 40 moves. The same step on the 2.76 second single gives 2.76 x 11.5 = 32 moves.

Three explanations fit. The record solves used far fewer moves than the typical wiki average. Or the ceiling of 11 to 12 TPS was a 2020s estimate that records have since passed. Or the metrics differ and I am comparing unlike counts. I do not have reconstructions of the record solves, so I cannot decide among them. I put the 40-move reading as likely, not proven. Feliks himself said the average could fall to the low 50s with better solutions [6]. A record average near 40 would be a bigger step than he forecast.

The forum data agrees on direction. Mike Hughey reported 59.6 moves at a 20 second average, and one solver reported about 52.55 at sub-12 seconds [7]. Moves fall as people get faster, but slowly: 7 moves across an 8-second span. Hughey also notes that fast solvers often pick speed-optimal algorithms over move-optimal ones, which raises the count slightly [7]. So move count is not even a clean proxy for skill.

Sensitivity: which assumption moves the result most

Compare two improvements from a CFOP solver at 55 moves and 10 TPS (an illustrative baseline, not a measured person). Time is 55 / 10 = 5.50 seconds.

• Cut 10 moves, keep 10 TPS: 45 / 10 = 4.50 seconds. Gain 1.00.
• Raise TPS to 11.5, keep 55 moves: 55 / 11.5 = 4.78 seconds. Gain 0.72.

Starting from 11.5 TPS, cutting 10 moves gains 10 / 11.5 = 0.87 seconds. In this model, the 10 moves win, and not by much. The result is most sensitive to the TPS ceiling. If the true ceiling is 16 and not 11.5, speed gains from turning are larger and the ranking flips. The ceiling is the weakest number I use, and it is one person's estimate [6].

The model also hides what I care about most. Moves and TPS are not independent. A solver who stops to find the next pair has a low TPS for that moment, because the hands wait for the eyes. Feliks says the room to improve is in lookahead, especially early F2L pairs and last-layer recognition, and that we are "a long way off 11 TPS" [6]. That sentence is the point. The ceiling is for a solver who never pauses. Real averages sit below it because of pauses. So the first lever is the pause, which is lookahead. My view that lookahead beats raw finger speed for most solvers stays at about 0.55 confidence. This post adds a mechanism but no new test.

I should name my blind spot. I judge methods by moves, and I may undervalue how easy a method is to learn. CFOP has the highest move count in my table, yet the wiki calls it widely considered the easiest to learn, with the most resources, and statistically the fastest method in practice [3]. A move count does not make a method fast. A method that people can learn, drill and look ahead in does.

What I will not claim

I will not claim the gap is caused by "talent" or by hand speed alone. Nothing here measures either. I also will not claim 20 is reachable by humans. Distance-20 positions are about one in a billion, so a random scramble is almost never one [1], but a human solving at 57 moves is nowhere near 20 on any scramble.

The number that would settle the question is the move count and TPS of the 3.51 second average, five solves, in one fixed metric. If those solves average about 40 moves at about 11.5 TPS, the human frontier is moves. If they average 55 at 16 TPS, my reading of the TPS ceiling is wrong.