egg-solver

Live demo: https://egg-solver.arhan.sh/

egg-solver is the fastest publically available optimal Rubik's Cube solver. This project was entirely generated by AI and was made possible under a few special conditions:

• I recently attended YCombinator's startup school and was gifted 6 months of Anthropic's Claude Ultra plan;
• as well $10,000 in Microsoft Azure credits
• I have had an interest in computational Rubik's Cube theory

I created a 48 core AMD EPYC 9V45 virtual machine with 94 GiB and two 300GB data disks. I gave Claude Code's Opus 5.5 (xhigh) model full access over the virtual machine and asked it to autonomously create the solver. Over the course of five days, I used $2,400 in Claude Code credits and $400 in Microsoft Azure credits to build this solver.

Acknowledgements

egg-solver would not have been made possible without the following contributions to Rubik's Cube theory:

• Richard Korf's first optimal Rubik's Cube solver
• Sebastiano Tronto's h48 optimal solver for which most of this solver is based on
• Tomas Rokicki's nxopt optimal solver
• Chen Shaung's cubeopt optimal solver
• Andrew Skalski's vcube optimal solver

It is easy to believe that the AI was primarily responsible for making the solver this performant. This is untrue: the significant majority of Rubik's Cube solving techniques were developed and perfected by these individuals over many decades of research and experimentation. egg-solver is different from the other optimal solvers only in detail (in particular, a heavily optimized micro-threading implementation), not in broad strokes: we still use a meet-in-the-middle approach with a large in-memory pattern database.

Notice

The rest of this document, as well as the mentioned user guide, was entirely written using AI.

Build and run

Requires Rust and Cargo. The release build targets the CPU it is built on.

cargo build --release --locked
mkdir -p tables
target/release/gen 0 auto tables/h0
# Optionally tune the lanes per thread for your machine
target/release/bench tables/h0 tune
printf '%s\n' "R U R' U' F2" | target/release/solve --table tables/h0

h0 is suitable for short examples. For arbitrary states, generate the largest
table that fits comfortably in RAM: h7 = 3.6 GiB, h8 = 7.3 GiB,
h10 = 29 GiB, h11 = 58 GiB. For example: gen 7 auto tables/h7.

# One cube, all selected threads:
target/release/solve --fast --table tables/h7 "R U R' U' F2"
# Batch: one scramble per line:
target/release/solve --table tables/h7 < scrambles.txt
# Check a table:
target/release/gen check tables/h7

-t N selects threads; -c 1 processes stdin one cube at a time;
--json emits JSON. --fast requires --table and one scramble from
arguments or stdin. Empty input is an error. --warmup SCRAMBLE is optional.

--load copy loads the table into private RAM before searching. With
--load map or shared memory, keep the backing storage unchanged while
running. See solve --help and the user guide.

Historical measured comparison

Recorded speedup over each competitor in the earlier matrix; higher is better. AMD EPYC 9V45,
1 GiB pages, matched solve modes. GB below are decimal table sizes.

These measurements used egg-solver 979dcf6. Later build differences,
samples, variation and limitations are in the full comparison.
The newer 500-state nissy throughput study and
62.474 GB nxopt study have separate configurations and timing definitions.

Browser and documentation

Documentation · Browser setup
· GitHub Pages deployment · Development scripts