Anthropic has added the /goal command to Claude Code, which keeps running a task until it’s finished. Typically, it keeps correcting an error until it’s fixed. It’s like a Ralph Wiggum Loop for adults…
Claude Code sets a completion condition and then works through iterations on its own until the condition is met. After each prompt iteration, a small, fast model (Haiku by default) reads the conversation and decides if it’s done. If so, the goal is automatically cleared. If not, it returns a brief reason to the Claude orchestrator as a guide for the next move.
The concept of an autonomous loop controlled by a verifiable condition isn’t new. Codex and OpenCode have offered something similar for longer, albeit with different mechanics. Anthropic is thus catching up to the market, but with a more elegant implementation. The evaluator is a separate model, not the main model evaluating itself.
How it works
The command is called with the condition as an argument:
/goal all tests in test/auth pass and lint is clean
Setting the goal immediately triggers the first turn (I don’t really like the Czech translation “obrátka,” so I won’t be using it for a while), and the condition itself serves as the command. An indicator ◎ /goal active appears in the status bar. After each turn, the evaluator returns a yes/no result and a brief reason, which is displayed in the status view and in the transcript.
Under the hood, /goal is an extension of the Stop hook that lives only in the current session and is evaluated via the prompt. Evaluation calls go to the small/fast model, so the token cost is negligible compared to main moves. The limit for a condition is 4,000 characters.
Key limitation: the evaluator does not call tools. It only evaluates what Claude has sent to the conversation. The condition must therefore be verifiable from what Claude produces itself—test output, exit code, Git status, number of files. It is not “run tests and check,” it is “Claude must run tests and the result must be in the transcript.”
/goal also works in non-interactive mode via claude -p and via Remote Control. With --resume, the condition is resumed, but the move and token counters are reset.
How to write a good condition
A good condition has three layers. Measurable end state: test result, exit code, empty queue, number of files. Verification method: npm test exit 0, git status is clean, ruff check . exit 0. Constraints: what must not be violated along the way, for example, “no other test file is modified”.
Adding a fuse is a necessity in practice: or stop after 20 moves. Without it, there is a risk of an infinite loop on an unfulfillable condition, where Claude pushes Sisyphus up the hill at your expense.
Bad conditions are those that the evaluator cannot determine from the transcript. Recently, a “mega prompt” has been circulating on X, where the author stuffs a multi-page template into /goal with rules like “the code looks like it’s from a well-funded startup.” Haiku cannot judge such a thing from the transcript. This content belongs in CLAUDE.md, not in the /goal argument.
Where /goal fits in the Claude Code autonomy family
/goal is the smallest member of the family. It’s worth framing it correctly so that readers don’t use it where something else should be used.
/goal | /loop | Routines | |
|---|---|---|---|
| Trigger for the next run | End of the previous turn | Time interval | Schedule, API endpoint, GitHub event |
| When it stops | Evaluator confirms the condition | Restart, exit, manually | Never (each trigger = new session) |
| Lives in | Session | Session | Anthropic cloud, persistently |
| Requires a running notebook | Yes | Yes | No |
| Configuration | Command argument | Command argument | Web UI, /schedule in CLI |
/goal is for tasks with a demonstrable end: module migration, refactoring a file under a size budget, completing a checklist in a single continuous run.
/loop is for regular checks while working on something else: deployment polling, periodic CI checks, reminders.
Routines are for runs without your laptop: nightly issue triage, responding to open PRs with a custom review checklist, responding to monitoring alerts via a POST request, porting changes between SDKs after each merge.
These three layers combine. A routine running every night at 8 PM sets /goal go through all PRs from last night against the checklist until none remain unprocessed in the prompt, and during that run, /loop 1m check CI status polls long-running jobs. Three layers, three different triggers, one result. It’s the first cohesive agent stack in Claude Code that holds everything together.
What /goal doesn’t solve
The evaluator is only as good as Haiku’s ability to read the transcript. During long runs with context compaction, there’s a risk that the evaluator will lose track of the evidence Claude is referencing. /goal will loop if Claude repeatedly encounters an error it cannot fix; without a fuse in the condition, it keeps running.
The function requires a workspace with a accepted trust dialog (the Stop hook is part of the hooks system). If an organization has disableAllHooks: true in its managed policy, /goal is unavailable.
Routines, as a persistent layer, have their own little issues worth noting: they are in research preview, the beta API may change, commits and actions are made under your GitHub identity (a PR opened at 3 a.m. looks like you opened it), the daily cap on runs and hourly cap on GitHub events aren’t specifically quantified in the documentation, and “green status” in the run list only means that the session technically finished, not that the task succeeded.
Practical Recommendations
Start with a single short condition with an exit code. Always add a fuse for the number of turns.
The quality bar, project conventions, and stack belong in CLAUDE.md, not in the /goal argument. For a fully non-interactive run, combine /goal with auto mode—auto mode handles per-tool approvals, /goal handles per-turn continuation, and together they run without prompts.
For CI/CD, here’s the headless version:
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
Conclusion
/goal is a good implementation of a good idea that Anthropic didn’t come up with first. Codex has long operated on the principle of “until I think I’m done,” and OpenCode has its own continue-until-done mechanics. Anthropic adds a clean abstraction—a single condition as a command argument—and a separate evaluator that assesses the main model from the outside. This is more elegant than letting the main model decide whether it has completed the task itself.
With Routines, on the other hand, Anthropic filled a gap that was either missing in competing systems or addressed via external CI. The trio of /goal + /loop + Routines is the first comprehensive autonomous stack in Claude Code. The value lies not in any single component, but in the fact that these solution components fit together.
An open question remains: how will /goal and Routines handle silent failures—that is, situations where the session technically completes and the evaluator confirms the condition, but the result is incorrect. For now, it usually falls to the person who opens the report and checks where it failed. That’s correct. But it’s going to be a pain. We’ll see how we deal with it…