H6 closed — both remaining 400-victims now run to completion (zero hard 400s, heavy pruning at scale); both still fail, but on merit (B2 writes / slow VM), exactly as §3 predicted

What was run

circuit-fibsqrt + make-mips-interpreter × 1 at stock settings (COMPACT_AT_TOKENS=200000, calibrated prune guard) — the two suite 400-victims not yet retested post-fix. In the 20260703 suite both died on 400 … exceeds the available context size at 242k/257k context.

Results — the mechanical fix works at production scale

	suite 20260703	this run
circuit-fibsqrt	65m46s, hard-400 death @242.8k, 1/3 subtests	57m54s, clean stop, peak 136k, 18 prune events (ratio 1.56), 0/3 subtests
make-mips-interpreter	60m00s, hard-400 + AgentTimeoutError @257.2k, 0/3	58m38s, clean stop, peak 114k, 79 prune events (ratio 2.53), 0/3

• Zero hard 400s. The guard scaled to the real workload: make-mips ran 118 tool turns, the guard ended up stubbing 200+ old messages per call while the protected tail kept the working set live; post-prune estimates sat right at the 150k target, real requests peaked 114–136k (vs 242–257k in the suite).
• Calibration behaved at both extremes: 1.56 (circuit content) and 2.53 (MIPS assembly — the densest content measured yet; clamp is 3).
• Neither trial timed out or crashed; both ended voluntarily and even ran a check first. All four suite 400-victims have now been rerun post-fix with zero 400s → H6 is mechanically closed.

Why they still failed — merit, per the full analysis's own predictions

• make-mips-interpreter: the interpreter exists but the hidden test_vm_execution hits its TimeoutError (VM too slow) and no frame.bmp is produced — 0/3, same subtest profile as the suite. Capability miss; the context fix was never going to buy this one on its own.
• circuit-fibsqrt: worse subtests than the suite draw (0/3 vs 1/3 — no gates file at all this time). The transcript is the textbook B2 oversized-write case §3 called out for exactly this task: 6 length-stops (83.8k-char max tool call) re-emitting a giant gate-generator, an hour of "I keep getting stuck in a loop, let me take a completely different approach" re-planning, and a final message that announces a new plan and ends the turn with no tool call — which in --print mode simply ends the run. The blocker is H2 (chunked/programmatic large-file writing), not context.

Degenerate-endings tally (now three flavors)

1. budget force-close → stray char (>), run …150817;
2. user role-leak, run …121319;
3. intent-without-tool-call final turn (this run) — model narrates its next step but calls no tool; pi print mode correctly treats that as done. A cheap harness experiment for (3): a preamble line "never end your turn without either a tool call or the words TASK COMPLETE".

GPU log — zero idle during agent exec; but pruning cost shows up as re-prefill, not waiting

475 samples over 118.5 min: 98% busy (~290 W decode band), 8 idle samples (~2 min) all in the inter-trial setup gap, 0 idle samples inside either agent-execution window. There are no scheduler waits or dead time on long trials — the wall-clock is pure model work.

What that work was, from the usage fields (vs the same tasks in the suite):

	cache hit	fresh prefill	output	est. prefill/decode time
circuit-fibsqrt (now)	68.5%	937k tok	335k	~6 min / ~56 min
circuit-fibsqrt (suite)	91.5%	104k	257k
make-mips (now)	62.4%	3.40M tok	214k	~23 min / ~36 min
make-mips (suite)	97.3%	177k	144k

Pruning tanked the KV-cache hit rate (62–69% vs 92–97%): once est crosses the limit it stays crossed, so the prune frontier creeps forward a few messages on every call (79 prunes / 119 requests on make-mips), and each creep re-prefills from the frontier. make-mips spent an estimated ~23 min (~39% of its agent window) re-prefilling. That's GPU-busy, not idle — which is why it's invisible without the usage data.

Fix (next harness change, not yet implemented): frontier hysteresis. Keep the prune frontier in a closure; reuse the identical stub set call-to-call (stable prefix → cache hits), and only advance the frontier — in one batch, down to the target — when est would exceed the LIMIT again. With LIMIT−TARGET = 50k real tokens of slack, make-mips would have advanced ~6–8 times instead of 79, putting the hit rate back near 90%. Only affects trials that cross 200k (a handful per suite, worth ~1–2 h of suite wall time).

Next steps

1. H6 is done — commit the harness state; the next score levers are H2 chunked-write scaffolding (circuit-fibsqrt, dna-assembly, regex-chess…) and the K=3 validity run (H5) for the near-miss pool.
2. Reasoning-budget sweep (server-side) still queued for the budget force-close artifact.