How I solved Jane Street's July puzzle

July 30, 2026

‘Pent-Up’ Frustration 3 / Knight Moves 7 hands you an 8×8 board, thirteen invisible towers, and eleven numbers a knight scribbled down on its way past. Reconstructing the walk took a pixel ruler, one beautiful forced deduction, and a search that was over almost before it began.

The puzzle

Jane Street’s July puzzle crosses two of their recurring series. The board is tiled by the twelve pentominoes plus one 2×2 square, giving thirteen regions. Each region is a slab one cube tall, and each must receive a tower — one extra cube on a square of your choosing. A knight starts on the bottom-left square and makes knight’s moves — in three dimensions: every move travels 0 units along one axis, 1 along another, and 2 along the third, where the third axis is altitude. It never lands on the same square twice, and it keeps going until it has stood on top of every tower.

The scoring rule is where the frustration lives. The knight starts at 0, and on its N^th move its score increases by N if it lands at the same altitude it left, is multiplied by N if it moves up, and is divided by N if it moves down — a move that is only legal when the score divides evenly.

Every three moves up to move #18, the knight wrote its score on the square where it landed. After that it wrote only every K moves, for some unstated K > 3. The board shows the twelve numbers it left behind (the 0 is the starting square):

The question isn’t the path itself. Once you’ve reconstructed the walk and filled every visited square with its score, you take each unvisited square, sum the scores on its orthogonal neighbors that the knight did visit, and add those sums up. That total is the answer.

Reading the board with a ruler

Rule one of a puzzle whose input is a picture: don’t trust your eyes, measure. I wrote a small script that walked every internal edge of the 855×855 image (the grid sits neatly at 45 + 95i pixels) and measured the darkness band across each one. The histogram was perfectly bimodal — every edge was either 2 pixels wide (plain grid) or 7 pixels wide (region border), with nothing in between. Flood-filling with the thick edges as walls produced 13 regions.

Here the puzzle hands you a checksum for free: the tiling should be the twelve pentominoes, each used once, plus a 2×2. My extracted regions were exactly that — F, I, L, N, P, T, U, V, W, X, Y, Z, one of each. A single misread edge would have broken the multiset, so this one check retired the biggest risk in the whole pipeline. The twelve printed numbers I cropped and read by eye from a contact sheet: 0, 1, 16, 23, 37, 88, 138, 272, 449, 528, 750, 1100.

What the rules actually pin down

Before searching, it pays to squeeze the model. Squares have altitude 1, towers altitude 2. A move’s displacement across (Δx, Δy, Δaltitude) must be a permutation of (0, 1, 2), which leaves only two families:

• Planar knight moves — the usual (1,2) hop with altitude unchanged: both squares must be at the same height. Score +N.
• Vertical slides — two squares straight in any direction, altitude changing by exactly 1: one endpoint is a tower, the other isn’t. Score ×N going up, ÷N coming down.

An altitude change of 2 is impossible when heights only span 1–2, so those are all the moves there are. Two consequences do a lot of work later. First, ups and downs strictly alternate — you can’t multiply twice without dividing in between, because after going up you’re on a tower and the only vertical move left is down. Second, the score is always a nonnegative integer, and 0 divides evenly by everything.

The bookkeeping constraint is lovely: eleven numbers, six of them from the writes at moves 3, 6, 9, 12, 15, 18 — so exactly five writes happened afterwards, at moves 18+K, 18+2K, …, 18+5K. The path can’t exceed 63 moves (64 squares), so 18 + 5K ≤ 63, boxing K into 4…9. And since the knight stops the instant it has visited all thirteen towers, the final square of the walk must itself be a tower.

The gift: a forced opening

Here is the deduction that cracks the puzzle open. Enumerate every score a knight can have after three moves. Starting from 0, running all 27 op-sequences and discarding illegal divisions leaves a six-element set: {0, 1, 3, 5, 6, 9}. The write at move #3 must land on a printed number. Two printed values sit in that set — but the 0 is on the starting square, which the knight can never revisit. That leaves the 1, sitting on g3.

Better still, there is exactly one arithmetic route to 1: 0 + 1 = 1, 1 + 2 = 3, 3 ÷ 3 = 1. The division means move #3 was a down move — the knight stepped off a tower onto g3. And the two additions before it were same-altitude moves, which chains the equality all the way back: the starting square and both intermediate squares are all at altitude 2. All three are towers.

Geometry finishes the job. A down-slide into g3 comes from e3, g1, or g5; of those, only e3 is a knight’s move from a square that is itself a knight’s move from a1 — namely c2. Before writing a single line of search code, the opening is forced:

Teaching a computer to feel frustration

The naive decomposition — enumerate tower placements, then search for a path — is doomed: 4 · 5¹² ≈ 977 million placements before a single move is tried. The right shape is one depth-first search over the walk, deciding lazily whether each newly visited square hosts its region’s tower. Height only ever matters on squares the knight actually touches; any region whose tower the search hasn’t placed on the path yet simply must still have a square available.

The printed numbers act as checkpoints, and nearly all the pruning power lives there:

