Goal Mode

Goal mode is the technique of handing an agent a persistent completion condition — what must be true, how success is checked, which constraints must stay intact — and letting the harness start new turns on its own until the check passes, a budget runs out, or a blocker forces escalation (OpenAI Cookbook). It trades per-step prompting for condition-checked autonomy: the operator gives up turn-by-turn control, and the quality of the written condition becomes the main lever the operator holds over cost and blast radius — with the budget cap and blocker-escalation above acting as harness-level backstops. All three major agent CLIs now ship a /goal command implementing it, with materially different evaluation mechanics.

Problem

Between a one-shot prompt and a fully scripted pipeline sits a large class of tasks — migrations with a parity check, refactors against an existing test suite, working through an issue queue — where the agent usually knows what to do next, but the harness returns control after every turn. The operator becomes the loop's clock: each "continue" costs a context switch, long tasks fragment across sittings, and the agent stops whenever it feels done rather than when the work is done.

The community's first answer was the "Ralph loop" — rerunning an agent against the same task file until success, with the filesystem as memory; Simon Willison describes Codex's /goal as OpenAI productizing exactly that pattern (Willison). Naive loops, however, re-prompt unconditionally and stop only on a counter. Goal mode adds the missing half: a stop condition tied to evidence instead of iteration count.

How to apply

1. Write the condition, not the task. The unit of a goal is a verifiable end state plus a way to check it. OpenAI's own contrast: "Improve performance" is a weak goal; a p95-latency target on a named benchmark while a correctness suite stays green is a strong one (OpenAI Cookbook).
2. Name the evidence. Codex requires completion to be verified against concrete sources — test results, benchmark output, generated artifacts, logs — rather than the model's self-reported confidence (OpenAI Cookbook). If no command or artifact can demonstrate "done," the task is not goal-shaped yet.
3. Put your own stop clause in the condition. Claude Code's docs suggest bounding the condition itself, e.g. appending "or stop after 20 turns" (Claude Code docs). Do not rely on implicit budgets — see the failure mode below.
4. Constrain the blast radius first. Run goal-mode work on a scratch branch or with read-only/limited permissions until you trust your own condition wording; an under-specified goal produces broad off-target changes because the agent keeps going until it decides it is satisfied (jdhodges.com).
5. Start and manage the goal. In Codex, /goal <objective> sets or replaces the goal, bare /goal shows status, and /goal pause, /goal resume, /goal clear manage its lifecycle; the feature is gated behind features.goals = true in config.toml, as of 2026-07-12 (use-case docs). In Claude Code, /goal takes a condition up to 4,000 characters (as of 2026-07-12), works non-interactively via claude -p "/goal ...", and an active goal survives --resume/--continue with its turn and token baselines reset (Claude Code docs).

Implementations

The comparison below is independent analysis of vendor documentation; no vendor publishes a cross-product comparison. As of 2026-07-12:

Implementation	Availability	Continuation trigger	Completion check
OpenAI Codex Goal Mode	Shipped in Codex CLI 0.128.0, released 2026-04-30 (GitHub release)	Continues only when the goal is active, the thread is idle, and no user input is queued; plan-only turns do not trigger continuation (OpenAI Cookbook)	The acting model judges its own evidence under explicit budget accounting; two prompt templates (goals/continuation.md, goals/budget_limit.md) are appended at the end of each turn to drive the continue/stop decision (Willison)
Claude Code /goal	Requires v2.1.139+ (Claude Code docs)	Next turn starts as soon as the previous one finishes, until the evaluator confirms the condition (Claude Code docs)	A separate small fast model (default: Haiku), wired as a session-scoped Stop hook, reads the condition plus the conversation and returns a yes-or-no decision; it calls no tools and sees only the transcript (Claude Code docs)
xAI Grok Build /goal	Announced 2026-06-22; requires SuperGrok or X Premium Plus, according to MarkTechPost (MarkTechPost)	Plans an approach, breaks work into a progress checklist, and executes, per the same report	Three-form verification before marking a task complete: code review, webpage inspection, script execution, according to MarkTechPost

