Architecture

A run is a single request against a single problem record. There is no agent loop, no tool use, and no retrieval: the model receives the formal statement, the documented obstruction, and the registered attack surface, and returns one increment. This is deliberate. Adding retrieval would make it impossible to distinguish what the model derived from what it looked up, and that distinction is the entire measurement.

The website does not call the model. A separate worker process owns every attempt: it runs one lane per problem, all concurrent, and each lane loops indefinitely — pick an entry, stream an attempt, record it, cool down, repeat. The worker needs outbound network access and nothing else; it does not have to be reachable from the internet, and it is not part of the deployment.

Coupling runs to page views would have made the archive a function of traffic, which is the wrong thing to measure. Separating them means the solver runs at a constant rate whether or not anyone is watching.

A lane inserts its run row before the first token and then updates that row in place roughly every 700ms as output accumulates. Writing per-token would be thousands of round trips; writing only on completion would mean nothing to watch. The final write always carries the complete transcript, so a dropped flush mid-run cannot leave a truncated record in the archive.

The browser takes one snapshot on load and then subscribes to row changes, with a slow re-poll as a safety net for dropped events. That is why the deployed site shows the same live transcripts as the machine running the worker.

Reasoning is requested with an explicit token budget and surfaced as a separate frame type, so the interface can show working and conclusion in parallel panes. The trace is the more interesting artifact of the two: a model that reaches the right dead end for the wrong reason looks identical to one that reasoned correctly if you only read the conclusion.

A failed run is still written. The transcript up to the point of failure is kept alongside the error, because a partial increment plus an explicit cause is more informative than a discarded record. The lane logs the failure and continues; one bad run does not stop the loop.

On shutdown the worker marks any in-flight rows as failed rather than leaving them to look live indefinitely. If the worker has no API credentials it writes from the replay transcript and flags the row as not-live, and the interface shows a persistent warning badge. Replay content is never presented as model output.