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

Claude Code /loop vs /goal confuses everyone. /goal is the self-correcting loop that fixes code; /loop is a scheduler that polls. Here's each in its place.

From the book: [Claude Code Loop Engineering](https://youcanbuildthings.com/books/claude-code-loop-engineering.md)

Web page: https://youcanbuildthings.com/articles/claude-code-loop-vs-goal

> **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.

![Claude Code loop vocabulary diagram placing /goal, /loop, subagents, agent teams, workflows, and ultracode around the generate-verify-decide-exit cycle](https://youcanbuildthings.com/images/articles/claude-code-loop-vs-goal/loop-vs-goal-diagram.png)

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.

| | `/goal` | `/loop` |
|---|---|---|
| What it is | A condition-loop | A scheduler |
| Stops when | A measurable condition is true | Never; it polls forever |
| Decided by | A small evaluator reading the transcript | A clock |
| Use it for | Fixing code until a check passes | Watching things (deploys, CI, PRs) |
| Converges? | Yes | No |

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"](https://www.anthropic.com/engineering/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:

```bash
/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.

## FAQ

### What is the difference between /loop and /goal in Claude Code?

/goal keeps working until a measurable condition is true, checked after each turn by a small evaluator. /loop just re-runs a prompt on a timer and never converges. The command that fixes your code is /goal; /loop is a scheduler for watching things.

### Which command makes Claude Code fix my tests automatically?

/goal. You give it a condition like 'the failing test passes (npm test exits 0)', and it takes turn after turn until the condition holds or a turn cap is hit. /loop will not do this; it polls a prompt on an interval.

### What is ultracode in Claude Code?

It's a setting that turns on workflow orchestration, not a separate product. The forum thread that asked 'what even is ultracode' had a one-word answer almost nobody gave: a setting.

---

Get the book: Claude Code Loop Engineering, $12.99 on Amazon: https://amzn.to/4ecjxtB