A vague bar
Still the number one failure, and a supervisor makes it cheaper to run for longer against one.
Observed sessions / proposed design
The upper row records earlier sessions. The lower row illustrates Relay’s design, not a paid-run result.
In plain terms
The Ratchet Loop is a build loop that keeps the best round — the champion — rather than the last one, judged blind by models that are not told which is which. It runs for days. The sessions it timed ran eight to nine hours and then ended — the window filled or the harness closed it — whatever round they were in; the next session started by re-reading everything. The method wrote a handover block (the RESUME block, one page at the top of the run’s notebook) to make that re-read short. It could not make the session longer, because no prompt can.
Relay turns the relationship round. Instead of one long session hoping to reach the next boundary — the moment a round is written to the run’s ledger, the method page’s log, one line a round, never rewritten — the run is a sequence of short sessions, each started at a boundary by a small script, each told to reach the next one and end. The script — the supervisor — is not an agent. It has no context window, reads no artifact, holds no opinion and cannot be argued with. It reads files, starts sessions, waits by process id, and does arithmetic.
The champion is still frozen by commit. The judges are still blind. The critic is still harsh. What changes is who keeps the run alive.
The hole it closes
The method page ends with a list of what the Ratchet Loop does not fix, and one entry on it is different from the others: a session shorter than the run. Seven real multi-day runs, and in none of them did one session last as long as the run. Three sessions were timed: 8h41m, 8h00m and 8h42m; the resumes after them ran 2h00m and 24m32s, each shorter because a fresh context spends its first stretch re-reading. The handover block made that re-read a page. The spec says the rest in as many words: closing this needs external automation — a supervisor that starts a fresh session per round and hands it the block. Relay is that supervisor.
What it does, round after round
One session one round
- Read the run’s ledger and handover note
- Start a fresh Grok Build session, no window
- Wait on it by process id, with a deadline — and kill a session silent for 30 minutes
- Check the files it left
- Apply your round and token limits
- again
- A fault in the record
- stop — deliver the last champion that still matches
- Three sessions that reached the model but completed no round
- stop — the hang wearing a loop
You get the same champion, by round and commit — and a run built to reach your cap rather than die at hour nine. Whether it does is the first thing a real run will measure
The session is the round
Each session is handed four facts in front of the brief — which session it is, when it started, when its deadline is, how many round lines the ledger had — and one instruction the ordinary method never gives: run exactly one round, and at its boundary end the turn. The context is fresh every round by construction. Every session is started with the harness’s cross-session memory off: Grok Build can inject prior sessions into a new one on its first turn. Judges still need independent contexts, calibration examples containing neither live candidate, and verified model provenance; a fresh session alone does not establish blindness.
The boundary is checked by a script
The method already says what a resuming context checks: the champion’s snapshot still matches, a half-finished promotion is rolled forward or cleared, the ledger only ever grew. Every one of those is a comparison between files. Until now a model performed them on itself, in a context that had just been asked to keep going. Now a script performs them after every session, and a fault stops the run, while a state the next session knows how to handle is written down and the run carries on.
A script cannot be persuaded that an orphan is the champion.
Ending a turn mid-round is refused
Three real runs ended by writing a tidy paragraph and going quiet, with the job half done, and from outside that is indistinguishable from a crash. The method’s answer was a sentence: ending a turn is ending the run. Relay makes it a control. A Stop hook — a script Grok Build runs before it lets the model end its turn — reads the record: no ledger line since the session began, a promotion left half-written, a child still running — each is refused, with the reason. It gates nothing in a session the supervisor did not start.
The brake reads the harness, not the model
The supervisor reads the harness’s token and cost reports instead of asking the model to estimate them. It checks the budget before another session and reserves the estimated cost of a typical one. This is a boundary check, not a hard billing ceiling: a session can cost more than its estimate. Missing or incomplete usage must be visible, and a cap that cannot be evaluated must not silently become an unlimited run. Keep a provider-side spending limit as well.
With a grok.com sign-in, Grok Build reports tokens but no dollar figure (observed on
grok 1.0.50, on every session). Set a token cap. A --budget-usd cap cannot be
evaluated there, so it stops the run after its first session.
Setup is checked before anything is spent
Deterministic checks with no model in them, before round 0 and before the model’s own setup probes: the kit was generated for this CLI and not the other; both hooks are registered and the folder is trusted, because an untrusted project hook is skipped in silence; the boundary hook, fired with a real payload, actually denies; Playwright and the Chromium it wants are installed, or every browser check answers “unrunnable”, which fails nothing. The supervisor refuses to start on any failure and each failure says what to do.
| Property | Ratchet Loop 4.5 | Relay |
|---|---|---|
| A session is | as long as it survives — three sessions timed: 8h00m, 8h41m, 8h42m | one round, then it ends on purpose |
| Who starts the next one | you, by pasting the line again | the supervisor, from the last ledger line |
| Ending a turn mid-round | a sentence says not to | a Stop hook refuses, with the reason |
| The boundary is checked by | the model, on itself | a script, from disk; a fault stops the run |
| The brake reads | /goal status, by the model | the harness’s own JSON spend report |
| Cross-session memory | whatever your window has set | off, on every session it starts |
| Setup is proved by | the model, at SETUP | deterministic prerequisites before round 0, then the model’s own SETUP |
| You paste | one /goal line | nothing — two commands at a shell |
| You watch | /goal status, workbench.md | gauntlet/relay/STATUS.md, workbench.md |
| Inside a round | the method | the method, unchanged |
| Measured on a paid run | earlier versions have reported multi-day runs; 4.5 is not comparatively measured | not yet — see below |
What it deliberately does not add
Ruflo, an agent meta-harness for Claude Code, was read while this was designed. Three of its ideas were taken — do what needs no judgement with no model, start sessions from a script and read spend off their JSON, audit the setup deterministically — and the rest, swarms and consensus algorithms and a memory that learns, was left where it was, with reasons, in RELAY.md §2. What that reading confirmed is that the one ingredient the Ratchet Loop lacked was the cheapest one on Ruflo’s list: a process outside the model that starts the next session.
Which edition to use
Grok Build and Claude Code both have ordinary Duel and Ratchet kits. Relay’s process supervisor currently supports Grok Build only. Changing the coding model does not change the harness: choose a model identifier your installation supports and record the resolved model and effort settings. This release does not claim a tested Claude supervisor.
Start a fresh lineage for this beta revision. Keep a run that started from an earlier beta kit intact. Updated judging rules and runtime behavior belong to a new run, starting from a named commit, rather than an old ledger whose meaning changes halfway through.
Already running a 4.4 Grok Build kit, or Relay 5.0-beta.2? On grok 1.0.50 its boundary hook can fail open under Windows PowerShell, and builder commits land outside your repository. Stop at a round boundary and apply the 4.4 field patch by hand. It changes no method rule, so the rounds you have run stay valid.
How you run it
Tick Relay under Where it runs on the generator, with Grok Build and the Duel
or the Ratchet chosen. The kit you download gains a run-kit/relay/ folder, a second
hook, and a second section for your AGENTS.md; its START-HERE.md ends
with two commands instead of a line to paste:
node run-kit/relay/bin/relay.mjs doctor node run-kit/relay/bin/relay.mjs run --once
From a shell at the repo root, not from inside Grok Build — the supervisor opens Grok
Build for you, with no window, once per round, and closes it at the boundary. Every session
the supervisor starts runs with --always-approve: nothing will wait for you to
say yes, which is the point, and also the thing to know before you start. Your window into the
run is gauntlet/relay/STATUS.md, rewritten at every boundary, beside the
workbench.md and progress.html the run keeps as always. Ctrl+C is
the pause: it stops the live session by PID, releases the lock and says so; the same
run command picks the run up from its last ledger line, never from round 0. There
is no /goal status and no /goal pause in a Relay run, because there is
no /goal.
The round and token caps from your brief are written into run-kit/relay/relay.json
and can be overridden on the command line. The defaults are there too — six hours a
session as the default deadline floor (slow recorded rounds can extend it), 600 turns,
30 minutes of silence before a session is killed as hung, 2 GB of disk
free — and a laptop that sleeps through that half hour counts as silence.
--once runs a single session and stops, which is the cheapest way to see whether a
round fits inside those before committing to a run. --dry-run prints the exact
spawn and starts nothing.
When recovery deliberately stops
A crash is not permission to forget spend or assume children exited. Each attempt
has a durable start record, full before/after file checks, and an accounting entry. Torn
accounting, incomplete usage under a configured budget, or unproved prior termination
blocks another session. Preserve the files and reconcile the recorded problem; deleting
.relay-state.json or a lock is not a recovery procedure.
Automatic landing is single-lineage only. The frozen artifact must match its commit, and the tracked working tree must be clean. Several piece champions do not establish a verified whole, so this beta refuses that checkout. On Windows, process closure cannot prove that a detached descendant exited; the beta does not provide a native process container.
What the supervisor writes down
- relay.jsonl
- One line per session, append-only: when it ran, its process id and session id, how many turns and tokens the harness reported, whether it was killed and why, which round it started at and ended at, every fault and warning the boundary check raised, and the verdict — continue, or stop and the reason.
- STATUS.md
- The window. State, champion by round and commit, sessions run, spend against your caps, the last five sessions, the last warnings. Rewritten at every boundary.
- ownership.md
- Every process the supervisor launched, by id. It terminates only what is on that list, only by id, never by name.
- sessions/
- For each session: the exact prompt it was started with, the full JSON result, the boundary check in full, the last of its stderr. When a harness fact turns out to matter, the evidence is already on disk.
What has been measured
Paid-run effectiveness remains unmeasured. The supervisor, boundary
check, stop gate and doctor are exercised by synthetic regression and adversarial tests
in relay/test/, in which a stand-in for the harness
appends honest ledger lines, appends nothing, hangs until it is killed by PID, or tampers with a
champion and is caught. That proves the mechanisms do what they say when the files look like
that. It does not prove a real round fits inside the turn cap, that the ledger-derived deadline is
sane, or that a session ends at the boundary of its own accord rather than only when the gate
holds it. Those are the first things a real run will tell you, and the supervisor’s own
ledger is laid out so that they are the first things you can read off it.
The first real run should be a bounded feasibility check. Verify that the installed Grok build fires the hooks, reports usable spend, ends at a real round boundary, and resumes from the verified record. Then compare completed artifacts at equal resources on repeated short and long briefs. Keep the benefit of automatic restarting separate from the method’s judging benefit. The comparison standard defines what would justify saying it is better than Gauntlet.
RELAY.md §12 lists what the first ten sessions will settle, in the order you will learn it — starting with whether the Stop hook ran at all, which a clean session and a hook that never loaded would otherwise report identically.
What this does not fix
The round itself
Every death inside a round — a judge that never returns, a slate that cannot show the change — is unchanged. Relay makes the round’s ending cheap. It does not make the round good.
The re-read
A fresh context reads the whole prompt every round, and the prompt is large. Relay pays that once a round rather than once a death, and writes down what it cost.
An adversary
The boundary check detects accidents. A run that wanted to hide a change from the snapshot would rewrite the snapshot too; the hook that denies that is the same hook as before, with the same open questions.