The evaluator's placement is the substantive design difference. Codex's acting model re-checks artifacts it can regenerate; Claude Code's evaluator is an external judge — structurally an llm-as-judge pass per turn — that cannot re-run anything, so proof must already sit in the transcript.

When to use / When not to

Use goal mode when the end state is demonstrable by the agent's own output and a check already exists: migrations with a clear target and parity check, refactors backed by an existing test suite, flaky-test reproduction, burn-down of a labeled issue queue until it is empty, performance work with a measurable target, research with a defined evidence bar (OpenAI Cookbook; Claude Code docs).

Do not use it when:

• the task is a one-line edit or a quick explanation — continuation machinery is pure overhead (use-case docs);
• the work is exploratory design, architecture, or anything requiring taste or stakeholder input — there is no mechanical condition to check (jdhodges.com);
• the stop condition would be vague ("make it better") — vagueness converts directly into cost and off-target diffs (jdhodges.com);
• in Claude Code specifically, the proof cannot land in the transcript — the evaluator cannot go run the tests itself (Claude Code docs);
• the right trigger is a clock, not a condition — "check every N minutes" is interval scheduling (/loop), a different technique with different stop semantics (Claude Code docs).

Trade-offs and failure modes

Cost scales with autonomy. Even a bounded, well-specified Codex goal — a font-matching task with a defined deliverable — consumed 188,832 tokens in roughly five minutes in one independent hands-on test (reported in a review accessed 2026-07-12; jdhodges.com). The same review warns that a vague goal can burn a weekly quota, since the agent continues until it decides it is done. Treat adoption as a cost-governance decision, not just a workflow one.

The condition is a reward signal. A loosely written condition invites reward-hacking-shaped completions — the agent satisfying the letter of the check rather than the work. This is why Codex's design demands artifacts over self-reported confidence (OpenAI Cookbook), and why Claude Code routes the decision to a separate model at all (Claude Code docs). The observed failure can also break in the honest direction: in the hands-on test above, when browser tools were unavailable, the agent shipped a report stating the missing step was not performed instead of fabricating results (jdhodges.com) — one observation, not a guarantee.

Evaluator blindness. Claude Code's evaluator is deliberately non-tool-using: a "tests pass" condition holds only if the acting model actually ran the tests and the output landed in the transcript (Claude Code docs). Conditions must therefore instruct the agent to surface evidence, not merely produce it.

Goal state is a context-engineering concern. Multi-hour unattended runs accumulate transcript against the context-window and will cross context-compaction boundaries. Both vendors re-inject goal state each turn rather than trusting it to persist — Codex re-appends its continuation template every turn (Willison), Claude Code re-sends the condition to the evaluator on every check (Claude Code docs) — which makes the condition text itself the one durable artifact; keep constraints in it, not in early conversation, as a matter of context-engineering.

Variants and related

• Interval loops. Claude Code's /loop starts the next turn on a time interval rather than a condition, requires v2.1.72+, and recurring tasks expire 7 days after creation, as of 2026-07-12 (Claude Code docs). Conflating the two gets you premature stops (interval loop doing condition work) or runaway cost (unconditioned goal doing polling work).
• Auto mode is orthogonal. Permission auto-approval removes per-tool prompts within a turn; /goal removes per-turn prompts. Anthropic's docs call the two complementary (Claude Code docs).
• The Ralph loop — the community precursor: re-read the same task file, filesystem as memory, retry until success (Willison). Goal mode is the vendor-hardened version with idle-detection, budgets, and an evidence check.
• Model endurance is the floor, not the technique. Anthropic reported Claude Sonnet 4.5 sustaining 30+ hours of autonomous coding at its 2025-09-29 launch (Anthropic) — a model capability that goal-style harness features build on, not a goal mechanism itself.
• Pattern neighbors. Claude Code's design — worker acts, small external judge gates continuation per turn — is structurally an evaluator-optimizer loop; the same announcement frames Anthropic's Agent SDK around coordinating subagent workers toward a shared goal (Anthropic).