/goal vs /plan in Codex and Claude Code: When to Use Each

Aug 3, 2026 Updated Sep 16, 2026

Article cover for “/goal vs /plan in Codex and Claude Code: When to Use Each” over a pastel ringed planet and orbital lines

What you’ll learn

How to choose /plan or /goal based on whether the method is settled and sustained execution is needed
Which tasks fit or do not fit each command, plus templates for writing a Plan and a Goal
How to combine the chosen AI model, reasoning depth, usage limits, and human approval points in one workflow

Use /goal for Sustained Execution and /plan for Planning

Use /plan when the method is unresolved, and /goal when the method is settled but the work must continue across multiple turns. Method certainty and required continuity are the main selection axes. Claude Code and Codex both provide these commands, although their permission behavior and completion mechanisms are not identical, so approval points and stopping conditions must remain explicit.

By the end of this article, you will have practical criteria for answering “When should /plan design the path, and when should /goal sustain execution to completion?” in your own context.

/plan Designs the Method; /goal Sustains the Agreed Objective

A relay that resolves an uncertain approach in plan and passes completion criteria and persistence to goal

/plan asks an agent to investigate and design the method before making changes, while /goal preserves an agreed objective across multiple turns. The primary output of Plan is a reviewable execution plan; the primary output of Goal is a verified change or document.

Perspective	`/plan`	`/goal`
Question it answers	What should be done, in what order, and with which risks?	What counts as complete, and how long should execution continue?
Main phase	Investigation, option comparison, design, and impact analysis	Implementation, drafting, repeated correction, and verification
Human checkpoint	Approve direction, scope, and acceptance criteria	Approve exceptions, privileged actions, and the final result
End state	An executable, reviewed plan	A result proven by tests, metrics, counts, or artifacts
Example used alone	Compare design options without executing them	Run a routine migration whose method is already approved
Example used together	Settle the approach for complex work	Execute the approved plan to a verifiable completion condition

The commands do not compete with each other. They are most useful at different stages of the same task because they separate responsibility for planning from responsibility for execution.

/goal Defines Completion Conditions and Sustains Execution

/goal is a command that gives a coding agent an objective and stopping condition to preserve across multiple turns. Because it can keep work running longer than a normal request, it needs both a description of the work and a definition of completion.

Item	Codex	Claude Code
Main role	Attach a persistent objective to the active chat	Continue turns until a completion condition holds
Basic controls	Set, view, edit, pause, resume, and clear	Set, view, and clear
Completion decision	Codex treats the Goal text as both the first prompt and the completion criteria	A separate small model evaluates the transcript after each turn
Suitable scope	Larger than one request and smaller than a work list with no defined end	Work requiring several exchanges whose completion can be demonstrated in the conversation

Goal in Codex

In Codex, /goal <objective> sets an objective and /goal shows its status. The Goal text serves as both the first request and the criteria used to judge completion. You can edit, pause, resume, or clear it after creation. Typical uses include moving code, reorganizing its internal structure while preserving behavior, experiments, trial versions, and improvements measured against a score.[1][2]

Goal in Claude Code

In Claude Code, /goal <condition> sets a completion condition. After each turn, a small evaluator model—Haiku by default—checks the condition and starts another turn when it is not yet satisfied.[4] The command requires Claude Code v2.1.139 or later, and one Goal can be active per session.[4]

The evaluator does not read files or run commands independently. It sees only information surfaced in the conversation, so Claude needs to report test results and verification output in the transcript. /goal also leaves permissions unchanged. An operation that is not already allowed still pauses for approval.[4]

/plan Designs the Method Before Execution

Before implementation or document changes begin, /plan produces an execution plan that covers findings, options, sequence, and verification. It does not settle requirements automatically. It prepares decision material for a person to review.

Plan in Codex

In Codex, /plan switches the active chat into Plan mode. An inline request such as /plan Propose a migration plan for this service can start the planning task immediately, and the command also accepts pasted text and image attachments. It is temporarily unavailable while Codex is already working.[2]

The official reference describes its purpose as proposing an execution plan before implementation begins.[2] Provide the files, constraints, existing decisions, and open questions that the plan needs to address.

Plan in Claude Code

