Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns

When you keep an agent running in Claude Code, the hard part is not only prompt wording. If you do not design when work starts, what counts as done, and how the loop stops, you mostly buy more turns and tokens without a clear outcome.

📑Table of Contents

Why loop design matters more than prompt spam
Four loop types compared (Turn / Goal / Time / Proactive)
Goal-based /goal and how to write stop conditions
Time-based and proactive patterns (/loop, /schedule, Routines)
Quality guardrails, token control, and a practical checklist
FAQ
Summary and next actions

This guide follows Anthropic’s official post Getting started with loops, the /goal docs, and Routines / /schedule. The goal is decision support: four loop types, stop-condition writing, local versus cloud scheduling, and practical quality/cost guardrails—not a popularity-driven summary of secondary coverage.

Why loop design matters more than prompt spam

A Claude Code loop is a work cycle that repeats until a verifiable stop condition is met. Startup and shutdown are first-class design choices, not afterthoughts.

Anthropic’s guidance is deliberately conservative: start with the simplest primitive, and add structure only when you can name the trigger and the done state. The first question is not “which advanced agent stack should I enable?” It is “where am I the bottleneck?”

Prompt-by-prompt progress keeps completion judgment with the human. That is fine for short exploration. It becomes costly when humans wait on:

implement-and-fix cycles until tests pass
measurable score targets such as Lighthouse
periodic PR comment and CI cleanup
recurring triage such as feedback queues or dependency bumps

Those jobs hand off different things: a verification check, a stop condition, or a start trigger. Different handoffs map to different primitives.

Reader decision rule: pick one bottleneck task, then decide whether the human repeatedly provides verification, completion criteria, or timing.

Four loop types compared (Turn / Goal / Time / Proactive)

The four types are a design vocabulary for trigger and stop behavior, not a product catalog of separate launches.

Loop	You hand off	Trigger	Stop	Best for	Main tools
Turn-based	Verification check	User prompt	Claude judges done or needs more context	Short, irregular work	Self-checks via SKILL.md
Goal-based	Stop condition	Manual real-time prompt	Goal met or max turns	Measurable completion states	`/goal`
Time-based	Schedule trigger	Fixed/dynamic interval	Cancel or external work finishes	Periodic work / external waits	`/loop`, `/schedule`
Proactive	Full prompt (no human in real time)	Event or schedule	Per-task goal; routine until disabled	Bug triage, dependency updates, recurring ops	Above + auto mode + dynamic workflows

Source: Anthropic Getting started with loops (as of 2026).

Turn-based starts from a human prompt and continues until Claude judges completion or missing context. The official mental model is familiar: read code, edit, run tests, then let a human decide the next step. The upgrade is encoding verification in a skill—for example start the dev server, exercise the control, capture before/after screenshots, require zero console errors, and check Core Web Vitals—then fix and rerun on failure.

Goal-based hands off a measurable done state. Time-based is driven by wall-clock or external change. Proactive composes schedule/event triggers with goals and workflows so humans do not need to stay in the loop.

A key caveat: the four-type post classifies and names existing primitives; it is not a single new product launch. Prefer “which axis am I missing?” over “force everything into Proactive.”

Selection matrix:

Still exploring requirements: Turn-based + verification skill
Done is measurable (tests, score, empty queue): Goal-based (/goal)
External systems change on a cadence: Time-based (/loop or /schedule)
Recurring work without a human online: Proactive composition

Independent coverage uses a similar matrix for explore / measurable done / external cadence / unattended triage (mer.vin loops guide). Treat product limits as time-sensitive and re-check official docs before production use.

Goal-based `/goal` and how to write stop conditions

/goal keeps Claude working until a condition holds. After each turn, a small fast evaluator model (default Haiku) checks the condition. If unmet, another turn starts; if met, the goal clears. One goal is active per session; a new /goal replaces the previous one. Setting a goal starts a turn immediately because the condition is the directive.

Official use cases include migrating a module until call sites compile and tests pass, implementing a design doc until acceptance criteria hold, splitting a large file under a size budget, and draining a labeled issue backlog until empty. The shared property is that completion can be judged from results already visible in the conversation.

Effective conditions include:

One measurable end state (tests pass, build exit 0, queue empty)
An explicit check Claude will surface (npm test exits 0, git status is clean)
Constraints that matter, plus a runtime bound (max turns or time)

Official example:

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Conditions may be up to 4,000 characters. In practice, “score 90” is incomplete without a try cap and change constraints. Without bounds, ambiguous evaluation tends to spend turns and tokens.

/goal, /loop, and stop hooks differ by why the next turn starts:

Approach	Next turn starts when	Stops when
`/goal`	Previous turn finishes	Evaluator confirms condition
`/loop`	Time interval elapses	You stop it, or work is judged done
Stop hook	Previous turn finishes	Your script/prompt decides

Source: Claude Code /goal docs (as of 2026).

Auto mode alone reduces in-turn tool prompts; it does not start new turns. Pairing auto mode with /goal removes both per-tool and per-turn prompts. Critically, the evaluator does not run commands or read files independently—it judges from conversation output. If Claude never prints test results, the evaluator cannot invent them.

Requirements: an accepted workspace trust dialog. Goals are unavailable when hook systems are disabled (disableAllHooks / managed-hooks-only style settings). Re-check current docs for your session policy.

