Progress update, 8 Sept 2026

Updates are bullet-point summaries generated with AI from my commits and build notes, then checked by me. Project articles and learning notes are written by me.

Two runs died and the machine looked like the obvious suspect at 1.7x slower than the week’s baseline. It was not. Thermal throttling: killed, the throttle bits never set across 1,470 samples. Memory pressure: killed, peak usage was lower than during a build. Throughput degradation: killed by the server’s own per-call numbers, identical to the previous session’s. What actually varied was how many tokens the model chose to emit, 1,057 to 1,483 per call, and at 3.4 tokens a second each extra hundred costs thirty seconds.
The longest call that survived took 477,824 ms against a 480,000 ms ceiling. Two seconds of margin. The next one went over.
So the fix bounds the work rather than the clock: the request now carries a token cap, and a response that stops because it hit that cap raises outside the retry path, because truncation is not retryable. The same prompt under the same cap truncates again, and on this hardware that costs another ten minutes.
The timeout went to fifteen minutes, deliberately generous rather than fitted. Sizing it to the longest call observed has now been wrong three times. With a token cap as the real control, the timeout is a backstop that should almost never fire, and a tight backstop is the same mistake again.
The next batch drew the identical section that had failed, because a failed record is not a skip and nothing deprioritised it. Same source, same prompt, only the ceiling changed, and it published. A controlled test rather than a lucky one. Three of three published; median wall clock across five published runs is 954 seconds.
A previously recorded finding turned out to be wrong. “Shorter source sections produce more verbatim overlap” rested on three data points; across all seventeen records the correlation is +0.185, the opposite sign, and the three newest near-floor runs produced the lowest verbatim runs on record. The genuine worst case was a 418-word section that reached 29 against a limit of 30. It predates the finding and was missed because only three runs were compared.
The build peak was measured three times, not once: 907.6, 867.2 and 882.8 MB. A single pass would have reported 867 and been 40 MB light.
Consecutive runs accumulate heat and swap. Peaks rose 79.6 → 80.7 → 81.8 °C across one batch, with the first active soft-throttle bit ever caught on this machine in a single sample, and swap steps up at every build phase without coming back down. Small, and the only metrics with a trend rather than a steady state.
The measurement tool needed a group the service account is not in, so the two columns the whole exercise existed to collect came back as errors. Caught mid-run. Moving the sampler to a separate account produced a better design anyway: one continuous trace across consecutive runs shows accumulation that per-run traces would hide.