In Claude Code, /plan [description] enters Plan mode.[5] Claude can read files, run exploratory commands, and write a plan in this mode. It normally does not edit source files, and implementation begins only after the plan is approved and the session moves to the selected permission mode.[6]

The text-only command interface also supports Shift+Tab, while code editors and the desktop app provide a mode selector. A reviewer can request more planning or edit the proposed plan before approval.[6] If bypassPermissions—a mode that skips permission checks before an action—is available during the work, however, Plan mode’s edit blocking is not enforced. Avoid that combination when Plan is intended to provide a safety boundary.[6]

Use /plan When the Method or Trade-Offs Are Unsettled

Use /plan when collecting decisions before a change provides meaningful value. In this article, any of the following conditions makes it a candidate.

The impact is unknown: The affected files, dependencies, and existing tests need investigation
Several approaches are plausible: Architecture, structure, or migration order needs comparison
Failure is costly: The work can affect a public API, data, authentication, or claims in a published document
Human agreement is required: Product requirements, the document thesis, or protected scope needs review before execution
The work will be handed off: Another session, person, or /goal needs an executable plan with limited ambiguity

A strong Plan is more than a work list. It separates verified findings, selected and rejected options, affected files, checking methods, steps for restoring the earlier state after a problem, and questions that require a person.

Choose /goal or /plan by Method Certainty and Required Continuity

Choose between the commands according to uncertainty about the method and the need for repeated execution.

State	Recommendation	Reason
Method and completion are clear, and one turn is enough	Normal request	A mode switch adds little value
Method is unresolved, and execution is not yet needed	`/plan`	Options and impact can be reviewed
Method is approved, and repeated changes and checks are needed	`/goal`	The completion condition can persist across iterations
Method is unresolved, and execution will be long	`/plan` → approval → `/goal`	Design decisions stay separate from sustained execution
Work restarts at a time or interval	Time-triggered task or `/loop`	Time, rather than a plan or objective, triggers the next run
Work includes an action that cannot be undone	Use Plan and Goal for preparation; let a person execute	The human review boundary remains explicit

Use /goal When the Objective Is Defined and Work Must Continue

In this article, I treat work as a /goal candidate when all six conditions below are met. This is my decision checklist based on the documented behavior.

It will not finish in one normal turn: The work repeats investigation, changes, and verification
It has one objective: It does not combine unrelated requests
Its end state is measurable: Tests, exit codes, counts, scores, or another artifact (a file, report, or other deliverable) can prove completion
The verification is executable: The agent can access the required files, commands, and logs
Intermediate decisions can be delegated: Progress does not require a person to decide product requirements or design direction every turn
The run can be bounded: A turn, time, attempt, or change-scope limit can stop it

The central consideration is verifiability, not duration. Even a task that takes hours has an unstable stopping point if completion means only “make it good enough.” In contrast, a large workload becomes a stronger Goal candidate when the same tests can remain its success criterion. This is also the principle behind a self-healing loop for coding agents, where verification results drive repeated fixes.

Bilingual Sync, Prompt Iteration, and Finite Worklists Fit /goal

/goal fits work where the reason to iterate and the proof of completion are defined together.

Synchronizing bilingual documentation

/goal Synchronize the public Japanese and English documentation under docs/guide.
Completion requires no translation placeholders, matching heading, table, and code-block counts, and a passing link check.
Do not change the claims, public URLs, or publication status.
Stop and report if confidential information or non-public material is required, or if the work is incomplete after 10 turns.

This task has a reason to span multiple turns because it covers only public-facing documents and can verify structure, links, and placeholders mechanically. Stopping as soon as non-public material becomes necessary separates Goal continuation from a person’s information-governance decision.

Prompt optimization against an evaluation score

/goal Improve prompts/support.md until the evaluation suite reaches a 92% pass rate.
Run npm run eval:support after every change.
Do not modify the test data or grader.
After 20 unsuccessful attempts, summarize the failure patterns and stop.

OpenAI’s official guide includes an example that changes prompts based on evaluation results until it reaches a target score or stopping condition.[1] Keeping the grader—the mechanism that scores outputs—unchanged prevents the run from appearing successful by rewriting the evaluation standard.

