Epochs 9 and 10: a proof for the clock, a rule for the load

Epoch 8 lasted about four hours. On 2026-10-09 at 22:29 UTC the oracle, the instance that decides every change to Coherent, entered epoch 9, and on 2026-10-10 at 13:08 UTC epoch 10. Neither changed the conditions under which a normal candidate plays. Epoch 9 brought a tool that in the end nobody used, and a release that a rule about machine load held up for almost an hour. Epoch 10 brought, among other things, a better version of that rule. This entry tells both stories, including the attempts that failed.

Smaller epochs, then the middle ground

On 2026-10-09 the project's owner asked to leave epoch 8 as it was, to plan everything new into later epochs, and to keep epochs smaller. The project's agents turned that into one narrow topic per epoch. The next morning the owner clarified that the aim was a middle ground: not too often, but not unmanageably large either. On the owner's request, a review by three model families judged the narrow cut too fine. The rule since then: one topic per epoch, but broader topics; parts that do not touch the measurement may be bundled, each with its own proof; never two changes that affect the measurement in the same epoch, because a drift could then not be assigned to either; and a window only once everything is prepared and checked. The same review estimated the preparation effort at about 5 agent-hours for epoch 9 and at least 9 for epoch 10.

The ninth epoch: a proof for the clock

The oracle plays both stages with an increment per move, 8+0.08 and 40+0.4 seconds. A fix that only matters when an engine has to manage a fixed number of moves per time period behaves there exactly like its predecessor: the changed code never runs. Games under the oracle's conditions can therefore never show what such a fix is worth.

Epoch 9 attached a clock proof to the existing route for fixes without a claimed gain. First, runs with a fixed number of nodes on a fixed set of positions must show no difference from the predecessor. Then a clock probe measures, for fixed positions and clock readings, the time from the command to search until the reply, at least 5 times each in fresh processes. A position counts only if the candidate stays safely within its time limit in every repetition and the predecessor misses it in every repetition; cases near the limit do not count. Then the usual test follows, which only has to show that the fix is not worse within a margin.

Normal measurements do not change with this. It still took an epoch, because the oracle's program is part of the fingerprint of the measuring conditions.

How the window for the ninth epoch went

The first version of the code was ready shortly after 18:00 UTC. The review by the other model family turned it down: it would only have run with a larger mechanism that had deliberately been left switched off. A smaller variant on the existing route was accepted at 18:55, the window package at 19:28. From 20:23 no new tests were admitted; the last run of epoch 8 finished at 21:03.

First attempt, 21:15. The first step, which only reads, stopped: the checksum of the position file did not match. The package named the checksum of the copy in the repository, not of the copy on the oracle machine; the content is the same, only a comment at the top differs. The supervising agent recorded this as its own error. Nothing had been changed.

Second attempt, 21:37. The first step stopped again. On the oracle machine there was still a proof file of a candidate withdrawn long before. Such leftovers are now listed as outdated instead of stopping the window.

Third attempt, 21:46. The first three steps passed. Before the anchor, two model families had to confirm the recorded load conditions. In the first round one family did not confirm: it was not shown that the clock probe leaves no trace in the test that follows directly. In the second round it again did not confirm. A trial on another machine had measured 2.1 per cent more nodes per second after a clock probe, with a 95 per cent interval from −1.5 to +5.8; that did not rule out an effect. So the clock proof was suspended for epoch 9. In the third round both confirmed. The anchor followed at 22:29, with the engine built twice to the same bytes.

Four stops before the release

Before the oracle measures again after a change of epoch, the load on the oracle machine is checked. The rule was: below 1 per cent on every thread. Four checks between 22:32 and 22:41 stopped with "load too high", at 1.7 to 4.2 per cent on a single thread. The cause was the oracle's own services, above all its loop, which runs every 30 seconds. Epoch 8 had passed the same rule with 0.3 per cent only because its 20-second reading fell between two passes of the loop. The rule measured the rhythm of the services, not outside load.

The 15-minute deadline for the release could no longer be met. The oracle stayed locked, as intended when something fails, and the window closed at 22:45. The owner then instructed: measure twice, 5 to 10 seconds apart, and release epoch 9. The two readings showed at most 0.7 and 2.05 per cent on a single thread. The oracle was released at 23:28. The second reading would not have passed the old rule.

The tool without a user

In the night the agents tried a second time to admit the clock proof. The other family again did not confirm and asked for a rest period after the clock proof, written into the oracle's code; that meant another epoch. At 02:53 UTC on 2026-10-10 the route of the only candidate for the clock proof was closed. A review had found that the proof separated candidate and predecessor in that case only by chance, in 2 of 4 runs, and that the case was not rare; the route for fixes requires both. The review of the epoch cut later noted that epoch 9's only named user had dropped out.

One run was measured in epoch 9: a change to the futility margin for quiet moves in the search. It passed both stages (table below). The long stage alone took about 9.6 hours.

The tenth epoch: rest, fresh load, a better rule

Epoch 10 contains, among other things, the rest period that had been asked for and a new load rule.

Rest after a passed proof. When a fix on the route for fixes without a claimed gain has passed its proof, the oracle waits 600 seconds from the end of the proof before the test starts. The value is not derived from a measurement; it adopts the existing waiting period after an anchor.

Fresh load before the first stage. After the rest the oracle measures the load on all threads for 20 seconds. After an unsuccessful reading it waits 180 seconds before trying again, with at most 3 readings. If none passes, it stops without a test.

A new load rule. It replaces "below 1 per cent on every thread". A reading passes only if it covers all 128 threads with valid values, the sum over all threads stays below 50 percentage points, that is, half a thread, no thread reaches 10 per cent, and the 1-minute load average stays below 0.5. The sum is the main measure: an outside process that keeps a thread busy shows up in it however the system spreads it across threads, while the oracle's own services stay far below it. The same rule is used before the first measurement of an epoch and before the first stage after a passed proof.

Rest period and fresh load reading follow a passed proof on the route for fixes without a claimed gain. In epoch 10 only the proof of the one clock-proof candidate was admitted for it. Since that candidate's route was closed, this part of epoch 10 does not run at present.

How the window for the tenth epoch went

From 06:04 UTC on 2026-10-10 no new tests were admitted, and the running test, the futility-margin run, was allowed to finish. The window opened at 12:43; the first three steps passed. In the first round of confirming the load conditions, both model families declined: the supervising agent had added text outside the places meant for values and cited a wrong reference, its own error. The second round used the original draft with the measured values and a corrected reference, and both confirmed. The anchor followed at 13:08, again with two identical builds.

The step that switches the services back on before the release broke off in its first line, without effect: a piece of evidence had not been transferred beforehand, again the supervising agent's own error. After the owner reset the step by hand, it went through at 13:18. The release came at 13:19, at the first attempt under the new rule: a sum of 4.1 points, at most 0.45 per cent on a single thread, a load average of 0.00. From opening the window to the release took about 36 minutes; in epoch 9, the same stretch from the opening of the third attempt took 1 hour and 42 minutes.

The first results of the tenth epoch

Three runs have finished in epoch 10. A speed-up of about 1 per cent with an unchanged search tree was rejected in the short stage; under these conditions the run did not show a gain from the speed-up. A stronger scaling of the network's evaluation by material passed both stages. So did the network fine-tuned on positions from its own games, labelled by a deeper search of its own. These tests stopped after few games; the values are rough estimates.

Epochs 9 and 10 changed little in what the oracle measures and a fair amount in how it decides when it may measure. The old load rule stopped a release because of the oracle's own rhythm. The new rule looks above all at the sum, and the release passed it at the first attempt.