/goal vs /loop vs /schedule vs Ralph: Which Loop Do You Actually Need?

Claude Code has four ways to run without you: /goal, /loop, /schedule, and Ralph. From the outside they all look like "the agent keeps going." They differ in three things that decide whether the run ends well: what starts the next turn, what stops the whole thing, and how much damage a runaway can do. Pick wrong and the loop quits before the work is done, or never quits at all.

All semantics below are verified against the official docs (code.claude.com/docs, checked 2026-07-01).

The one-table version

The table settles most cases. The details below are where the failure modes hide.

`/goal` — run until a condition is provably true

/goal <condition> runs turn after turn until the condition holds. The mechanics: after each turn, a small fast model (defaults to Haiku) reads the transcript and answers yes/no. "No" comes with a reason, which becomes guidance for the next turn. Officially it is "a wrapper around a session-scoped prompt-based Stop hook."

Two properties trip people up:

1. The evaluator cannot run commands or read files. It judges only what is in the conversation. /goal the auth module is refactored is unenforceable. /goal npm test exits 0 and npx tsc --noEmit is clean — run both and show the output works, because Claude prints the proof into the transcript. 2. There is no built-in turn cap. The official pattern is to write the cap into the condition itself: ...or stop after 20 turns. Conditions max out at 4,000 characters. One goal per session. /goal alone shows status, including token spend. The evaluator's own cost bills on the fast model and is usually negligible.

Headless works too: claude -p "/goal ..." runs the whole loop in one invocation.

Pick /goal when the outcome is binary and provable from command output. get-the-build-green is the archetype; kill-flaky-tests is the harder version (exit condition: 10 consecutive green runs). More at /type/goal.

`/loop` — re-run on an interval while the session stays open

/loop 20m check CI and fix anything red re-runs a prompt on an interval. The semantics that matter:

• Session-scoped. Tasks live in the current conversation, stop when you start a new one, and survive --resume only if unexpired.
• Seven-day expiry. Every recurring task self-deletes 7 days after creation. This is deliberate: it bounds forgotten loops.
• 1-minute minimum, jittery fires. Up to 30 minutes late, or half the interval for sub-hourly. Never build a loop that assumes exact fire times.
• Self-pacing. Omit the interval and Claude picks the delay each iteration (1 min to 1 hr) based on what it saw, and can end the loop itself once the work is provably done.
• loop.md. A .claude/loop.md replaces the built-in maintenance prompt for bare /loop — your project's default loop, versioned in git.

Pick /loop when you are reacting to external change rather than converging on a state: ship-pr-until-green polls CI and pushes fixes until it is green. Browse /type/loop.

`/schedule` — runs with the laptop closed

/schedule creates a Routine: prompt + repos + connectors, executed on Anthropic-managed cloud infrastructure (research preview; Pro/Max/Team/Enterprise). One routine can have a cron schedule, an HTTPS fire endpoint, and GitHub event triggers.

Know the safety model before you rely on it: routines run with no permission prompts at all. Containment is structural instead — fresh clone per run (no local files), pushes restricted to claude/-prefixed branches by default, connector scoping, and a daily per-account run cap. Minimum schedule interval is 1 hour. Sub-hourly polling belongs in /loop, not a routine.

Pick /schedule when the job recurs on a calendar or fires on an event and does not need your machine: nightly audits, morning triage, PR-opened reviews. Examples at /type/schedule.

Ralph — brute force, fresh context every pass

The original Ralph Wiggum loop is a bash while true around claude -p "$(cat prompt.md)". Fresh context every iteration; all memory lives in files. That buys you no context rot and no 200-turn drift. It also means Ralph has no built-in stop, cap, or expiry. None. Every guardrail is yours to write: a hard MAX_ITER, a programmatic success check (never let the loop grade its own homework), and a guardrails file the agent reads at start and appends learnings to after each pass.

There is also a bashless variant — a Stop hook that re-injects the prompt each time the agent tries to end its turn: stop-hook-ralph. Same semantics, one session, same need for a hard cap. Whole family: /type/ralph.

Pick Ralph when you have a backlog of independent items, a mechanical check per item, and the willingness to build the harness. Without the harness, skip Ralph.

Does the choice affect safety? Barely.

We grade every loop published in this directory with one scorer, and the type barely predicts the grade — the scorer reads the same guardrail signals whichever command you typed, and in practice all four types average out in the same middle band. Even Ralph, the structurally scariest pattern, averages within reach of /goal. The guardrails in the prompt (exit condition, turn cap, check command, scope) set the grade, not which command you pick.

So choose the type for its mechanics: trigger, lifetime, where it runs. Put the safety work into the prompt, whichever you choose.

The 30-second decision

• Provable end state, one sitting? /goal, cap written into the condition.
• Watch something and react, this session? /loop. Remember the 7-day expiry and the jitter.
• Recurring or event-driven, laptop closed? /schedule. 1-hour minimum, no permission prompts, so scope it.
• Backlog to grind overnight, fresh context each pass? Ralph, with your own cap, or not at all.

They compose. A routine that fires on PR events can set a /goal inside the run. A Ralph iteration is a headless session that can itself carry a goal. And whichever you pick, an unattended loop should be able to tell you it finished — ConnectMyEmail gives your agent an email lane, so "notify me" is not the part of the harness you have to build.

Still unsure? Describe the job in the loop builder. It picks the loop type from your goal and exit condition and generates the harness, budgets included. Then run the result through /grade before its first unattended night.