• Checkpoint feasibility. At every node, sort the BFS distances to the still-unused printed squares; the i-th nearest must be reachable by the i-th remaining write time (a Hall’s-condition-style relaxation). One clue out of reach kills the branch.
• Arithmetic feasibility. Between checkpoints there are at most K moves whose numbers are known. A tiny 3-way recursion (at most 3⁹ sequences, cut far earlier) asks: can any unused clue value even be produced from the current score in this gap? If not, prune.
• Region feasibility. Every towerless region still needs an unvisited square within reach of the remaining moves.
• A score ceiling. Ups and downs alternate, and within one checkpoint window the move numbers are consecutive — so each up/down pair multiplies the score by a factor close to 1, and a lone unpaired climb tops out at ×63. A score that strays more than a couple of orders of magnitude above the printed values can never get back to one by the next write, so capping it at 10⁸ discards nothing a real solution could do.

The result was almost anticlimactic. For K = 4, 5, 6, 8, and 9 the search dies after exactly 850 nodes — the checkpoint arithmetic can’t survive past move 18. For K = 7 it explores 195,309 nodes and returns exactly one solution, in well under a second. No second path, no alternative tower placement, nothing.

The unique walk

The knight’s eleven notes, in order:

Overall the walk breaks down as 42 additions, 6 multiplications, and 6 divisions, and every multiplication but the final one is shadowed by a division a move or three later — the knight climbs a tower, lets the score spike, then pays it back down. My favorite details are the divisibility coincidences the setter engineered: the score is 248 when the knight climbs at move 30 precisely because 248 = 8 × 31, so the ×30 spike to 7,440 can come back down cleanly through ÷31. The 8,976 = 272 × 33 spike likewise lands exactly on a multiple of 34.

The ending is the flourish: the last written value, 1,100 on h8, then a climb off the corner — 1,100 × 54 = 59,400 — onto the tower at h6, the thirteenth and final one, and the knight stops on the spot.

The answer

Nine squares were never visited. For each, sum the scores on its visited orthogonal neighbors:

Challenges and wrong turns

Trusting pixels. The scariest failure mode was never the search — it was feeding it a board with one wrong edge and getting a confident, wrong, internally consistent answer. The pentomino checksum caught that risk early, and I later re-extracted the board from scratch, with fresh code, as an independent check.

“Every K moves” is genuinely ambiguous. Writes at 18+iK is the natural reading, but writes at multiples of K (21, 28, … for K=7) is defensible, and so is reading “up until move #18” exclusively, ending the early writes at 15. Rather than argue grammar, I ran the search under all three readings. The two alternatives admit zero solutions for any K; the natural reading admits exactly one. When one interpretation of an ambiguous sentence produces a unique solution and the others produce none, you’ve found the setter’s intent.

Pruning without lying. Every prune had to be a strict relaxation — a condition that no genuine solution could fail — because the deliverable wasn’t a solution but a proof of uniqueness. The score cap was the one that needed an actual argument (the alternation lemma above) rather than a shrug.

Small rules with teeth. Three subtleties would each have silently broken the search: the knight stops immediately on the thirteenth tower, so the final square must be a tower; the starting square may itself host its region’s tower (and the unique solution requires it — a1 is a tower); and 0 divides evenly by every N, so the score can idle at 0 through vertical moves.

Alternative approaches

By hand? More viable than it looks, at least at first. The opening is forced with pencil and paper, the early checkpoints are only three moves apart, and parity plus the clue geometry constrain the midgame heavily. I suspect a patient human solver rides the checkpoints most of the way and only sweats in the seven-move gaps. That’s presumably the intended experience — the computer just removes the “patient.”

Constraint programming / SAT. You could encode position-per-move one-hots, altitude variables, and the score recurrence, and let a CP solver prove uniqueness. The catch is the score arithmetic: multiplication by move number with values in the tens of thousands makes for ugly propagation. Bounded score domains would tame it, but the bespoke DFS with checkpoint pruning is both simpler and certainly faster here.

Meet-in-the-middle. The checkpoint structure invites solving each clue-to-clue segment independently — enumerate all (path fragment, score) pairs consistent with consecutive checkpoints, then stitch fragments on compatible visited-sets and tower commitments. Overkill for a search this small, but it’s the right architecture if the gaps had been longer or the board bigger.

Towers first. The tempting decomposition — guess all thirteen towers, then pathfind — multiplies a billion-case outer loop by a hard inner problem. Deciding tower placement lazily inside the path search is the entire ballgame; it turns tower choice from a combinatorial explosion into a two-way branch at first visit.

Verification

A solve like this is a pipeline of things that can each silently fail, so the answer got layered checks: I wrote an independent verifier from scratch — exact rational arithmetic, every rule re-tested — and then attacked my own answer from three more angles: re-extracting the board from the pixels with fresh code, re-auditing every rule and my reading of the instructions, and recomputing the final sum two structurally different ways. Everything agreed.

I solved this fully offline — no forums, no hints — and only after locking in 33,609 did I look around. Two published community solutions, one in Java and one with a full write-up, report the same K, the same final tower with the same 59,400, the same nine neighbor sums, and the same total.

Puzzle: Jane Street Puzzles — 'Pent-Up' Frustration 3 / Knight Moves 7, July 2026. Final answer 33,609. Board coordinates in this post use chess notation: files a–h left to right, ranks 1–8 bottom to top; the knight starts on a1.