Processing a work list with a defined end

/goal Review every issue labeled docs-ready and prepare either a corresponding change proposal or a blocking reason.
Do not merge, publish, or close issues.
When the target queue is empty, report the change list and unresolved items.

A finite queue and an observable empty state provide a stopping condition. Excluding external writes and publication separates long-running work from human approval.

Cases where `/goal` is unsuitable

Prefer a normal request, /plan, scheduled execution, or a human decision for the following work.

A question or small change that fits one turn: Continuation checks add little value
Subjective improvement: “Make the UI better” or “raise quality” does not define a measurable end state
A list of unrelated tasks: Priorities and decision criteria change inside one Goal
Highly confidential work: Keep work involving credentials, customer data, access controls, or production environments outside autonomous Goal continuation
Approval-centered operations: Production publication, purchases, messages, and data deletion need explicit human checkpoints
Implementation with unresolved requirements: Use /plan or a normal conversation to settle options and acceptance criteria first
Monitoring that waits between checks: /loop or a time-triggered task is a better fit when time intervals should trigger another run
Claude Code work completed only by hidden external state: The evaluator cannot decide completion unless evidence appears in the transcript

For irreversible operations in particular, divide the workflow so the Goal continues through preparation and stops before execution. Goal increases continuity; it does not expand the approved action boundary.

Cases where `/plan` is unsuitable

Use /plan to reduce uncertainty before a change. It is usually unnecessary for the following work.

A question that needs only an answer: Request the research result or explanation directly
A small change with a fixed method: Put the acceptance condition in a normal request
Requirements work without a decision owner: Plan can present options but cannot replace a business decision
A long-term direction that will not be executed now: Preserve it as a design-decision record or formal proposal instead of a Plan that exists only in one conversation
A known emergency recovery procedure: Follow the approved standard operating procedure and its stopping conditions

An excessively detailed Plan can also become difficult to update when implementation reveals new facts. Specify the sequence and verification, but avoid freezing every function-level edit before execution begins.

Templates for a strong Plan and Goal

A Plan Records Decisions, Constraints, and Verification

A strong Plan separates investigation scope, decisions, options, verification, and approval points. Explicitly withholding implementation keeps the session focused on review.

/plan Investigate and plan how to achieve [objective]. Do not make changes yet.
Review [target files, sources, and specifications].
Show the selected approach, rejected alternatives and reasons, impact, and sequence.
Use [tests, review checks, or metrics] as acceptance criteria.
Separate [permissions, publication, deletion, or requirement decisions] as human checkpoints.
Do not resolve unknowns by assumption; list them as open questions in the plan.

A Goal Records the Objective, Completion Conditions, and Stop Conditions

A strong Goal can be written with four elements: objective, verification, constraints, and stopping conditions. OpenAI’s long-running work guidance also describes a Goal with expected behavior, review criteria, constraints, and a clear definition of done as stronger than simply asking Codex to implement a plan.[1]

/goal Achieve [one objective].
Verify completion with [command, metric, count, or artifact].
Preserve [protected scope, compatibility, and permission boundary].
Stop and report when [a condition requiring human judgment] occurs.
Also stop at [a turn, time, or attempt limit].

When a plan file is involved, do not stop at “implement PLAN.md.” Keep the acceptance criteria in the Goal or in the plan itself. I find it easier to use /plan to settle the method, confirm the scope, and then switch to /goal.

Choosing an AI model and reasoning depth

Choose an AI model according to decision difficulty and the effect of a mistake, not only expected duration. effort controls how deeply AI reasons before answering. The recommendations below are my task-based interpretation of each vendor’s official guidance. The models actually available depend on the contract and product environment.

Choose Codex Models and Reasoning Depth by Uncertainty and Risk

Codex defaults to GPT-5.6 Sol at medium in the Power setting. Sol fits complex, open-ended work; Terra fits everyday implementation; and Luna fits repeatable work with a known procedure. Start with the lowest effort that meets the objective, and raise it only when you can observe a useful quality difference.[3]

