Claude Code’s /goal command hands Claude a finish line instead of a single task. You give it a condition you want to be true, something like “every post on the site has an excerpt and a cover image,” and Claude keeps taking turns on its own until that condition is met. Normally you’re the one deciding when it’s done: you read the output, judge whether it’s good enough, and prompt again if it isn’t. With a goal, Claude keeps working until the condition is actually true, without waiting for you in between.

If “goal versus task” sounds like splitting hairs, the difference is who decides when to stop. A task is one prompt and one round of work, and you’re the judge of the result. A goal is a stopping condition that stays in force across as many rounds as it takes. It’s scoped to your current session though, so it’s not a standing instruction that follows you into future conversations. One goal per session, and clearing the conversation with /clear drops the goal along with it.

THE CHECKER IS AN EVALUATOR The goal checker isn’t the Claude doing the work. It’s an evaluator: a small, fast model (Haiku by default) that reads the conversation after each turn and grades it pass or fail against your condition. A fail sends Claude back to work, with the reason fed in as guidance for the next turn. The check itself costs almost nothing; the real spend is the work it keeps relaunching.

HOW TO SET A GOAL AND CLEAR IT

You set a goal by typing /goal followed by the condition you want satisfied. That kicks off a turn immediately with the condition as the instruction, so you don’t need to send a separate prompt after it.

/goal every post on the site has an excerpt and a cover image

While a goal is running, here’s what you can check and control:

  • ◎ /goal active shows while it’s running, along with how long it’s been going.
  • Type /goal on its own to see the status: the condition, how many turns it’s checked, and how many tokens it’s spent so far. That last number is the one to actually watch.
  • /goal clear stops it before the condition is met. stop, off, and cancel all work as aliases.
  • Only one goal can be active per session.
  • Starting a fresh conversation with /clear drops the goal too.

One more tip if you want a truly autonomous run: pair the goal with auto mode. A goal removes the per-turn prompts, but each turn can still stop to ask you to approve individual commands. Auto mode clears those per-command approvals within a turn, /goal clears the per-turn approvals between them, and together the loop genuinely runs unattended, with auto mode still stepping in to block anything actually dangerous.

WRITING A GREAT GOAL CONDITION: THE THREE PARTS

The natural assumption is that the goal checker can poke around your project to verify things, run the build, open files, look at the site. It can’t do any of that. The checker only sees the chat, the same back-and-forth you’ve been reading, so whatever proves your goal true has to actually show up there. “Every post has an excerpt” works because Claude checks the posts and reports what it found, and that report lands right in the conversation for the checker to read. “The site feels more polished” doesn’t work, because nothing in the chat can prove it.

You don’t need to write anything beefy. A good condition is one sentence with three parts: 1) the thing you want to be true, 2) how to prove it, and 3) when to give up. Something like “all 40 posts use the new tag format, confirmed by listing them, or stop after 20 turns.” (The proof part can stay implicit when it’s obvious: a post either has an excerpt or it doesn’t.)

Part 3, when to give up, is the one most people leave out, and it’s the most important. A goal only ends two ways: the checker says yes, or you stop it. So a goal that can’t come true just keeps going, and there are a few classic ways that happens:

  • Claude fixes one thing and breaks another, over and over.
  • The condition depends on something Claude can’t actually change.
  • The target is fuzzy, like “more polished,” so the checker never gets to a clean yes.

Any of these loops will keep burning tokens all night. “Or stop after 20 turns” is the insurance policy. It’s the same lesson as writing prompts that keep Claude calm: a vague target makes Claude guess what “done” means, and a specific one gives it something real to aim at.

WHY GOALS PLUS ULTRACODE TORCHES YOUR TOKENS

There’s a running joke that the fastest way to burn through your usage limits is pointing a goal plus ultracode at one task and walking away. It’s funny in the way that hurts, because it keeps actually happening: one developer left a goal running overnight and woke up 14 hours later to find the entire weekly token allowance on their $200 plan gone. A goal keeps relaunching the work until the condition holds, so you pay for more turns. Ultracode fans each of those turns out into a bunch of subagents working in parallel, so you pay more for each turn. Put them together and a goal that takes fifteen turns, where each turn spins up a dozen agents, adds up to a couple hundred Claude instances while you’re off doing something else.

There are jobs that justify the combo, like grinding through a big code migration until every test passes. If you take one on, for the love of bob, put a turn limit in the condition. Check the running token spend with a bare /goal now and then, and remember /goal clear works anytime the spend stops being worth it.

WHEN A GOAL IS WORTH IT

The goals that keep showing up in people’s writeups and threads mostly fall into a handful of shapes:

  • Until every test passes. The classic: fix the bug or finish the refactor, with the test suite (and a clean lint run) as the finish line.
  • Until the checklist is done. Write a plan file first, then point a goal at completing every item, so Claude can’t stop halfway through and summarize.
  • Until each one is handled. Batch work, like rewriting all 40 product descriptions until every page is under 150 words. Goals aren’t just for code.
  • Until it works end to end. Build the feature, then actually click through every part of it in the browser before calling it done.
  • Until the two systems talk to each other. Setup and migration work, like connecting a site to a new backend until a change pushes cleanly in both directions.

The best payoffs seem to come when the work is too big to babysit and the finish line is something a machine can verify. If the honest answer to “when is it done” is “when it looks good to me,” skip the goal and just keep prompting.