Yohei Nakajima's soft-to-rigid packing set a new record for 12 unit cubes in a cube (2.93151). His log stops at n = 13 after 48 runs (best 2.997) when his cloud machine restarted. This repo picks up from there.

Page: https://tronford.github.io/cubes-in-cube-n13/ (3D view, chart of all runs, in-browser check, note, PDF)

Result: 13 unit cubes fit in a cube of side 2.956145 (contact value 2.956145157584923). With 10⁻⁶ clearance on every pair and every wall, the certified side is 2.956148820837.

This matches Erich Friedman's 1998 entry for n = 13, shown on the Cubes in Cubes page as 2.956+. The page gives only three decimals, so it is not claimed as an improvement. Most likely it is the same packing, found again from scratch.

Video of the run (21 s): media/cubes13.mp4. Balls in a big box are squeezed, harden into cubes, settle, and the final packing is pulled apart until nothing overlaps. Eight cubes stay axis-aligned in the corners; five tilted cubes (17°, 28°) fill the middle.

Dropping a 14th cube into the 13-cube packing and re-melting (348 runs) gave a raw 2.990191, which exact tightening took to 2.9899494936611677. Friedman's 1998 entry for n = 14 is the closed form 2 + 7√2/10 = 2.9899494936611664: the two agree to about 10⁻¹⁵. Eight cubes sit axis-aligned in the corners, four are tilted by 45° and two by 8.1°. Claim file with 10⁻⁶ clearance (side 2.9899532177546): claims/cubincub_n14/, VALID and CERTIFIED (91 pairs). Not an improvement - the method finds the 1998 construction, nothing below it so far.

All on one home PC (12 threads, Node + Python), 9 October 2026.

Three different starting points end in the same place. Every raw run below 2.957 that was tightened with the exact solver converges to 2.956145158, the same value to nine decimals. Kicking the best packing (random shifts and rotations of up to 11 cubes, then exact re-tightening) never went below it: it either returned to 2.956145158 or fell apart into a worse packing. Every run is listed in results/runs_n13.csv.

So this method finds the 1998 packing reliably once it has enough runs, and nothing below it.

python verify.py claims/cubincub_n13/cubincub_n13.json          # standard library only
python certify_exact.py claims/cubincub_n13/cubincub_n13.json   # exact rational arithmetic, needs numpy + scipy

Outputs: verify_output.txt (VALID, min pair gap 1.0e-6, min wall gap 1.0e-6) and certify_output.txt (CERTIFIED, a separating plane for each of the 78 nearby pairs). File format is the same as the Hyra and Nakajima record files: one [x, y, z, qw, qx, qy, qz] pose per cube in [0, s_full]³.

node scripts/replay13.js            # the record seed: prints side 2.9561676813530875, writes out/replay13.json
node scripts/worker2.js 13 151013 151014 1 0.04 2 out/runs.jsonl   # same run, raw result only
python scripts/tighten.py 13 1      # exact SLSQP tightening of the best raw run in out/ -> 2.956145158

• src/cubes/sim3x.js - Nakajima's sim3.js with two additions: a noise multiplier (nz) and remelt() (warm start from a finished packing).
• src/cubes/exact3.py, verify.py, certify_exact.py, scripts/make_claim.py - Nakajima's, unchanged.
• scripts/remelt.js, scripts/insert.js - the two new search moves.
• scripts/render13pv.py - the video (PyVista frames with a real depth buffer, then ffmpeg). scripts/render13.py is the older matplotlib version.

Method, simulator, exact solver and checkers: Yohei Nakajima (repo, MIT). The n = 13 runs, re-melt and insert moves, video: @BuilderOfAgents, built with Claude Code.