Phase and task	Recommended model	Effort
Plan: Routine document structure or a narrow change	GPT-5.6 Terra	`medium`
Plan: Architecture, option comparison, or a high-risk migration	GPT-5.6 Sol	Start at `medium`
Goal: Rule-based bulk edits and finite queue processing	GPT-5.6 Luna	`low` to `medium`
Goal: Failures with an unknown cause or difficult optimization	GPT-5.6 Sol	Evaluate before raising to `high` or above

If a Goal stalls, do not jump straight to the maximum setting. First check whether the completion criteria, source context, or execution environment is missing. Raise effort only when reasoning depth is the actual constraint; this also makes cost easier to explain.

Choose Claude Code Models and Reasoning Depth by Uncertainty and Risk

Claude Code’s model configuration assigns Sonnet to daily coding, Opus to complex reasoning, and Fable 5 to the hardest and longest-running tasks. The opusplan setting uses Opus in Plan mode and switches to Sonnet for execution.[7] high is the default effort for many models, xhigh provides deeper reasoning, and max targets the hardest tasks but can overthink, so it should be evaluated before broad use.[7]

Phase and task	Recommended model	Effort
Plan: Routine document structure or a narrow change	Claude Sonnet 5	`high`
Plan: Systems design or comparison among several approaches	`opusplan` or Claude Opus 5	`high` to `xhigh`
Goal: Standard implementation, fixes, and migrations with clear verification	Claude Sonnet 5	`medium` to `high`
Goal: Long-running work with many unknowns	Claude Opus 5	`xhigh`
Goal: The most difficult long-horizon work and research-like iteration	Claude Fable 5	`high` to `xhigh`
Plan and Goal: Work that prioritizes maximum capability over cost	Fable 5 or Opus 5	Compare before using `max`

The versions behind the opus and sonnet aliases in opusplan depend on the provider. Check the resolved versions when the environment must pin a model.[7] The default Haiku evaluator is usually sufficient for Claude Code Goal. Changing ANTHROPIC_DEFAULT_HAIKU_MODEL affects not only Goal evaluation but also background functions such as conversation summarization.[4]

Manage Cost, Context, Execution Scope, and Quality as Separate Budgets

Enterprise use of AI processing units needs more management than watching the bill. I recommend separating three budgets: money and usage, information sent to AI, and the work AI may execute without another approval.

OpenAI identifies reducing requests and tokens (units of input and output information AI processes), and choosing a smaller model where accuracy can be maintained, as basic cost-optimization strategies.[8] Anthropic likewise explains that Claude Code cost varies with the model, codebase, and usage pattern, and that longer input history increases token consumption.[11] Using maximum capability by default is therefore harder to govern than escalating after comparing quality and usage on representative tasks.

Budget	Decide in `/plan`	Monitor in `/goal`	Return to a person when
Financial and usage	Baseline model, reasoning depth, and condition for using a stronger model	Usage, exchanges, attempts, and elapsed time	The approved limit is reached or a stronger model is needed
Information sent to AI	Sources to read, work scope, and decisions to preserve	Irrelevant history, duplicate sources, and conversation growth	A shortened summary cannot preserve assumptions or another job enters the conversation
Work AI may execute	Allowed changes, protected scope, and external actions	Permission increases, scope expansion, and actions that cannot be undone	Publishing, sending, deleting, purchasing, or release to a live environment is next
Quality	Acceptance criteria and required evidence	Tests, evaluations, and review findings	Criteria must change or residual risk needs acceptance

Separate product-level controls from a Goal’s own stopping conditions. OpenAI’s governance documentation treats usage analytics, usage controls, and audit records as different administration surfaces.[9] Anthropic also documents different locations for organizational spend limits and usage reporting depending on the contract and authentication method.[11] Do not rely on an administration alert alone; put turn, time, attempt, or item-count limits in the Goal itself.

If the product surface does not expose exact token counts during a session, use turns, attempts, processed items, and elapsed time as operational proxies. At the enterprise level, review usage trends by team, use case, and model. At task level, compare them with artifact acceptance rates and review findings. Lower usage does not necessarily improve total workflow efficiency if rework or human review time increases.

Design Human-in-the-Loop around events

Human-in-the-Loop (HITL) is an operating model in which a person reviews the work at predefined decision points and chooses whether to approve, revise, or stop it. Event-based review preserves continuity better than requiring a person to intervene on every turn, while still returning control when risk or budget reaches a boundary.

