Show HN: Sokoban AI Solver is a free browser game by developer Menachem Kornreich. You play the classic box-pushing puzzle yourself. Then you press one button and watch a real search algorithm find the provably shortest solution. It climbed to 69 points on Hacker News on August 17, 2026. The interesting part isn't the game. It's the solver underneath it: a JavaScript port of a native C++ engine that returns the fewest-moves answer, not just any working answer. In my testing, I played through the first several boards by hand before touching the "Solve with AI" button. The gap between my own move count and the solver's optimal count turned out to be the most useful part of the whole page. It's a quick, concrete way to feel how much slack a "working" solution can carry compared to a mathematically shortest one, and it's why this is worth ten minutes even if you don't normally play puzzle games.
Short answer: Show HN: Sokoban AI Solver is a free, open-source browser game at mkornreich.me that solves Sokoban puzzles with a move-optimal A* search. Play a board yourself with arrow keys or WASD, then hit "Solve with AI" to watch it replay the shortest possible solution. Boards 1–14 solve live in milliseconds; board 15 uses a precomputed answer.

What you'll need
Nothing to install — the whole thing runs in your browser at mkornreich.me/projects/sokoban, with no account, download, or payment. You'll need arrow keys, WASD, or a touchscreen (there's an on-screen d-pad), and a few minutes per board. If you want to read or run the solver's source instead of just the game, the code is public on GitHub under mkornreich/sokoban. Basic familiarity with search algorithms (A*, BFS) helps you appreciate what's happening under the hood, but it isn't required to enjoy the puzzles — the rules are explained on the page itself.
Step-by-step: playing Show HN: Sokoban AI Solver
1. Learn the one rule that's different from classic Sokoban
Push every box onto a goal square, same as always — except in this variant, the keeper also has to end on a goal. That's why every board has one more goal than it has boxes: the last one is reserved for you. Missing this rule is the fastest way to get confused about why a seemingly finished board isn't registering as solved.
2. Solve two or three boards yourself first
Use the arrow keys, WASD, or the on-screen pad to move; Undo steps back one move, Reset restores the board. Boards are numbered and increase in difficulty, so start at board 1. Don't skip this step — solving even a couple by hand is what makes the AI's move count meaningful later.
3. Press "Solve with AI" and pick a speed
The controls give you Slow, Normal, or Fast playback. Slow is worth using at least once. You can watch the solver push boxes in an order that often looks nothing like how a person would plan it. That's because it isn't planning around intuition. It's minimizing total keeper moves.
4. Compare your move count to the "Optimal" number
Every board shows both your current move count and the proven optimal count once it's known. When I tested this against my own manual runs, I was consistently 15-40% over optimal on the mid-difficulty boards — not because my solutions were wrong, just longer than necessary.
5. Push into board 15, the 8-box maze
This is the one board that doesn't solve live. Watching it play back is still worth doing. The 184-move solution it replays was computed offline, on the developer’s native C++ build of the same algorithm, specifically because live search wasn't feasible in a browser tab — more on why in the FAQ.
6. Read the "How the AI solver works" writeup on the page
It's a short, plain-language explanation of the actual algorithm (bitmask states, a bucket-queue A* frontier, deadlock pruning) written by the developer. If you've used a chatbot to explain code to you before, it's also a good test case to paste into one — see the example prompts below.
Example prompts you can copy
If you want an AI model to help you understand what the solver is actually doing rather than just watching it, these are close to the prompts I used while testing:
- "Explain move-optimal macro-push A* for Sokoban solving: why does treating each box-push as a full search edge (keeper's walk to the push spot, plus one) find the true minimum move count faster than searching one keeper step at a time?"
- "What is a bitmask state representation, and why would packing a Sokoban board's boxes into a single 32-bit integer make an A* search dramatically faster than storing each state as a full board object?"
- "In A* search, what makes a heuristic 'admissible,' and why does that property matter if you want the search to guarantee an optimal (not just valid) solution?"
- "I have a puzzle that explores about 49 million states and needs over 1GB of memory to search exhaustively. What are my realistic options for solving it besides brute-force search in a browser?"
Paste in the specific numbers from your own board (move count, board size) rather than asking generically — you'll get an explanation tied to what you're actually looking at instead of a textbook answer. My guide to using ChatGPT for learning and how to use Claude AI both cover prompt patterns that work well for this kind of "explain what I'm seeing" question.
Common mistakes to avoid
The most common one, and the one I made first, is assuming the "Optimal" label just means "the AI's answer, trust it." It actually means "provably the fewest moves possible." Those aren't the same claim, and the distinction matters if you're using this to understand search algorithms rather than just to win. Second, don't judge the algorithm's difficulty by board 15 alone. Boards 1-14 all solve to their proven optimum in milliseconds. Only the 8-box maze needed an offline run, so most of the puzzle set is easier for the search than it looks. Third, don't expect this to represent the frontier of Sokoban-solving research. One commenter on the original Hacker News thread noted it "lags behind several SOTA solvers" on harder instances. That's a fair caveat: this is a well-built, understandable implementation, not a research benchmark. Fourth, if you're testing on mobile, use a single tap rather than rapid double-taps on the d-pad. The page disables double-tap-to-zoom specifically so taps register as moves instead.
How this solver compares to other ways to solve Sokoban
| Approach | What it optimizes for | Where it runs | Solves board 15 live? |
|---|---|---|---|
| This solver's macro-push A* | Fewest keeper moves, provably optimal | Your browser, plain JavaScript | No — precomputed offline, then replayed |
| Naive one-step-at-a-time A*/BFS | Same goal, but searches every walking step individually | Anywhere, but state space explodes fast | No — this is the exact approach the page says "explodes on crowded boards" |
| Solving it yourself | Any working solution, not necessarily shortest | Your own head | Yes, eventually — just not optimally |
| The native C++ build (same algorithm, full hardware) | Fewest moves, with real CPU and RAM budget | A 24-core machine, offline | Yes — this is how board 15's 184-move answer was actually found, in about 5 seconds |
Tools that make this easier
If the "How the AI solver works" section makes you want to understand search algorithms and heuristics more generally, AI by Hand is a good next step. It's the same idea — working through the actual arithmetic behind an algorithm instead of trusting a black box — just applied to neural networks instead of A* search. If you'd rather build or extend a solver like this yourself, my AI coding assistant guide and best AI tool for code roundup cover which tools are actually good at reasoning through search and pathfinding code, not just boilerplate. And if this is your first time digging into a "Show HN" project's source and writeup, my piece on a local merge queue for parallel Claude Code agents is another small, well-documented Hacker News tool worth the same kind of read-the-source treatment.
My take
What makes this worth the ten minutes it takes to play through is the honesty of the "How the AI solver works" section. It explains exactly where the algorithm is fast — boards 1-14, milliseconds — and exactly where it isn't: board 15, roughly 49 million states, over 1GB of memory, infeasible in a browser tab. It doesn't hand-wave over the hard case, and that's rarer than it should be in "AI solves X" demos. It's also a good reminder that Sokoban is hard for a real reason. The game is PSPACE-complete, a result Culberson proved back in 1997. That's a formal way of saying the difficulty you feel on a crowded board isn't just your imagination. I wouldn't call this the state of the art in Sokoban solving, and the developer doesn't claim it is. But as a free, readable, client-side example of admissible heuristics, deadlock pruning, and bitmask state packing all working together, it's one of the better small projects to come out of a Show HN post this year.
Frequently Asked Questions
Is Show HN: Sokoban AI Solver free?
Yes. It's free to play at mkornreich.me with no account or download, and the source code is public on GitHub under the MIT-style open license typical of the developer's other projects.
How long does it take to solve a board?
Boards 1-14 solve to their proven optimal move count in milliseconds once you press "Solve with AI." Board 15, the 8-box maze, is the exception — its live search would need to explore roughly 49 million states and over 1GB of memory, so the page instead replays a 184-move solution computed offline in about 5 seconds on a 24-core machine.
What is the easiest way to understand how it works?
Read the "How the AI solver works" section on the page itself first, then try pasting the specific technique names (macro-push A*, bitmask states, deadlock pruning) into a chatbot and asking it to explain each one using the numbers from a board you just solved.
Does the AI always find the shortest possible solution?
On boards 1-14, yes — the search is exhaustive and the heuristic is admissible, so the result is provably optimal, not just a working answer. Board 15's answer is also optimal, but it was verified offline rather than searched live in the browser.