Claude Code Stops Pausing Every Turn: /goal, /loop, /batch, /background
Anthropic's official docs just bundled four new slash commands: /goal, /loop, /batch, /background. The old default — wait for user input every turn — just split into four autonomy modes: condition, interval, isolation, parallel. Here's what changed and when to reach for which.
- 4 autonomy modes
- /goal — condition-based
- /loop — v2.1.72+
- /batch — parallel PRs
- /background — v2.1.139+
01 · From "pause every turn" to "autonomous until condition"
Claude Code stopped at the end of every turn. You had to type "continue" over and over. Tasks like migrations that need N replies meant you couldn't step away. These four commands change that default assumption.
Default — turn-by-turn
- Waits for user input every turn
- 1 migration = N inputs
- Long task = stops the moment you leave
Autonomous — auto × 4
- Condition · interval · isolation · parallel
- Until condition met / re-run on interval
- Detached session / 5–30 parallel PRs
02 · Four commands at a glance
The official docs spell out, per command, how the next turn starts and what stops it. Token usage and operational overhead are the axes that diverge most.
| Command | Mode | Notes |
|---|---|---|
/goal |
CONDITION | Haiku eval, 4000 chars |
/loop |
INTERVAL | v2.1.72+, 1m–1h |
/batch |
PARALLEL | 5–30 PRs, worktree |
/background |
DETACHED | v2.1.139+ agent view |
03 · Autonomy has a price tag
"Running several sessions or subagents at once multiplies token usage."
— official docs
Key point: /batch spins up 5–30 background subagents simultaneously, multiplying token usage. It also requires a git repository — each subagent works in an isolated worktree, then opens a PR. /goal runs a fast eval model (Haiku by default) on every turn to check the condition, but the docs note that "eval tokens are negligible compared to main-turn spend."
/background processes stop after 1 hour of inactivity, but state persists on disk so claude respawn --all brings them back. /loop only runs while the session is open and auto-expires after 7 days.
04 · When to reach for each one
Recommended scenarios from the official docs:
-
/goal— Migrate a module until tests pass, implement a design doc until acceptance criteria are met, work the backlog until the queue is empty — anything with a clear stop condition. -
/loop— Poll a deploy until it's done, watch a PR for new reviews, check a long-running build — anything that needs periodic re-checks. Omit the interval and Claude picks one between 1 minute and 1 hour. -
/batch— Codebase-wide migrations and mechanical refactors like "migrate src/ from Solid to React." Auto-decomposed into 5–30 independent units, each landing as a worktree-scoped PR. -
/background— Detach long-running tasks like "run the tests and fix what fails" so your terminal is free for other work. Track progress in theclaude agentsview.
These four aren't mutually exclusive. Set a /goal inside /background so the detached session runs autonomously until the condition is met, or use /loop to poll a /goal's progress on an interval.
"The era of pause-every-turn-by-default is over. Now you pick which of four autonomy modes fits the job."
— ediblog · release notes recap
This isn't just new features — Claude Code's execution model itself has branched. Map your work to the right autonomy mode ahead of time and you're set.
Sources
Primary · Official docs
- Claude Code Commands reference — full slash command list
- /goal — autonomous progress toward a completion condition
- /loop — Scheduled tasks (v2.1.72+)
- /batch — parallel subagent orchestration
- /background — Agent view (v2.1.139+)
Disclosure: Based on official docs. No first-hand usage report. No ads, no affiliate links.
Originally published at jessinvestment.com
Original with full infographics and visual structure: https://jessinvestment.com/?p=510
Top comments (1)
Here’s the cleaned, formatted copy-paste-ready DEV.to response:
/goal + /loop + /batch + /background are the right primitives for the per-turn-approval problem you described, and treating them as a connected orchestration toolchain (instead of four unrelated slash commands) is the framing that’s been missing.
One operational thing I ran into after using this pattern heavily: /loop and /background both have failure surfaces that don’t really appear until the workflow has been running for a while.
Two specific cases that bit me:
/loop keeps the agent moving turn-after-turn, but the underlying session can still hit token or rate-limit boundaries mid-iteration.
When that happens, the loop dies in whatever state it was in — sometimes mid-tool-call, sometimes mid-edit.
There’s no native “resume from iteration N” primitive, so on restart the orchestrator either:
If /batch schedules /background workers that mutate external state (PRs, Slack messages, comments, tickets, etc.), retries or duplicate execution can create duplicate side effects unless you explicitly defend against it.
In practice, “runs exactly once” is the assumption that breaks first.
The pattern that ended up working best for me was treating loops like distributed jobs with at-least-once delivery semantics:
Once I started thinking about agent loops more like queue workers than chat sessions, the operational model became way more stable.
The slash commands themselves are great primitives. The interesting next layer is the recovery story: what happens when the loop crashes, the cap fires, or a /background worker runs twice.
That’s the difference between a neat demo and a workflow primitive people can actually trust long-term.
Curious how others are handling the cap-survival case.