A sandbox (a restricted execution environment for file and network access) limits what is possible in Codex, while the approval policy (the rule for when a person must confirm an action) determines when the agent must ask.[10] In Claude Code, permissions are enforced by the product rather than the model, with allow, ask, and deny rules.[12] For either product, a prompt that says “do not” is not a substitute for organizational controls. Layer sandboxing, permission rules, and managed settings.

Risk	Example	Recommended human checkpoint
Low	Read-only research or organization of existing information	Review the evidence and artifact after completion
Medium	Reversible document or code changes	Approve the Plan, then review the diff and verification
High and confidential	Credentials, customer data, authentication or access controls, production environments	Keep the work outside Goal; use Plan only to prepare non-confidential steps and decision evidence, while a named owner controls execution
High and judgment-intensive	Legal content, public claims, or major design decisions	Review scope and evidence in Plan, then require a domain specialist to approve execution and the final result
External or irreversible	Publishing, sending, purchasing, deletion, database updates, or deployment	Let AI prepare the action; require the named owner immediately before execution

Effective HITL also names the decision owner. The requester owns the objective and priority, the domain owner owns acceptance criteria, the administrator owns data and permissions, and the reviewer checks the diff and evidence. One person can hold several roles, but the Goal should not approve its own final result.

At minimum, return control to a person for these six events.

An assumption or selected approach in the Plan no longer holds
A usage, turn, time, or attempt limit is reached
Confidential data, an unapproved external service, or broader permissions are required
The next action is publishing, sending, deleting, purchasing, updating a database, or deploying
Evidence conflicts or an acceptance criterion needs to change
The cause remains unknown after the allowed verification failures

Under this design, people review the decision-relevant diff and evidence instead of following every agent step. Ask the agent to report the stopping reason, completed items, remaining options, and usage proxies concisely.

Use /plan to Choose the Method Before /goal Sustains Execution and Verification

The most reusable sequence is Plan → human approval → Goal → event-based review → verification → final human decision. This sequence applies only to work that the organization’s information classification permits in Goal. Keep highly confidential work out of Goal and switch to a human-controlled procedure during Plan. Approving a Plan does not grant blanket authority to execute every later action. Exceptions and irreversible operations remain separate checkpoints.

Identify the requester, reviewer, objective, excluded scope, and data classification
Use /plan to investigate the current state, options, impact, risks, and verification
Put the model, three budgets, permissions, and HITL events in the Plan
Have a person approve the approach, change scope, acceptance criteria, and checkpoints
Preserve the approved Plan as a concise execution specification
Give /goal the objective, completion conditions, constraints, budgets, and run limit
Let the agent iterate on changes and verification, stopping when an event occurs
Have a person decide the exception and update the Goal or Plan before continuing
Have a person inspect the diff, evidence, and results before publication or merge

Pass only the selected approach, target files, acceptance criteria, protected scope, and stopping conditions from Plan to Goal. A concise record of decisions and reasons keeps Goal focused better than transferring the entire investigation log.

Use /plan for Argument Design and /goal for Drafting and Verification

For documents, use Plan to settle the thesis and evidence, then use Goal to align the primary draft, translation, references, and format checks. AI can support structure, drafting, revision suggestions, and format checks, while a person remains the author, editor, and publication owner.

Design the Argument and Evidence with `/plan`

/plan Plan an update to the [topic] article. Do not edit the article yet.
Review the existing primary and translated articles, related pages, and editorial rules.
State the reader question, thesis, required primary sources, and distinction from existing articles.
Design matching headings, tables, code examples, and internal links for both languages.
Separate external facts, author interpretation, and experience that requires human confirmation.
State the approved sources and data classifications, baseline model, budgets, and model-escalation condition.
Treat publication, review approval, and deletion of existing articles as human checkpoints.

During Plan review, check that the thesis fits one article, each external claim has a primary source, and the article has a distinct role. The claim-to-evidence mapping matters more than the number of sources.

Sustain Drafting and Verification with `/goal`

