Kociemba Tutorial — Near-Optimal Cube Solving
What this is
This page assumes you can already solve with CFOP (or any speed method) — you know faces / edges / corners / layers and can read notation like R U R′.
Kociemba is not a human method — it's a computer solving algorithm: give it any scramble and it finds a ~20-move solution in tens of milliseconds. A human solving the same cube usually takes 50+ moves.
This page covers two things: how the machine gets to that surprisingly low move count (two-phase reduction), and why 20 is the ceiling (God's number).
This is not a method you can "learn and execute by hand" — there's no algorithm set to memorize, no case recognition. It's a concept page for understanding how a computer solves a cube near-optimally.
The ceiling and the gap
God's number = 20. This is a mathematically proven hard limit: any scrambled 3×3 cube can be solved in 20 moves or fewer — no state needs 21.
What makes 20 startling is the contrast: you solve that same cube with CFOP in 50–60 moves. Human methods sit nearly twice as far from optimal.
Where does the gap come from? Humans recognize — we spot a finite set of cases (CFOP's 57 OLLs, 21 PLLs) and apply a memorized algorithm; the move count is capped by "how many cases you can hold in memory." The machine isn't bound by that: it searches a precomputed table covering tens of billions of states, looking up a path to a short solution directly. Recognition has a ceiling; search (almost) doesn't.
How the machine gets there
The machine's edge isn't "a cleverer move at each step" — it's problem reduction. It splits the solve into two phases: Phase 1 (reduction) throws the cube into a special restricted form — the subgroup G1; Phase 2 (solve) then finishes inside that much smaller space. Solutions are inherently shorter in G1, because fewer moves are available. Each phase runs its own search; together they average about 22 moves, rarely above 25. The demo below plays this out — watch the Phase 1 / Phase 2 divider on the move strip: that's exactly where the machine switches strategy.
Why two phases, rather than searching end to end? Because finding the globally shortest solution means searching the entire cube state space — a space far too vast to search directly. Splitting into two phases shrinks each search to a size a precomputed table can finish in milliseconds. Reduction buys computability — that's the algorithm's reason for existing.
Formal details (for the curious)
G1 move-set: inside the G1 subgroup, only {U, D, R2, L2, F2, B2} are needed — U/D may turn freely, but R/L/F/B are restricted to half-turns. This is the formal statement of "why solutions are shorter in G1": fewer options, more short solutions searchable.
What Phase 1 reduces: Phase 1 drives three coordinates to zero simultaneously — corner orientation twist(3⁷ = 2187) × edge orientation flip(2¹¹ = 2048) × E-slice edge position UD-slice(C(12,4) = 495). Their product ≈ 2.2 billion — Phase 1's coordinate search space.
|G1| (subgroup order): the reduced subgroup holds about 1.95 × 10¹⁰ (~19.5 billion) states — roughly nine orders of magnitude smaller than the full space (~4.3 × 10¹⁹). That's the quantified payoff of the reduction.
Why near-optimal: each phase uses a precomputed pruning table plus IDA* (iterative-deepening A*) search. The table stores "at least how many moves to the goal," letting the search aggressively prune bad branches — the key to solving a cube in tens of milliseconds. Two phases don't guarantee global optimality, but in practice they're extremely close.
God's number = 20, in context: this is the half-turn metric (a half-turn counts as 1). The lower bound = 20 was established early — positions like superflip need exactly 20; the upper bound = 20 was confirmed in 2010 by Rokicki et al. via computer enumeration (every state is ≤20 moves from solved). The bounds meet, so God's number is pinned at 20.
God's number's 15-year gap: the lower bound of 20 was pinned early by superflip (~1995), but the upper bound crept down slowly from Thistlethwaite (1981) until Rokicki et al. finally squeezed it to 20 in 2010 using massive computation. Proving "no state needs more than 20 moves" was far harder than expected — a story worth reading in full.
Where next
You've just seen the theoretical "ceiling" — but theory doesn't make you faster. Heading back to CFOP, drilling F2L and sharpening recognition is what actually lowers your move count.
To go deeper: the full history of God's number — that 15-year gap, superflip, the 2010 computation sprint — is the natural next read; beyond it, optimal solvers (guaranteed ≤20 moves) and the formal group theory of the cube. Each deserves its own dive.