A collection of specialized Rubik's Cube solvers covering 3x3x3 stages (Cross, XCross, Free Pair, Pseudo F2L, EOCross, and Last Layer) and 2x2x2. Each solver includes an interactive Visual Cube State Editor.
The following practice trainers are also available:
This site supports Progressive Web Apps (PWA). You can install it directly from your browser to run solvers and trainers offline.
These solvers are designed for speedcubers using methods such as CFOP and ZZ. They search for optimal or efficient solutions for Cross, XCross, and EOCross variations, as well as selected Last Layer algorithmic substeps.
Memory requirements for each solver are summarized below. The browser tab may crash if device memory is insufficient.
| Solver | Single Search | Analyzer |
|---|---|---|
| F2L Lite | 50 MB | 50 MB |
| Pairing | 50 MB | 100 MB |
| Pseudo F2L Lite | 50 MB | 50 MB |
| Pseudo Pairing | 50 MB | 200 MB |
| EOCross | 100 MB | 100 MB |
| F2LEO | 50 MB | 50 MB |
| Pseudo F2LEO | 50 MB | 50 MB |
| LL Substeps Lite | 50 MB | - |
| LL Lite | 50 MB | - |
| LL AUF Lite | 50 MB | - |
| F2L | 800 MB | 50 MB |
| LL Substeps | 800 MB | - |
| LL | 800 MB | - |
| LL AUF | 800 MB | - |
| 2x2x2 | 50 MB | - |
// setup comment on the scramble line. When opening generated links on alg.cubing.net or cubedb.net, content up to the line with // setup will be placed in the Setup/Scramble field, while subsequent lines will be placed in the Moves field.
EMPTY_EMPTY is selected, requiring centers to return exactly to the state determined by the user's Scramble and initial Rotation.Evaluates the transition and final state of F2L pairs and cross-edge connections along the solution steps for each of the 4 F2L slots (BL, BR, FR, FL). When enabled, analysis badges are displayed alongside each solution.
E).Indicates when a Block or Free state is formed and sustained continuously until the final move of the solution:
🔒 / ⚡: Formed and maintained from inspection / move 0 throughout the entire solution.🔒M{k} / ⚡M{k}: Formed at move k and preserved without interruption through the final move.🔒End / ⚡End: Formed specifically on the final move of the solution.Exclusion of the dropdown rotation prefix: In the main solver (index.html), if an orientation is selected in the Rotation dropdown, it is prepended to the beginning of the displayed solution string (which may consist of one or two turns, such as z2 or z2 y). This dropdown rotation prefix is excluded from the move count.
Move 1 (M1) begins immediately after this prefix. Any cube rotations (x, y, z) that appear within the generated solution sequence itself are counted as standard moves.
Configures facelet stickering modes for solution previews in Twisty Player. The available display modes are:
You can preview the stickering mask directly in Twisty Player. When Auto Stickering Setting is enabled, stickering masks are applied automatically to match the chosen solver configuration.
A solver suite for Cross, XCross, XXCross, XXXCross, and full F2L. It searches for optimal solutions for Cross, first pairs, multi-slotting, and complete F2L states. The F2L full solver covers the same problem domain at higher search speeds.
A specialized solver for forming arbitrary free pairs. It finds solutions for Cross with a preserved free pair, advanced F2L setups, and multi-slot pair preservation.
A solver suite for Pseudo Cross, Pseudo XCross, Pseudo XXCross, and Pseudo XXXCross. It is designed to explore non-standard blockbuilding and pseudo-slotting opportunities.
A solver suite for forming pseudo free pairs alongside Cross or multi-slot states, enabling unconventional F2L transitions and advanced blockbuilding.
A solver suite for EOCross, XEOCross, XXEOCross, XXXEOCross, and complete F2L with full edge orientation (ZZ method foundations).
A solver suite for Cross, XCross, XXCross, and XXXCross that simultaneously preserves the orientation of designated F2L slot edges (F2L edge orientation control).
A solver suite combining pseudo-slotting with edge orientation control across Pseudo Cross, Pseudo XCross, Pseudo XXCross, and Pseudo XXXCross.
A solver targeting Last Layer substeps defined by CP, CO, EP, and EO subsets. It searches for algorithms and setups for sets such as OLL, COLL, and ZBLS. The LL Substeps full solver performs the same search.
A solver for full Last Layer states (pre- and post-AUF are preserved or handled automatically). It is useful for generating and verifying algorithms for PLL, 2GLL, ZBLL, and 1LLL. The LL full solver performs the same search.
A specialized Last Layer solver that explicitly searches solutions including pre- and post-AUF alignment. Using LL Lite or the full LL solver is generally recommended for faster execution.
An optimal solver for the 2x2x2 pocket cube. It generates short, efficient algorithmic solutions for methods such as CLL and EG (EG-1, EG-2).
Random pattern generators powered by min2phase.js. A total of 14 specialized trainers are available. Scrambles can be generated with custom constraints (Rotation, Slots, Length), and solutions can be verified immediately.
Each trainer integrates with its corresponding solver. Click [Next] to generate a new scramble, and [Solve] to view step-by-step solutions.
| HTM | Number of Patterns | Percentage |
|---|---|---|
| 0 | 1 | 0.00 |
| 1 | 15 | 0.01 |
| 2 | 158 | 0.08 |
| 3 | 1394 | 0.73 |
| 4 | 9809 | 5.16 |
| 5 | 46381 | 24.40 |
| 6 | 97254 | 51.16 |
| 7 | 34966 | 18.40 |
| 8 | 102 | 0.05 |
| HTM | Number of Patterns | Percentage |
|---|---|---|
| 0 | 1 | 0.00 |
| 1 | 15 | 0.00 |
| 2 | 172 | 0.00 |
| 3 | 1950 | 0.00 |
| 4 | 21535 | 0.03 |
| 5 | 220368 | 0.30 |
| 6 | 1989591 | 2.73 |
| 7 | 13431990 | 18.40 |
| 8 | 40963892 | 56.12 |
| 9 | 16325184 | 22.37 |
| 10 | 36022 | 0.05 |
| HTM | Number of Patterns | Percentage |
|---|---|---|
| 0 | 17 | 0.00 |
| 1 | 255 | 0.00 |
| 2 | 3102 | 0.00 |
| 3 | 35217 | 0.05 |
| 4 | 367070 | 0.50 |
| 5 | 3184390 | 4.36 |
| 6 | 18621816 | 25.51 |
| 7 | 41028188 | 56.21 |
| 8 | 9746797 | 13.35 |
| 9 | 3868 | 0.01 |
| HTM | Number of Patterns | Percentage |
|---|---|---|
| 0 | 4 | 0.00 |
| 1 | 48 | 0.00 |
| 2 | 568 | 0.00 |
| 3 | 6556 | 0.01 |
| 4 | 70495 | 0.10 |
| 5 | 693185 | 0.95 |
| 6 | 5618257 | 7.70 |
| 7 | 27845257 | 38.15 |
| 8 | 36570024 | 50.10 |
| 9 | 2186315 | 3.00 |
| 10 | 11 | 0.00 |
| HTM | Number of Patterns | Percentage |
|---|---|---|
| 0 | 68 | 0.00 |
| 1 | 816 | 0.00 |
| 2 | 9256 | 0.01 |
| 3 | 103681 | 0.14 |
| 4 | 1012687 | 1.39 |
| 5 | 7689281 | 10.53 |
| 6 | 32089788 | 43.96 |
| 7 | 30868369 | 42.29 |
| 8 | 1216774 | 1.67 |
| HTM | Number of Patterns | Percentage |
|---|---|---|
| 0 | 1 | 0.00 |
| 1 | 15 | 0.00 |
| 2 | 178 | 0.00 |
| 3 | 1982 | 0.01 |
| 4 | 21041 | 0.09 |
| 5 | 204732 | 0.84 |
| 6 | 1645039 | 6.76 |
| 7 | 8477633 | 34.84 |
| 8 | 12917628 | 53.09 |
| 9 | 1061851 | 4.36 |
| 10 | 140 | 0.00 |
From memorizing single solutions to navigating search spaces. Why these solvers and trainers were built.
In modern speedcubing, nearly every learning path begins with algorithmic memorization. Solvers consult algorithm sheets for F2L, OLL, and PLL, practicing a strict one-to-one stimulus-response model: identify a specific case on the cube, then execute the memorized move sequence. As a pedagogical entry point, this approach is undeniably effective. It provides the fastest route to solving the Rubik's cube without visual aids and comfortably propels solvers toward intermediate milestones like sub-30 or sub-20 averages.
However, over-reliance on this model ingrains a subtle, damaging mindset: the subconscious belief that every cube state has only a single "correct" answer. The physical puzzle ceases to be an open problem space for dynamic reasoning and is reduced to a passive trigger mechanism for recalling stored muscle memory.
This mindset inevitably breeds an overemphasis on raw execution speed, or turns per second (TPS). When cubers search for alternative algorithms, the primary motive is almost always: "Which one can I execute the fastest?" Consequently, the fastest-turning sequence is crowned the best solution.
Yet, local efficiency rarely translates into global solve efficiency. The isolated execution speed of an algorithm is fundamentally decoupled from the total solve time. A lightning-fast F2L sequence provides zero competitive advantage if it rotates the next target pair into a blind spot on the back layers, forces an awkward regrip or y-rotation, or prematurely shatters another pre-paired piece in the top layer. In such cases, the pause required to re-identify the next pieces completely wipes out the milliseconds saved by high TPS.
The problem is not memorization itself. Rather, it is the inability to outgrow the single-answer paradigm when advancing to elite performance. Speedcubing is not simply a contest of executing pre-packaged algorithms as fast as possible; it is an ongoing process of evaluating tradeoffs across the entire solve.
The consequence of the single-answer mindset is a complete absence of meaningful choice, even in stages of the solve where flexibility is paramount. In F2L (First Two Layers), where algorithmic solutions are heavily cataloged, solvers frequently execute a single default sequence the instant they recognize a piece formation.
Yet, solving an F2L slot is rarely an isolated problem. For any given slot and pair state, there are multiple viable solutions, each with distinct trade-offs:
Rather than dynamically selecting the procedure best suited to the context of the solve, solvers often settle for the single representative algorithm they originally memorized.
Even more revealing is that this exact trap appears in the Cross—a stage characterized by immense intuitive freedom. During the 15-second inspection, intermediate and even advanced cubers routinely fall victim to a persistent habit: stopping their search the exact second they spot any viable Cross solution.
For any random scramble, there are typically dozens of valid Cross paths ranging from 5 to 8 moves. Settling for the first functional sequence encountered is a missed opportunity. The first Cross discovered is rarely the shortest, and even when it happens to be minimal, it may leave the first F2L pair scattered across difficult angles, hidden in back slots, or requiring an immediate rotation upon completion.
Knowing an answer—or finding a single workable path—is merely the prerequisite to playing the game. The true progression in speedcubing lies not in expanding your catalog of answers, but in cultivating the discipline to generate multiple candidates and evaluate which one creates the most favorable continuation for the solve.
The pedagogical flaws of the single-answer model become glaringly evident in how XCross (extended cross) is conventionally taught. Nearly every tutorial and walkthrough begins with a pre-selected, exceptionally convenient Cross. From there, the instructor explains keyhole techniques, pseudo-slotting, or blockbuilding insertions to fold an extra F2L pair into the Cross execution.
These tutorials showcase the finishing touches of a successful solve, but they systematically omit discarded drafts and failed attempts. They rarely demonstrate the "bad" Cross candidates that lead nowhere, completely glossing over the most cognitively demanding step of real-world inspection: Which baseline Cross should you build in the first place?
In actual competition solves, the bottleneck is almost never the insertion technique itself. It is the initial selection process. Cubers attempting to learn XCross struggle not because they fail to understand blockbuilding, but because they are never taught the comparative evaluation that precedes it. They are left trying to force-feed algorithmic insertion tricks into whatever random Cross they happen to see first.
A strictly minimal Cross—say, a 5-move solution—frequently scatters F2L pieces or isolates corners from their corresponding edges. Conversely, a Cross that intentionally takes a one- or two-move detour (such as a 6- or 7-move solution) might naturally preserve a pre-made block or set up an effortless three-move insert. When solvers fixate purely on minimizing the move count of the Cross in isolation, these high-value transitions remain completely invisible.
XCross is not an advanced execution trick for cramming an extra pair into a predetermined Cross. Fundamentally, it is the skill of generating multiple Cross candidates in parallel and identifying which base Cross naturally aligns with the first F2L pair. The true barrier to mastering XCross is not lack of blockbuilding knowledge; it is the refusal to compare base solutions.
Few concepts in speedcubing are as heavily romanticized—and routinely misunderstood—as Look Ahead. Taken literally, the phrase implies foresight bordering on omniscience: "Execute the current F2L pair at maximum speed while simultaneously scanning the entire puzzle to identify the exact position, orientation, and relationship of the next pair."
Framed this way, the cognitive burden is staggering. Solvers attempt to force an impossible multitasking feat, quickly conclude that human working memory cannot sustain it, and walk away frustrated.
In reality, Look Ahead is not clairvoyance; it is an exercise in deliberate environmental control. It would be far more accurately described as Continuous F2L or Next-Pair Tracking. Elite solvers do not peer into the future through brute perceptual force; they simply configure the present so that visual continuity is never interrupted:
This reveals a crucial insight: solving during F2L and planning during inspection are the exact same skill.
Cubers traditionally treat inspection planning and mid-solve Look Ahead as completely unrelated competencies. Yet their underlying architecture is identical. In inspection, an advanced solver rejects a crude Cross in favor of a candidate that yields a free pair, sets up an ergonomic 3-move insert, or effortlessly links into an XCross. In the middle of F2L, that same solver bypasses a lightning-fast insertion in favor of an alternate sequence that keeps the next corner-edge pair directly in line of sight.
Neither scenario requires psychic abilities. Both simply demand an intentional present choice that prevents the subsequent search from collapsing. Look Ahead is not about predicting the unknown; it is about steering the present so that the future remains effortless to follow.
Most conventional Rubik's Cube solvers output a single optimal solution. The engine performs an exhaustive search, isolates the absolute minimal move sequence, and prints it in one clean line. To a human user, however, this presentation reinforces the single-answer illusion: it creates the impression that the machine has delivered the one "true" way to solve the puzzle.
The trouble is that a computer's optimal solution is completely decoupled from human intuition. It often depends on unintuitive finger-tricks, unnatural slice turns, or awkward angle changes. More critically, it provides zero context: the solver has no way of knowing which baseline Cross that sequence was derived from, making it nearly impossible to assimilate into real inspection habits.
This reveals why calibrating scrambles to an exact move count is often misunderstood. Some solvers question whether knowing the move count in advance acts as a "spoiler" or an artificial hint. That objection only makes sense within the single-answer paradigm, where solving is treated as a guessing game with a score.
In practice, the move count is not a hint; it is a calibration metric for the search space. It defines the boundary of acceptable detours: "How many extra moves must be spent before a favorable structure (such as an XCross or oriented pair) emerges?" Once a cuber shifts from hunting for a single correct string to comparing viable candidates, knowing this parameter simply anchors their evaluation within realistic human bounds.
This is also why human solvers need access to dozens—or hundreds—of simultaneous solutions. When a beginner who only sees one basic Cross inspects an isolated, computer-generated XCross, the sequence looks like black magic. Without knowing the underlying baseline, they cannot reverse-engineer the logic. They try to force their familiar "bad Cross" into an XCross using clumsy, high-move insertions, never learning what makes an efficient solution tick.
When an entire spectrum of solutions is displayed side-by-side, the structure of the puzzle suddenly becomes transparent:
A multi-solver workbench is not an answer key; it is a cartography tool for the search space. By comparing alternative baselines against their resulting extensions, solvers transition from passively tracing computer outputs to actively recognizing patterns they can choose for themselves.
Speedcubers exploring these tools often notice a conscious design omission: there is no stopwatch. In an ecosystem where almost every practice utility revolves around timers, these tools strip away time measurement entirely, pairing only a specialized scrambler with an analytical multi-solver.
This omission is deliberate. The second a running clock appears on screen, human cognition shifts from exploration to panic. Confronted by milliseconds ticking away, solvers instinctively default to their oldest habits: locking onto the first workable Cross they spot and turning as fast as possible to salvage their average. A timer enforces the very stimulus-response loop this project aims to break. True evaluation requires unpressured space to test alternatives, verify hypotheses, and steadily raise the resolution of your mental planning.
A similar principle governs the move-count calibration. The scramblers do not produce states solvable in "at most N moves"; they guarantee an exact minimal move count of N via exhaustive search verification.
Allowing loose upper bounds introduces accidental shortcuts—lucky 3- or 4-move solutions that undermine deliberate practice. When a solver knows with absolute mathematical certainty that an 8-move solution exists and that nothing shorter is possible, the nature of their search changes. It is no longer an idle guessing game. The move count ceases to be a cheat; it becomes a structured constraint that grants solvers the conviction to look beyond superficial pairings and hunt for structural interactions they would otherwise overlook.
This context clarifies the purpose behind seemingly impossible tools like the XXCross, XXXCross, and XXEOCross trainers. These targets were never designed under the expectation that an average human would plan three complete F2L slots and full edge orientation within a standard 15-second WCA inspection.
Instead, they serve as cognitive sandboxes. Under extreme, hyper-dense constraints, the fundamental mechanics of piece interference, orientation conservation, and slot independence are magnified. By examining how three slots can be harmonized simultaneously—or how middle-layer EO can be preserved without sacrificing cross efficiency—solvers develop a wider conceptual perspective. When they return to ordinary single-slot XCrosses or standard crosses in real competition, the search space no longer feels overwhelming; it feels spacious.
These trainers are not competitive arenas meant for logging fast splits. They are laboratories for decision-making—built to help cubers transcend mechanical repetition and rediscover the Rubik's Cube as an evolving landscape of conscious choice.