Inside the Solver

How the Rubik's Cube Solver Works: Kociemba's Two-Phase Algorithm

By LK Forge  ·  5 min read  · 

The Rubik's Cube solver takes any scrambled cube and hands back a short solution — usually about 20 moves — in under a millisecond. It does not brute-force the 43 quintillion possible states, and it is not a learned model. It uses Kociemba's two-phase algorithm, one of the most elegant ideas in puzzle-solving: split an impossibly large search into two small, tractable ones. Here is how it works, and the exact numbers behind those near-optimal solutions.

Why You Can't Just Search

A Rubik's Cube has about 4.3 × 1019 reachable states. A blind search for the shortest solution is hopeless — you could not enumerate that tree in a lifetime. Yet every cube can be solved in at most 20 moves: that proven maximum is called God's Number. The challenge is finding a short solution quickly, without walking the whole space. Kociemba's method does exactly that by being clever about where it searches.

Two Phases, Not Brute Force

The two-phase algorithm splits solving into two much smaller searches, joined by a carefully chosen halfway point — a subgroup of cube states (called G1) reachable using only a restricted set of moves:

Each phase is a bounded depth-first search guided by large precomputed pruning tables — lookups that say "you are at least N moves from the goal," so the search abandons hopeless branches immediately. The solver then tries progressively deeper phase-1 solutions and re-optimises, so the combined solution comes out close to optimal rather than merely valid.

Why two small searches beat one big one. Searching for a guaranteed-shortest solution across all 43 quintillion states is astronomically expensive. Splitting at G1 turns one intractable search into two that pruning tables make almost instant — at the cost of solutions being near-optimal (about a move longer than the theoretical minimum) rather than provably shortest.

The Benchmark: ~20.5 Moves, Under a Millisecond

How long are the solver's solutions, and does a nastier scramble make the cube harder to solve? We ran the shipped engine over 200 random cubes at each scramble depth and measured the solution length in the half-turn metric (a 90° or 180° face turn each count as one move):

God's Number = 20 12.4 19.2 20.4 20.5 20.5 depth 10 depth 15 depth 20 depth 30 depth 40 lkforge.com
Mean solution length (half-turn metric) versus how many random turns were used to scramble the cube. 200 cubes per depth.
Scramble depthMean movesMedianMaxMean solve time
1012.410210.10 ms
1519.220210.29 ms
2020.421210.50 ms
3020.521210.47 ms
4020.521210.46 ms

200 random cubes per scramble depth, solution length in the half-turn metric. This build caps solutions at 21 moves — consistent with God's Number = 20. Full data is published as the LK Forge Rubik's Cube Solver Benchmark dataset on Hugging Face.

Why Scrambling More Doesn't Help

The striking result is the plateau. A lightly scrambled cube (10 random turns) solves in about 12 moves, but past roughly 20 turns the cube is already maximally scrambled — piling on more turns cannot make it any further from solved than God's Number allows. So the mean solution length settles at about 20.5 moves and stays there, whether you scramble with 25 turns or 40. Solve time stays flat too, at half a millisecond, because the two-phase search does the same bounded work regardless of how the cube got mixed up.

Reproduce It Yourself

The solver wraps the vendored min2phase library. You hand it a 54-character facelet string describing the six faces, and it returns the move sequence:

import min2phase from './vendor/min2phase.js';
min2phase.initFull();               // build pruning tables once (idempotent)

// 54 facelets: U, R, F, D, L, B faces, each 9 stickers (U/R/F/D/L/B)
const solved = 'UUUUUUUUURRRRRRRRRFFFFFFFFFDDDDDDDDDLLLLLLLLLBBBBBBBBB';
console.log(min2phase.solve(solved));   // '' — already solved

// a scrambled state returns a short move string, e.g. "R U R' U' F2 ..."

The solver runs exactly this on the colours you enter and animates the solution move by move.

Frequently Asked Questions

Is there a Rubik's Cube solver that shows the moves?

Yes — this page's Rubik's Cube solver is a free in-browser tool. Enter the colours of your scrambled cube and it returns a short sequence of moves that solves it. No sign-up.

What algorithm does the Rubik's Cube solver use?

Kociemba's two-phase algorithm, via the min2phase JavaScript library. Phase one drives the cube into a well-behaved subgroup; phase two finishes it there. It is a deterministic search over pruning tables, not a generative-AI or LLM wrapper.

How many moves will the solution be?

Typically around 20 moves — the measured mean is about 20.5 in the half-turn metric, and this build caps solutions at 21. That is consistent with God's Number = 20, the proven maximum any cube ever needs. The two-phase solver is near-optimal, not guaranteed shortest.

How fast is the Rubik's Cube solver?

Under a millisecond per solve once the pruning tables are built. The one-time table build happens on first use; after that every cube solves in well under a millisecond in plain JavaScript.

Is the Rubik's Cube solver free?

Completely free, no account required. It runs client-side in your browser, so nothing you enter is uploaded.

OPEN THE RUBIK'S CUBE SOLVER