Stop-condition checklist:

End state is measurable in one sentence
Evidence is a tool result that appears in transcript
Change-scope constraints are stated
Turn or time cap is present
Vague words (“nicely”, “as much as possible”) are removed

Time-based and proactive patterns (`/loop`, `/schedule`, Routines)

A typical time-based command is:

/loop 5m check my PR, address review comments, and fix failing CI

/loop is local/session scoped. Closing the laptop, ending the session, or powering off stops it. It fits short-lived polling while you are actively working. It is a poor fit for “keep running overnight on cloud infrastructure.”

For cloud continuity, use /schedule and Routines. A Routine stores prompt, repositories, and connectors and runs on Anthropic cloud infrastructure. Triggers include schedule, API, and GitHub events. Creation paths include the web routines UI, Desktop, and CLI /schedule. Routines require paid plans with Claude Code on the web, count against a daily routine run cap separate from subscription usage, and treat one-off runs differently from recurring caps (Routines docs).

Proactive work is usually a composition: for example hourly scheduled monitoring of a feedback channel, /goal until triage/action/response is complete, dynamic workflows for parallel worktrees plus judge review, and auto mode. That pattern fits unattended recurring operations.

Operational caveats:

Dynamic workflows can spawn many agents; pilot small before scaling
Running routines faster than the watched signal changes mostly burns budget
Local /loop and cloud Routines differ in file access, minimum interval, and survival after sleep; third-party summaries of caps and jitter are useful for awareness but must be re-verified against current official docs
Research preview and plan-gated surfaces should be confirmed before production adoption

Decision boundary: if session lifetime is enough, start with /loop. If you need survival after laptop sleep, GitHub event triggers, or managed recurring runs, evaluate /schedule / Routines. When tasks have measurable done states, embed /goal inside time-based triggers so per-task stop and routine lifetime stay separate.

Quality guardrails, token control, and a practical checklist

Longer loops amplify both quality and cost. Official quality guardrails include:

Keep the codebase clean so agents follow existing patterns
Encode “good” as self-verification skills
Make framework/library docs reachable
Use a second agent for review (/code-review or GitHub Code Review)
Encode recurring failures into the system instead of only patching once

On cost, match primitive and model size to task complexity, define clear success/stop criteria, pilot dynamic workflows, prefer scripts for deterministic work, and avoid over-frequent schedules. Useful inspection commands:

/usage for skills, subagents, and MCP usage
bare /goal for condition, runtime, evaluated turns, tokens, and latest evaluator reason
/workflows for per-agent tokens and mid-run stop controls

Reader next-action checklist (run on exactly one task):

Pick one bottleneck task
Decide the handoff: verification, stop condition, or start trigger
Write one measurable stop condition with a bound
Pilot locally with /goal or /loop
Only then expand to /schedule or multi-agent workflows
Inspect /usage, then adjust interval, model, and primitive

Decision criteria:

Done is expressible as tests/score/queue → try /goal first
Timing of external change dominates → /loop
Continuity without a human session is required → evaluate /schedule later
You cannot write a stop condition yet → stay Turn-based and harden verification first

⚠️ Unbounded long loops are often a budget failure before they are a quality failure. Pair stop conditions with observation (/usage, bare /goal).

FAQ

Q1. Are the four loop types separate product launches?

No. They are axes for trigger and stop design. Prefer adding the missing axis over adopting every advanced composition at once.

Q2. How do /goal and /loop differ?

/goal is condition-driven after each turn via an evaluator. /loop is interval-driven by wall-clock timing. Use /goal when done is measurable; use /loop when external change cadence is the driver.

Q3. What happens if I close my laptop during /loop?

Local execution stops. Use /schedule / Routines when cloud continuity is required.

Q4. What happens without a stop condition?

Turns and tokens tend to grow while completion stays ambiguous. Add measurable criteria and a turn/time cap.

Q5. What should I start with?

One bottleneck task, the simplest primitive, observe stalls or over-reach, then improve verification and conditions before multi-agent or high-frequency schedules.

Summary and next actions

Loop design centers on what you hand off and how you stop. Turn, Goal, Time, and Proactive give shared vocabulary; they are not a mandate to enable everything at once.

Next action: write one stop condition for one bottleneck, pilot with local /goal or /loop, record success criteria and cost, then expand carefully. Primary references:

Re-check current docs for research-preview and plan-dependent surfaces before production adoption.

Related articles:

Related new article:

Free Anthropic Academy courses for Claude Code, MCP, and Agent Skills – This published update adds current operational context for Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns.
Claude Code Setup plugin: codebase-aware hooks, MCP, skills recommendations – This published update adds current operational context for Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns.
Adversarial Verification for Claude Agents: Practical Checklist – This published update adds current operational context for Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns.
Graph vs Loop Engineering: Adoption Checklist (2026) – This published update adds current operational context for Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns.
Claude Cowork Record a Skill: Plans, Steps, Privacy Limits – This published update adds current operational context for Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns.

Author

krona23

Over 20 years in the IT industry, serving as Division Head and CTO at multiple companies running large-scale web services in Japan. Experienced across Windows, iOS, Android, and web development. Currently focused on AI-native transformation. At DevGENT, sharing practical guides on AI code editors, automation tools, and LLMs in three languages.

DevGENT about →

📚 Read Next