The goal loop

/review judges work you already did. The goal loop judges work it is still doing, and keeps going until the judge agrees.

You state the goal once. The coder works it. A reviewer with clean context checks the repo against that goal, returns PASS, FAIL or PARTIAL, and the loop either stops or feeds the reason back for another round.

/goal the auth middleware must reject expired tokens, with a test that proves it
/goal fix the flaky upload test --max=8
/loop migrate the config loader to zod        # alias
/goal clear                                    # drop the loop, keep this turn

Attach images to a goal the same way you attach them to a prompt: they ride along to the coder.

A round

Steps 2 and 3 run before any model sees the round. A typecheck or test failure is an automatic FAIL, so the loop never spends a reviewer call to learn the build is broken.

The reviewer gets fresh context every round, its own model slot, and its own prompt-cache lane. It judges the current state of the repo, not the diff narrative, and it re-checks that nothing it passed earlier has regressed.

When it stalls, it changes something

Feeding the same failure to the same model is how loops burn tokens. Each round changes one variable instead:

Escalation resolves against your task router and fallback chains, so the ladder spends your configured models rather than picking new ones.

When it stops

• PASS — the reviewer verified the goal. The loop closes with its summary.
• Oscillation — the same failure reason twice in a row. Two identical verdicts mean the coder is not moving, and a third round would not move it either.
• Round cap — 5 by default, --max=N per run, goalLoop.maxIterations as your default.
• Token cap — goalLoop.tokenCap, counted across coder and reviewer rounds.
• Ctrl+X — kills the loop in any phase, mid-code or mid-review.

Only a stuck loop asks you a question. It is never a routine gate between rounds.

Steering a running loop

Type while it runs. Your line folds into the next round's coder prompt instead of interrupting the turn, and prior verdicts stay in the prompt so the coder can see what it already tried. /goal clear removes the loop without killing the turn in flight.

The stand-in

A loop that blocks on ask_user at 3am is a loop that achieved nothing by morning. When you are away, the stand-in answers in your place from a fresh context, logs the decision with its rationale, and falls back to the safe path when it is not confident.

Override a stand-in decision later and the correction is remembered, so it converges toward your judgment across sessions.

Headless runs treat you as away by definition: there is no keypress to detect, so the dial alone gates it.

Where you watch it

An unbounded loop shows an ∞ marker instead of a row of empty pips.

In CI

empryo --headless --loop "the migration must be reversible and covered by a test"
empryo --headless --loop "fix the failing suite" --max-iterations 8 --json

Configuration

{
  "goalLoop": {
    "maxIterations": 5,
    "tokenCap": 2000000,
    "standIn": "conservative",
    "runtimeProbe": false
  }
}

Every round is a real coder turn plus a real reviewer run, priced into the tab's totals like any other work (cost tracking). A loop that runs its cap is five judges and four coder turns, so state a goal specific enough to converge on: "rejects expired tokens, proven by a test" converges, "improve auth" does not.

Goal loop or review-until-pass

/goal escalates models when it stalls; /review pass keeps judging the same way until the findings are gone.

Next