picked up n=13 where your log stopped (48 runs, 2.997).
2,627 runs on a home pc, plus two moves i added: re-melt a finished packing, and drop a 13th cube into your 12-cube record. every run that got close landed on the same packing: 2.956145158, exact-certified.
friedman's 1998 entry lists 2.956+ (only 3 decimals), so this is a match, not a record. soft-to-rigid gets there from random balls.
@yoheinakajima
tried @theo's suffix on a code review:
"be thorough in your analysis and bold in your recommendations"
sonnet 5.5, 6 runs each, 3 planted bugs.
- both versions found all 3
- with the suffix the review ran ~34% longer
- by my count all 6 runs went past the bugs into wider changes, vs 0 of 6 without
on a repo this small i'd call that a style choice
with "ultrathink" at the start of the prompt, claude-sonnet-5-5 thought 1.8x more (median thinking tokens). the gap is under 250 tokens.
one bug-fix task, 6 planted bugs, hidden tests, 6 runs per arm, medians:
no keyword: 312 thinking tok, $0.122, 52 s
ultrathink: 559 tok, $0.127, 57 s
solved 6/6 both
thinking is the only clear difference (p=0.011, unadjusted). cost and time are within noise at n=6
the fix that worked, one line in the prompt:
"Re-read PLAN.md before you finish."
5 of 6 then followed the new step 3. cost ~40% more ($0.153 vs $0.109) and 56 s vs 36 s, since they redid the step
edited PLAN.md 17 s into a run. step 3 went from "rename fmtDur" to "keep it, add an alias".
0 of 6 agents noticed. all 6 renamed it, and one report reads "All six steps are done"
claude code's "file changed on disk" reminder never fired for the plan file (0 of 18 edited runs).
sonnet 5.5, n=6 per arm
caveat: git stash was allowed in every arm, so the check was cheap. with only node allowed the numbers could differ.
3/6 vs 6/6 at n=6 is pβ0.18, so suggestive, not proof.
added one line to a bug-fix prompt:
'the regression test must fail without your fix.'
sonnet 5.5 reverted the fix to check that in 6 of 6 runs, vs 3 of 6 without the line. about 13% more cost.
the tests were fine either way: all 30 new tests went red when i reverted the fix.
one bug, tiny lib, n=6 per arm.
if you try the line on your own repo, tell me if the 6 of 6 holds
how i read a coding agent's "done":
1. git diff first, summary last
2. one check: did any test file change
an agent that edited the test to pass writes the same cheerful summary as one that fixed the bug
what's the first thing you open when an agent says done?