DeskTheory is where founder-CEOs learn to run their companies on AI leverage.

When to use /goal vs. /loop in Claude Code

Two Claude Code commands that both keep it running without you re-prompting. /goal drives one job forward, turn after turn, until a finish line you define is provably met. /loop re-runs a prompt on a timer to poll something. The test: are you pushing work to done, or watching for a change?

I had Claude Code rewrite every product description in a 40-item export last week, and I didn't want to sit there approving each turn. There are two ways to make it keep going on its own, and the first time you reach for one you will probably grab the wrong one. They look like the same tool. They are not. /goal is for getting something done. /loop is for keeping an eye on something.

Both are slash commands, the lightweight way you tell Claude Code to do a packaged thing. Both keep the session alive between prompts so you stop babysitting it. The difference is what starts the next turn, and that one difference decides which one you want.

What they are (in plain English)

/goal keeps Claude working until a condition you wrote is true. You type /goal followed by a finish line, like /goal all tests in test/auth pass and the lint step is clean, and it starts working toward it. After every turn, a separate, smaller model (it defaults to Haiku) reads the conversation and answers one question: is the condition met? A "no" comes back with a reason, and that reason becomes the instruction for the next turn. A "yes" clears the goal. It keeps going, sometimes for hours, until the finish line is true or you type /goal clear. It shipped in Claude Code v2.1.139.

/loop re-runs a prompt on a clock. You type /loop 5m check if the deployment finished and tell me what happened, and that prompt fires every five minutes. Give it just a prompt and no interval and Claude picks the gap itself each round, anywhere from one minute to an hour, based on whether anything is happening. It converts your interval to a schedule under the hood and runs until you press Esc to stop it. It's been in Claude Code since v2.1.72.

Here is the whole distinction in one line. With /goal, the next turn starts the moment the last one finishes, and it stops when a model confirms you're done. With /loop, the next turn starts when a stretch of time elapses, and it stops when you say so. One is driven by progress. The other is driven by the clock.

Why you should care as a CEO

The whole choice is one question: are you pushing work to a finish line, or watching for something to change?

Pushing to a finish line is a goal. The job has a clear "done" but you don't know how many tries it'll take to get there. Clean every row in this customer list until each one has a verified email. Rewrite all forty product pages until each is under 150 words. Work through this backlog until the queue is empty. You don't want it to run a fixed number of times. You want it to run until the end state is real, and a fresh checker confirms it.

Watching for a change is a loop. The work is happening somewhere else, on its own schedule, and you just want to be told when it shifts. Did the overnight export land yet? Is the long build done? Has the deploy gone green? You're not asking Claude to make the thing happen. You're asking it to check back every so often and report.

The expensive mistake is pointing one at the other's job. Put a /loop on work that has a finish line and it re-runs blindly on the clock, never knowing whether it's done, burning turns on a job that was finished three rounds ago. Set a /goal to poll something external and it spins, because the condition won't come true no matter how hard Claude works: the thing it's waiting on isn't Claude's to move.

One caution on goals, because it trips people up. The checker only judges what Claude has actually shown in the conversation. It doesn't go run commands or read files on its own. So write the finish line as something Claude's own output can prove ("the test command exits clean," "every row prints a verified email"), and cap it with a clause like "or stop after 20 turns" so a goal that can't be met doesn't run forever.

Where you'll see it

• The sibling decision, when the job is big enough to split across many agents at once: goal vs. dynamic workflow in Claude Code.
• What a slash command actually is, since both /goal and /loop are ones: what is a slash command.
• The scheduling idea a /loop rests on, the timer that fires a job on a cadence: what is a cron.
• When a poll needs to run unattended with your laptop closed, not just inside an open session: run autonomous workflows 24/7 with Claude Code routines.
• Both are gears in your harness, the setup that lets an agent run real work for you.

What you should do next

Take the next job you'd otherwise babysit and ask the one question before you type: am I pushing this to a finish line, or watching for it to change? Then reach for the matching command.