I tested 39 LLMs on solving Rubik's cubes with no tools

Only two of 39 large language models tested on RubiksBench could reliably solve a Rubik's cube without tools, with most models unable to solve a cube just six moves from completion, according to the benchmark's single-request, temperature-0 harness run through OpenRouter. The test showed models cubes scrambled in 3, 6, 10 and 20 moves, with 10 cubes each at the 6-, 10- and 20-move levels, and required at least one solve to advance a round; the 20-move ceiling reflects God's number, the finding that all 43 quintillion 3x3 positions are solvable in 20 moves or fewer. The benchmark notes that claude.ai and chatgpt.com solve nearly every cube when allowed to write scripts calling a solver library such as kociemba, which the no-tools harness excludes.

If you’ve ever looked into solving a Rubik’s cube you’ll know it has a concise DSL to represent the 18 possible moves: six faces Up, Right, Front, Down, Left, Back , each turned clockwise, anticlockwise, or halfway round: | Face | Clockwise | Anticlockwise | Half turn | |---|---|---|---| | Up | U | U' | U2 | | Right | R | R' | R2 | | Front | F | F' | F2 | | Down | D | D' | D2 | | Left | L | L' | L2 | | Back | B | B' | B2 | The entire cube state can also be represented in 2D, unfolded into a cross like this: U U U U U U U U U L L L F F F R R R B B B L L L F F F R R R B B B L L L F F F R R R B B B D D D D D D D D D Since the problem the cube and its answer a list of moves are both just text, it makes for an easy test to give an LLM and an easy one to grade as you can play the moves on a simulator and see if the cube is solved. I built RubiksBench https://rubiksbench.com/ to see how LLMs compare. The short answer: out of 39 models, only two can reliably solve a Rubik’s cube. Most can’t even solve one that’s six moves from done. The test Show a model a scrambled cube as text and ask it to reply with the moves that solve it. A few other rules: - No tools. - If you ask claude.ai https://claude.ai or chatgpt.com https://chatgpt.com you’ll get the right answer almost every time, because they write a script that calls a solver library like kociemba . So the harness sends one request through OpenRouter, offers no tools, and scores whatever comes back. - The model gets one reply. - Temperature is set to 0, though some reasoning models ignore it. - Every model gets the same cubes in the same order. - There are four rounds: 3, 6, 10 and 20-move scrambles. A model has to solve at least one cube to move up. Not very scientific, but it stops me burning tokens on calls that will never produce a result. - 3 moves is just a sanity check and isn’t ranked. One solve gets you through. The 6, 10 and 20-move scrambles get 10 cubes each. Why stop at 20 moves? Despite there being 43 quintillion scrambled positions on a 3x3 Rubik’s cube, all of them can be solved in 20 moves or fewer. This is known as God’s number https://en.wikipedia.org/wiki/God%27s algorithm . The existence of God’s number means scrambling the cube with 50 or 100 moves doesn’t make it any harder than scrambling it with 20. In an earlier version of the prompt I tried this with GPT-5.6 Sol and the scores at 25, 50 and 100 all sat in the same range as at 20 and used roughly the same amount of reasoning tokens. The prompt This is the actual prompt for one of the cubes: Below is a scrambled Rubik's Cube, shown unfolded with all 6 faces visible. Each face is a 3x3 grid of stickers. Each letter names a sticker's color, using the face it belongs on when the cube is solved: U=White Up , R=Red Right , F=Green Front , D=Yellow Down , L=Orange Left , B=Blue Back . The diagram is laid out as follows: - The first 3 lines indented are the U Up face. - The next 3 lines each hold four space-separated 3-sticker groups. Left to right, these groups are the L Left , F Front , R Right and B Back faces. - The last 3 lines indented are the D Down face. Each face's rows and columns are oriented as they appear once the cube is folded up: - U: its first line is the row touching B, and its last line is the row touching F. - D: its first line is the row touching F, and its last line is the row touching B. - L, F, R and B: the first line of each is the row touching U. - Reading a line from left to right: U, F and D run from L to R; R runs from F to B; L runs from B to F; and B runs from R to L. B U U F U U F L L U L L D B B D L L F F L R L L D F F R R U B B U R D D R F F R R U B B U B D D B D D F R R Give the sequence of moves that returns this cube to a fully solved state all 9 stickers on each face matching . Respond with only the move sequence in standard notation: a space-separated list of face letters U, D, L, R, F, or B , each optionally followed by ' for a counterclockwise turn or 2 for a double turn. Do not copy any example — work out the actual sequence for the cube shown above. Do not include any explanation, commentary, or code. The results These are the results as of 27 October 2026. The live leaderboard https://rubiksbench.com has the latest scores. Only 7 of the 39 models solved even one 20-move scramble, which is as scrambled as a cube gets. Each model at its best thinking setting: | Model | 6 moves | 10 moves | 20 moves | |---|---|---|---| | GPT-6 Astra | 10/10 | 10/10 | 9/10 | | GPT-6.1 Sol | 10/10 | 10/10 | 8/10 | | Kimi K3.1 Pro | 9/10 | 4/10 | 7/10 | | GPT-5.6 Sol | 7/10 | 5/10 | 5/10 | | GPT-6 Sol | 2/10 | 2/10 | 2/10 | | Claude Opus 5.5 | 5/10 | 2/10 | 1/10 | | Claude Sonnet 5.5 | 4/10 | 1/10 | 1/10 | A note on noise: even at temperature 0 , the same model on the same 10 cubes can produce different results from one run to the next. Scores can differ by about 2 cubes. So the top two are clearly ahead, but the order of the rest is mostly noise. You’ll notice that only OpenAI, Anthropic and a single Kimi model make the list. No Grok, Gemini, Meta, DeepSeek, Mistral or Qwen model solved a 20-move cube most couldn’t even solve a 6-move cube . The top two Astra and GPT-6.1 Sol are outliers, solving nearly every cube given to them. The next best Kimi K3.1 Pro solves about two thirds. How they solve it For 3-move scrambles, the models that pass can tell the cube is barely scrambled. They work out the three moves from the cube itself, then play them backwards. At 6 moves, many still notice it’s close to solved, but they can’t work out which moves to undo. So they give up on that and solve the cube the way a beginner learns, which is one layer at a time, with small, fixed move sequences. It’s not sexy, but it works. Each short sequence solves a piece or two without breaking the ones already solved, rather than using highly efficient solving algorithms on the whole cube. Here’s GPT-5.6 Sol solving a 6-move scramble in 151 moves layer by layer: The models that produce shorter answers generally perform worse, suggesting going the long way is easier for the models. Here are the move lengths across every answer for every model on the 6-move cubes. | Answer length | Solved | Wrong | Share solved | |---|---|---|---| | 20 moves or fewer | 17 | 163 | 9% | | 21 to 49 moves | 8 | 85 | 9% | | 50 moves or more | 54 | 43 | 56% | On 10-move and 20-move scrambles, none of the 77 solves, across every model and setting, were 20 moves or fewer. A short answer is usually a model going for the shortest route and missing. Claude Opus 5.5 does this the most, with its wrong answers at 6 moves being about 7 moves long. Why the long way works With a short, near-perfect solve the cube looks scrambled right up until the last couple of moves, then suddenly it’s solved. There’s no way to tell if you’re on track until you’re done. So the models that do try this have to get up to 20 moves exactly right in their head. Less than 10% managed it on 6-move cubes, and none did on 10 or 20. In contrast, the beginner’s method, which the models seem to be aware of, allows you to check after each step. The sequence is cross → bottom layer → middle layer → top face → last pieces into place, which is exactly what GPT-5.6 Sol did in the above example. The answer ends up being much longer, but each part of it can be verified independently, so it’s ultimately much easier for the models. Early on, I tested this with GPT-5.6 Sol by giving it the same cube it took 151 moves to solve and asking it to provide the shortest possible solution, 20 moves or fewer. It thought for much longer and came back with 20 moves, but they didn’t solve the cube. Its thinking shows it was trying the near-optimal two-phase method: “My goal is to find an optimal solution using a two-phase method, but it’s computationally intensive. I want to guarantee the shortest path when solving.” Failure modes Failures mostly happen in one of three ways: the model produces an incorrect answer, the model refuses to answer, or it thinks itself to death. Wrong answers The model writes a legal list of moves, and when you play them the cube isn’t solved. About 45% of all failures happen this way. Refusals About 20% of failures are the model outright refusing to answer, usually with something like “I cannot solve this cube”. Here are some real examples: - “The position is unreachable odd edge-orientation parity , so no solving sequence exists.” - Grok 4.7 https://rubiksbench.com/models/x-ai/grok-4.7?effort=xhigh&depth=10&cube=3&thinking=1 - “I cannot reliably solve this specific Rubik’s Cube state without computational tools. I apologize for the inconvenience.” - DeepSeek V4.1 Flash https://rubiksbench.com/models/deepseek/deepseek-v4.1-flash?effort=high&depth=6&cube=8&thinking=1 - “I can help solve it, but I need either a clarifying image or a precise mapping of each sticker position to its color letters.” - GPT-5 Nano https://rubiksbench.com/models/openai/gpt-5-nano?effort=low&depth=3&cube=5&thinking=1 Thinking itself to death The model maxes out its token budget on thinking without ever producing an answer. About 30% of failures happen this way. The “thinking” setting dictates how much of the model’s token budget is allocated to reasoning tokens vs output tokens. On OpenRouter, the split is 20% allocated at low , 50% at medium , 80% at high and 95% at max . With a 128,000 token limit limits differ by model at max , that’s about 121,600 tokens for thinking and only 6,400 left to write the answer. If all tokens are spent on reasoning, nothing will be returned and the run is considered a fail. Here are some of the ways different models think themselves to death: - Mistral Large 4 https://rubiksbench.com/models/mistralai/mistral-large-4-0?effort=high&depth=3&cube=4&thinking=1 on a 3-move cube thought for 238,587 tokens, about 950,000 characters, and said “Wait” 543 times. Near the end it still hadn’t settled what a single U turn does: “But I’ve seen in cubing notation: U move: UF - UR? … I’m not sure.” - Claude Fable 5.1 https://rubiksbench.com/models/anthropic/claude-fable-5.1?effort=max&depth=10&cube=7&thinking=1 plays its own answer through one sticker at a time, checking every piece after every turn. It ran out at move 38: “Now I’m applying move 38, a B turn.” - Claude Sonnet 5.5 https://rubiksbench.com/models/anthropic/claude-sonnet-5.5?effort=high&depth=6&cube=6&thinking=1 used all 128,000 tokens, and its thinking ends: “Still tracking cube face rotations… Still tracking cube state…” - Kimi K3 https://rubiksbench.com/models/moonshotai/kimi-k3?effort=max&depth=6&cube=3&thinking=1 starts confident: “beginner method from scratch might take ~60 moves. Tracking 60 moves manually is possible” . 90,000 tokens later it has only the first step, the cross: “Could we use the cross sequence and then solve the remaining last two layers using a known method? Still hard.” - Hunyuan Hy4 https://rubiksbench.com/models/tencent/hy4-preview?effort=low&depth=6&cube=10&thinking=1 was counting stickers, came up one short, and asked itself “Missing one U sticker maybe R? R row?” Then it wrote “R row?” 15,912 times and ran out of tokens. The rest The rest were rare failures that don’t fit any of these and aren’t interesting enough to go into detail about. Things like the model producing the right moves but with nonsense appended to the end, or a provider Meta that cuts off any call that runs past about 6 minutes. Lower is sometimes better For the Opus models, a lower setting forces the model to stop and commit. At low , Opus 5.5 answered all 10 cubes using about a third of the thinking, and half of those answers were right. The OpenAI models go the other way, because they almost always stop and produce an answer. Astra answered every cube at both low and xhigh with scores of 8/10 and 10/10 respectively. A lower setting doesn’t make a weak model good. It just confirms the model’s failure. Kimi K3 at max https://rubiksbench.com/models/moonshotai/kimi-k3?effort=max&depth=6 and Hunyuan Hy4 at high https://rubiksbench.com/models/tencent/hy4-preview?effort=high&depth=6 maxed out their token budget on almost every cube 9 and 10 out of 10 . At low , both answered all 10 cubes but still got all 10 wrong. The exception to this is Claude Fable 5.1 https://rubiksbench.com/models/anthropic/claude-fable-5.1?effort=max&depth=6 , which fills its token budget at every setting, producing only 1 answer at low , 2 at max . Its first three calls at max wrote nothing. Its thinking summary on one of them: “Still tracking cube rotations…” Closing thoughts Already the benchmark is somewhat saturated at the top. Two OpenAI models, GPT-6 Astra and GPT-6.1 Sol, solve nearly every cube, and Kimi K3.1 Pro recently reached 7 of 10 on 20-move scrambles. Nobody else is really close at the moment, but I expect a few models to score 10/10 at every length in the next few months. When this happens the next step up would be larger cubes such as 4x4. Until then, I’ll keep benchmarking models as they come out. The board at rubiksbench.com https://rubiksbench.com/ will continue to see updates. If you enjoyed this, give me a follow on X https://x.com/brianbriscoe