Ralph loops, and the loop guard that killed good runs

A loop that never stops.

Geoffrey Huntley's own description is two sentences: “Ralph is a technique. In its purest form, Ralph is a Bash loop.” The loop is one line. It pipes a prompt file into a coding agent, waits for it to finish, and does it again, forever.

That sounds like a way to burn money, and Huntley is candid about the defects: “the technique is deterministically bad in an undeterministic world.” The trick is that the prompt stays the same while the repository does not. Each pass starts with a clean context, reads what the last pass left behind, and pushes a little further.

According to HumanLayer's brief history of Ralph, Huntley published it in July 2025, and it went viral in the final weeks of that year. By then Anthropic had released an official plugin that installs, in VentureBeat's words, “a 'Stop Hook' inside your Claude session.” In January 2026 The Register ran the headline that Ralph lets Claude “vibe-clone commercial software for $10 an hour”.

One line in Huntley's post matters most for this story: “Ralph can be done with any tool that does not cap tool calls and usage.” Luminair has a tool that caps tool calls. We built it on purpose, and then it capped the wrong ones.

Stop the spin.

Every agent user has watched a run go in circles: the same failing command, the same edit that does not apply, the same search with nothing new. Each lap costs tokens and time, and nothing changes. On 29 August 2026 Luminair added a tool-loop honesty card: if a run called the same tool with the same input six times in a row, a Solace card said it might be stuck and suggested pressing Stop.

Later Solace gained a stronger switch, Self-healing loop intercept, on by default. At three identical calls in a row it stops the run itself, shows a card and records what it saw. The idea is sound. The definition of “identical” was not.

This is how the first version decided two calls were the same:

const sig = (p.name || '') + '|' + JSON.stringify(p.input || '').slice(0, 200);

Tool name, then the first 200 characters of the input. Short commands fit easily. Long ones do not.

“Antigravity is not working.”

That was the report on the morning of 17 September, in capitals. Runs on Google's Antigravity engine were ending abruptly in the middle of real work. The engine was fine. The code comment written that day names two causes, both in the guard.

1 · Long commands that start the same way

Agents often write long one-off scripts: set up the PATH, then a node -e or python3 -c with a page of code. Three different scripts with the same setup lines look identical in their first 200 characters.

2 · A file read with no line numbers

The second cause was subtler. When Antigravity reads part of a file, its stream reports the call as view_file with only the file's path. The line range is not in the event; the comment records that this was checked against a live run. So reading lines 1 to 200, then 200 to 400, then 400 to 600 of one file arrives as three identical calls. To the guard, that was a loop. To the agent, it was reading.

The same was true of Antigravity's edit tools, which report the target file but not the change, and of a task tool polled for its status. The records from that morning, which we come back to below, contain all three.

Only repeated actions count.

The fix, made on 17 September and tightened on the 18th, moved the guard into a small pure block in renderer.js that the test suite loads and runs directly. It changes both halves of the question: what counts as the same call, and which calls are allowed to repeat.

The comment explains the read-only rule in one line: “re-reading after each edit is normal work”. An agent that edits a file and reads it back, again and again, is doing exactly what you want. A read cannot burn anything but tokens, and it is how an agent learns that the world changed, which is the whole point of Ralph.

When the guard does stop a run, it drops the rest of the stream, stops the engine, shows a card that begins “Solace self-healed:” with the tool and the count, and writes a record: the tool, the count and the call's signature.

Twenty-seven stops.

Those records live in a file in the app's data folder. The one on our main development Mac holds 27, the first from the morning of 17 September. We sorted them by what today's rules would do with each.

Two things stand out. First, nine of the twelve stops on 17 September were exactly the false positives the fix removed: file reads, task status checks and a path-only edit. None of those tools appears again after that day.

Second, the stops that remain are not all loops. Several are an agent waiting on a slow build: the same short ps or sleep-then-check command run three times while a code-signing job finishes. Each call returns the same thing because the build is not done yet. By the guard's rule that is a loop. By Ralph's logic, the world just had not changed yet. We have not changed that rule; a Mac-side wait is usually better done with a proper background job, and the card makes the stop visible.

Repetition is not the signal.

Ralph and the loop guard look like opposites, but they agree on the underlying idea. Repetition is fine when something changes between laps. Ralph makes sure it does: fresh context, a changed repository. The guard should only step in when nothing can have changed: the same action, with the same input, from a tool whose result is already known.

That is why the fix did not just raise the threshold. A higher count would still have killed a long Antigravity read, only later. The real change was to stop treating reads as actions, and to stop trusting a summary of the input instead of the input itself.

See what the guard did.

1. 1Open the Solace panel. Under Quality gates, Self-healing loop intercept is on by default. Switch it off and you get one warning card at six repeats instead of a stop at three.
2. 2When a run stops with a card that begins Solace self-healed:, it names the tool and how many times it was called with the same input. If the run was doing real work, send it again with a nudge to vary its approach.
3. 3For a long wait on a build, ask the agent to start it as a background job instead of polling it with the same command.

Checked, and not claimed.

Sources

• Geoffrey HuntleyRalph Wiggum as a “software engineer”
• HumanLayer · 6 January 2026A Brief History of Ralph
• VentureBeat · 6 January 2026How Ralph Wiggum went from 'The Simpsons' to the biggest name in AI right now
• The Register · 27 January 2026'Ralph Wiggum' loop prompts Claude to vibe-clone commercial software for $10 an hour