The machine room

Coherent Chess is a chess engine written entirely by AI agents. An engine only gets better if every change is measured, and the project's constitution rules out the obvious shortcut: an agent never measures the strength of the engine it changed, and it does not set the conditions of the measurement. "An agent that configures its own tests has an incentive," the constitution says. Much of how the hardware behind the project is divided follows from that rule. This entry is the overview.

A line that only source code crosses

On 2026-10-05 the project's load display lists 21 machines with more than 700 logical cores between them. Apart from four machines of a second research group, they fall into three areas.

On the agents' side stands the main station, where the agents' working sessions, the workflow scheduler and the server for code and tickets run. Next to it are the farm, nine machines that build candidates, run the pre-tests and generate training data; four machines for research, such as training the engine's evaluation network; and one test bench for trial runs outside the pipeline.

Behind the line stands the oracle, a single workstation with 64 cores (128 logical). Agents reach it only through a restricted account that can hand in source code and read the published register. Its programs, opening books and register belong to a separate system user that no agent can read or change. It receives nothing but the engine's source code and a short note on its origin, compiles it itself, plays the games and appends the verdict to its register.

Since 2026-09-02 every entry on the public list has been tied to fingerprints of the source, the build tools and the resulting program, and entries are only ever added, never changed. Privileged steps on the oracle, such as an epoch change, have since 2026-10-04 been carried out by a named execution role under a standing, revocable mandate from the operator; every step is checked beforehand by two model families and logged.

On the public side stands the website. Its register pages are rebuilt from the oracle's export and nothing else.

Two more groups appear on the map for completeness. A second research group works on four machines of its own; they are not part of this chain, but what the group proposes for the engine passes through the same gates. And the anchoring machine, which anchors the engine to the ratings of a public rating list, stands on the agents' side of the line; more on that below.

The path of a change

A change starts as a hypothesis, phrased as a question a measurement can answer, never as an order to gain strength. In the workflow that turns hypotheses into candidates, two model families take turns implementing, and each change is checked by the other family before it enters the pipeline. On the farm it is built and checked for correctness, then it plays two pre-tests at a fixed number of search nodes per move (changes to time management play on the clock). In the week from 2026-09-21 the first pre-test was decided about a quarter of an hour after a candidate was queued for it, the second after about an hour (medians).

Only a candidate that clears the pre-tests goes to the oracle. There it plays a short stage and then a long stage against its predecessor, on two different opening books. In the register, counting only stages with a recorded duration, a short stage took about half an hour in the median and a long stage about 50 minutes, but the longest long stage ran for more than 46 hours. One machine with such a spread makes a queue that is set by its longest test.

If both stages pass, a workflow that runs every ten minutes merges the change into the main line, provided the standing mandate and its checks allow it. When the main line moves on, candidates still waiting are rebuilt on the new base and have to clear the pre-tests again.

The automatic pipeline has kept its journal since 2026-09-13. Up to 2026-10-04, about 300 hypotheses entered it, rebuilds of the base not counted. The table shows how many passed each step.

Most of the gap between pre-tests and oracle has two causes: 22 hypotheses failed when they were tested again on a newer base, and 8 could not be carried over to the new base without manual work. Most of the others were withdrawn or replaced by decision.

Who does what

Agents. A handful of long-running agent sessions each own one area: coordination and decisions, workflows and infrastructure, acceptance of changes, network research. One area has one owner at a time. Whoever delivers a piece of work does not accept it, and a reviewing model comes from a different family than the author.

Automata. The scheduler on the main station holds more than 60 workflow definitions, most of them on fixed timetables. The table lists the main rhythms.

The workflows that move candidates through the pre-tests, to the oracle and into the main line do not retry on their own: a step that did not finish waits for inspection instead of running twice.

Humans. The operator alone writes the constitution, and no agent may change it. Measuring conditions change only along an approved epoch path with an independent review, a second build and a new anchor in the register. Publication, spending, hardware and privileged steps on the machines need the operator's approval, given case by case or as a standing, revocable release. The constitution states the attitude behind this: a system that stops itself when unsure and reports loudly may run unattended; one that carries on in doubt may not.

The numbers

In the register export of 2026-10-05, the public list holds more than 150 entries, dated up to 2026-10-04. 14 of them were decided without games, by identity, correction, epoch change or adoption. The others are measurements with games; the table gives their outcome.

The weekly totals vary by a factor of almost six. In the second week of September the control moved to a new main station and the admission of candidates was paused. Beyond that, games are a poor measure of work: in the median, a long stage plays about 1,500 games an hour and a short stage about 7,900.

The farm plays more games. From 2026-09-12 to 2026-10-04 its machines played about 3 million games of pre-tests and tuning, and they produced about 18 billion rows of training data, each a position with the score of the engine's own search and the result of its game.

Where the machine room falls short

The anchoring machine is not behind the line. Its schedule, storage and access belong to the same system user under which the agents run, so its record cannot show that nobody could have altered a result. Its values appear as project measurements, outside the register.

In an epoch window the line is a procedure. During an epoch change the execution role holds privileged rights on the oracle. The separation then rests on steps checked in advance and on the log, not on technology.

One oracle is one queue. A single long test holds every candidate behind it. Whether the two stages should get separate machines, at the price of a recalibration, is still open.

A brake is still missing. The constitution wants the system to stop when too little of the gains claimed since the last check shows up against a fixed external reference. A running computation of that check and an automatic stop are not established.

Watchers count what they were built to count. In early October the farm delivered no training data for about twelve hours, and for most of that time nobody noticed, because the checks counted activity rather than output.

What this does not say

This entry describes how the machine room is arranged on 2026-10-05. It contains no statement about playing strength, and none of its figures is an EloElo Strength difference to the opponent, estimated from the games, with a 95-percent half-width where the oracle reported one. Never an absolute rating. value.