omelettehedron 🥚

Live demo: https://omelettehedron.arhan.sh/

omelettehedron is a fast solver for the face-turning octahedron (FTO): a two-phase solver that finds short solutions within milliseconds and can prove them optimal. 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 three 300GB data disks. I gave Claude Code's Opus 5.5 model full access over the virtual machine and asked it to autonomously create the solver.

Acknowledgements

omelettehedron would not have been made possible without the following contributions to twisty-puzzle theory:

• Herbert Kociemba's two-phase algorithm, on which the two-phase solver is based
• Richard Korf's first optimal Rubik's Cube solver: IDA* with pattern databases

It is easy to believe that the AI was primarily responsible for making the solver this performant. This is untrue: the significant majority of the solving techniques were developed and perfected by these individuals over many decades of research and experimentation; omelettehedron applies them to the FTO.

Notice

The rest of this document, as well as the documents in docs/, was entirely written using AI.

Overview

A fast two-phase solver for the face-turning octahedron (FTO), written in Rust, and a separate optimal solver (single-phase IDA*).

• Phase 1 brings the puzzle into H_A, the positions that can be solved by turning only the four class-A faces U, F, BR and BL.
• Phase 2 finishes with those faces only. Its 933,120 positions are fully tabulated, so it is an O(length) lookup, and its solutions are optimal even among all face-turn solutions.

Phase 1 is an IDA* search guided by pruning tables. See docs/PHASES.md for why this split was chosen and how it compares with alternatives (and docs/CHEN.md for Chen Shuang's block split, which we measured and set aside), docs/RESULTS.md for measured speed and solution lengths, and docs/OPTIMIZATION_LOG.md for how it got there.

On 48 threads a random position gets its first solution in about 6 ms (23 moves on average), 21.5 moves after 1 s and 21.2 after 5 s; a proof of optimality takes from a few seconds to about a minute (optimal lengths are around 20-21).

Build

cargo build --release

On x86-64 the build targets x86-64-v3 (AVX2/BMI2, any x86-64 CPU from about 2015 on); see .cargo/config.toml. Other targets build too: aarch64 (e.g. Apple Silicon) uses NEON for the byte shuffles, wasm32 uses simd128 when enabled (-C target-feature=+simd128), and anything else falls back to scalar code.

Notation

Hold the puzzle with a corner pointing at you:

Side	Faces
Front	U (top), R (right), F (bottom), L (left)
Back	B (top), BR, D (bottom), BL

X turns face X 120° clockwise as seen from outside, and X' turns it anticlockwise. X2 is accepted as two turns. Opposite pairs: U–D, F–B, R–BL, L–BR.

Xw turns face X together with the middle layer (a wide turn). Xs turns only the middle layer between X and its opposite face, in the sense of X, so Us = Ds' (a slice turn). Scrambles may always contain wide and slice turns; solutions name slices by their front face (Us, Rs, Fs, Ls). Xv in a scramble turns the whole puzzle like X (all three layers of X's axis).

solve ... -v also says whether the solution solves the pure FTO, where every centre triangle is unique: the solver itself treats centres of a colour as interchangeable, so its optimum is a lower bound for the pure puzzle. bench/hard.tsv lists hard positions (scripts/bench-hard.sh).

Face turns can rotate the whole puzzle, so a solution ends in the solved state in some orientation. Internally the front corner is held fixed.

Move sets

Solutions use face turns, plus the families given with --moves (comma-separated). Every allowed move counts as one.

--moves	Solutions use	Effect
(none)	face turns	the face-turn metric
slice	face and slice turns	shorter solutions; own pruning tables (*-slice.prun)
wide	face and wide turns	same lengths and search; see below
wide,slice	all three	as slice, printed as with wide

A wide turn is a turn of the opposite face plus a whole-puzzle rotation, and the solver treats every orientation as solved, so wide turns never shorten a solution. With wide the search is unchanged and only the output differs: the corner piece between U, R, F and L stays where the scramble left it, and turns of the faces around it are printed as wide turns of the opposite faces (Dw for U if the scramble left that piece in front).

With slice the phase-1 search has 24 internal moves instead of 16, and slices are not phase-2 moves; see docs/PHASES.md for the move-order rules, the tables and why optimal mode stays exact.

This is the beginning of the README. Read the rest at the original. Read the full README ↗