/goal Update the [topic] article and its translation according to the approved Plan.
Write the primary-language version first, then keep heading order, table count, and code-block count aligned.
Limit external claims to approved primary sources and match every body marker to a reference.
Do not send confidential information to an unapproved external service.
Do not change existing UI, URLs, or unrelated articles.
Completion requires aligned language diffs, consistent voice, valid internal links and references, and zero Critical findings—issues that block publication—from the required review commands.
Stop and report when evidence, author-experience confirmation, publication, or the [usage, turn, or attempt] limit requires a person.

Do not reduce the completion condition to “improve quality.” Break it into language structure, reference numbering, links, and review results. Keep human editorial judgment and confirmation of personal experience as reviews after the Goal stops, rather than pretending they are mechanical checks.

Use /plan for the Change Path and /goal for Implementation and Regression Checks

For development, use Plan to settle the specification and impact, then use Goal to iterate through small changes and verification. Defining rollback and approval boundaries during planning reduces the risk of changing the specification only to make a test pass.

Design the Change Path with `/plan`

/plan Create an implementation plan for [feature or migration]. Do not change code yet.
Inspect the relevant specification, call paths, data model, and existing tests.
Show the selected approach, alternatives, affected files, compatibility, and migration order.
Define unit, integration, type, and static-analysis checks, plus a rollback method.
State the baseline model, budgets, model-escalation condition, and role-based approval points.
Make database changes, public API changes, new dependencies, and deployment separate approval points.
Do not assume unresolved product requirements; leave them as questions.

Review acceptance criteria before implementation steps. Work that must preserve existing behavior needs both a success condition and regression tests in the same Plan.

Iterate Through Implementation and Regression Checks with `/goal`

/goal Complete [feature or migration] within the approved Plan.
Run relevant tests after each small diff, then run the full approved verification set.
Preserve the public API, existing data, and protected files.
Completion requires every acceptance criterion plus successful target tests, type checks, and static analysis.
Stop and report if execution requires a design outside the Plan, confidential information, a database change, broader permissions, an external write, or deployment.
Also stop at the [usage, turn, time, or attempt limit] and summarize unresolved causes.

If implementation invalidates a Plan assumption, do not force Goal to continue. In Codex, /goal pause can suspend the run while /plan redesigns only the affected part. In Claude Code, stop or clear Goal, update the approach in Plan mode, and then set a new completion condition.

I cover product-level selection in How I Choose Between Claude and Codex. With either command, access to the required files, commands, permissions, and verification evidence on the current product surface matters more than the product name alone.

Summary: Set the Method with /plan Before /goal Sustains Execution

Use /plan to review the method, budgets, and checkpoints, then let /goal continue the approved method to a verifiable completion condition. Document and development work that combines design decisions with sustained execution benefits from Plan → human approval → Goal → event-based review → verification → final human decision.

Check six points before starting.

Does the Plan separate the selected approach, impact, verification, and open questions?
Has a person approved the Plan and acceptance criteria?
Are financial and usage, context, and autonomous-execution budgets separate?
Does the Goal include completion conditions, protected scope, checkpoints, budgets, and a run limit?
Are HITL events and their decision owners named?
Do publication, merge, and irreversible operations remain human decisions?

Once those points are explicit, start with a normal model and effort setting. Raise capability only when planning difficulty or an execution failure demonstrates the need.

Keep one-step work and tasks that require external-impact actions before the method is agreed in ordinary interaction or human review rather than handing them to /goal.

This article is a general information summary and is not legal advice. Confirm practical decisions with a qualified specialist.

References

OpenAI, Follow a goal, ChatGPT Use Cases
OpenAI, Developer commands, ChatGPT Learn
OpenAI, Model guidance, OpenAI API Docs
Anthropic, Keep Claude working toward a goal, Claude Code Docs
Anthropic, Commands, Claude Code Docs
Anthropic, Choose a permission mode, Claude Code Docs
Anthropic, Model configuration, Claude Code Docs
OpenAI, Cost optimization, OpenAI API Docs
OpenAI, Governance, ChatGPT Learn
OpenAI, Agent approvals & security, ChatGPT Learn
Anthropic, Manage costs effectively, Claude Code Docs
Anthropic, Configure permissions, Claude Code Docs

For the latest releases and updates, check the official website and official documentation.