/loop vs /goal in Claude Code: The Real Difference

Summary:

1. /goal is the self-correcting loop that fixes code; /loop is a scheduler that polls.
2. /goal converges on a measurable condition, checked by a small evaluator reading the transcript.
3. /loop re-runs a prompt on an interval and never reaches a finish line.
4. Reference card placing subagents, agent teams, workflows, and ultracode on the same loop.

The Claude Code /loop vs /goal distinction is the single most expensive piece of vocabulary to get wrong, because the two commands look alike and do opposite jobs. Someone on the Claude Code forum typed out what everyone was too proud to say: “all I know is I am ultra confused.” He’d read three explanations and they contradicted each other. You’re not behind. The terminology genuinely is a mess. Here is each term in its place, starting with the one that matters.

What’s the difference between /loop and /goal?

/goal keeps working until a condition you write is true; /loop re-runs a prompt on a schedule and never converges. That single difference is the whole thing, and mixing them up is how people point a timer at their codebase and wait all night for a fix that was never coming.

If you take one mechanical fact from all of this, take this: the command that makes an agent fix your code until it’s right is /goal, not /loop. /loop is a genuinely useful scheduler, and you’ll use it, but it polls. Point a /loop at your code expecting a fix and it’ll dutifully re-run your prompt on a timer while nothing ever converges.

What does /goal actually do?

/goal takes a turn, checks whether your condition holds, and either takes another turn or stops. You give it a condition, and after every turn a small, fast, cheap model reads what just happened and answers one question: is the condition true yet? If yes, the goal clears and you get control back. If no, the agent takes another turn.

/goal the failing test in test/auth passes (npm test exits 0) and lint is clean

Now the part that trips everyone: the evaluator judges the conversation, not your filesystem. It does not run your tests itself. It reads the transcript of what the agent did and decides from that. So the condition has to be something the agent’s own output can demonstrate. Watch the difference:

# WORKS: the agent runs the test, the result lands in the transcript the evaluator reads
/goal the failing test in src/auth passes (npm test prints "0 failing")

# DOESN'T WORK: the evaluator can't read the filesystem to confirm this
/goal the auth file is correct

“Correct” isn’t something the evaluator can see, so the loop either never confirms or rubber-stamps the agent’s say-so. Write conditions the agent has to prove by running something. And bound it, because a condition can run a long time if something’s wrong:

/goal the failing test in test/auth passes and lint is clean, or stop after 20 turns

This pattern is not a novelty someone tweeted. Anthropic’s engineering writing describes it directly as the evaluator-optimizer:

“In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.”

(Source: Anthropic, “Building effective agents”.)

/goal is that pattern, productized: a loop that runs until a small validator model confirms it’s done.

What is /loop for, then?

/loop is the heartbeat: it does a thing on a schedule, not until a thing is finished. Where it shines is watching, the jobs that never “complete”: babysit a deploy, keep an eye on CI, shepherd open pull requests. One of Claude Code’s creators runs a stack of these, each a saved command on a clock:

/loop 5m  /babysit            # auto-address review, shepherd PRs to production
/loop 30m /slack-feedback     # put up PRs for feedback
/loop 1h  /pr-pruner          # close stale PRs

None of those is trying to reach a finish line. They’re maintenance, running on a clock. The moment you catch yourself wanting a /loop to “keep fixing until it’s right,” stop. That’s a /goal, and you just saved yourself a confused night.

Where do subagents, teams, workflows, and ultracode fit?

They’re the other four words people pile into the same fog, and each has one job. Place all six on the generate-verify-decide-exit cycle and the confusion dissolves. Keep this card:

/goal        : a CONDITION-LOOP. Keeps working until a checker confirms the condition. THE loop mechanic.
/loop        : a SCHEDULER. Re-runs a prompt on an interval. Polls; never converges on a pass condition.
subagents    : workers the loop dispatches (the Agent tool); they report back. Can't spawn their own.
agent teams  : peer sessions that message each other + share a task list. Experimental, off by default.
workflows    : a SCRIPT holds the plan, so no single context holds it all (16 concurrent / 1,000 total caps).
ultracode    : a SETTING, not a product. Top effort + workflow orchestration.

The center of the diagram is the loop itself: generate a change, verify it with a check, decide from the result, then exit when the condition holds or repeat. /goal lives on the decide step (it sets the exit condition). /loop sits outside the cycle as the scheduler that can restart the whole thing. Subagents do work inside generate and report back. Agent teams are peers that argue with each other. Workflows move the plan into a script when it’s too big for one agent’s head. And ultracode is the setting that turns workflow orchestration on. That’s the entire secret behind the word that spawned a hundred confused threads.

What should you actually do?

• If you want code fixed until a check passes → use /goal with a runnable condition (npm test exits 0) and a turn clause (or stop after N turns). Never /loop.
• If you want something watched on a schedule → use /loop with an interval and a saved command. Never /goal, which would stop the instant it decides the condition is met.
• If your /goal never finishes → your condition names a mood, not a fact. Rephrase it as a result the agent prints to the transcript by running a command.
• If “teams” and “workflows” still blur → ask one question: does the job break into independent pieces? Single-file edit, no. Maker-and-checker that argue, a team. A giant plan, a workflow. Many same-shaped tasks, fan out.

The bottom line

• The serious practitioners draw the /loop versus /goal line cleanly; the slogan-repeaters conflate them. That contrast is itself a tell for who’s actually shipping with these tools.
• /goal is a loop with an exit; /loop is a clock with none. “Run until done” mode is just /goal with a well-written condition, not a loop with no brakes.
• Draw the generate-verify-decide-exit cycle once, label the six terms on it, and you’ve cleared the bar that confuses most people using these tools every day.