Coding agents are increasingly able to pursue an objective without waiting for a new instruction after each step. With /goal in OpenCode 2.2.1, OpenCode, Codex CLI and Claude Code now offer comparable approaches.
The shared command hides different mechanisms. Who decides when a task is finished? What stops an agent from looping indefinitely? How can developers control the cost of autonomous work?
From a single prompt to a persistent objective
An agent can inspect a repository, edit files, run commands and fix errors. But the end of a conversation turn does not necessarily mean the work is complete. During an API migration, for example, tests may still fail, lint errors may remain, and calls to the old API may still exist after the agent reports progress.
A goal defines a success condition that remains active across turns. The agent can work, examine results, correct problems and continue while the control mechanism determines that more work is needed. This is a work loop guided by a measurable objective, not a guarantee of fully autonomous correctness.
How /goal works in OpenCode 2.2.1
Released on 29 October 2026, OpenCode 2.2.1 introduced /goal in the terminal interface (TUI) and Desktop:
/goal Fix the TypeScript errors, pass all tests
and produce a successful build.
OpenCode stores the goal in the session. When a turn finishes normally and the session is about to become idle, a review checks progress and can trigger another continuation.
| Command | Purpose |
|---|---|
/goal <objective> | Set a goal |
/goal | Check its status |
/goal pause | Pause execution |
/goal resume | Resume the goal |
/goal clear | Remove the goal |
The built-in plugin uses an experimental session-idle hook. In the initial implementation the reviewer uses the session's model and history, so reviews consume additional model resources. The implementation also pauses after three stalled rounds or 50 rounds, and in certain blocked situations. These safeguards are not a token or spending cap.
Interface limitation: the initial version supports the TUI and Desktop. opencode run does not support /goal as a slash command.
Codex: a verifiable contract
Goals are available in Codex from version 0.128.0. A persistent goal is associated with the working thread and can describe the expected result, evidence of success, constraints, allowed resources and conditions for stopping or requesting human input.
Codex can inspect available evidence such as changed files, test results, logs or benchmarks. It distinguishes an achieved goal from a task that is blocked or has exhausted its budget: reaching a resource limit does not mean the work is finished.
Claude Code: a separate evaluator
In Claude Code, /goal uses a session-scoped Stop hook. After each turn, a separate small, fast model evaluates the condition against the conversation. It can judge the goal met, not yet met or impossible; when work remains, the session can continue.
Using a smaller evaluator may cost less than repeatedly calling the main model, although actual costs depend on the configured provider and workload. The evaluator does not independently run commands or inspect files: it judges what the main agent has surfaced in the conversation. A separate evaluation is therefore not an independent technical verification.
The key differences
| Criterion | OpenCode | Codex | Claude Code |
|---|---|---|---|
| Automatic continuation | Yes | Yes | Yes |
| Mechanism | Built-in plugin and idle hook | Persistent thread state and controlled continuation | Session-scoped Stop hook and evaluator |
| Evaluation | Review using the session model in the initial implementation | Evidence-based checks within the thread | Separate fast model |
| Budget control | No dedicated token cap in the initial implementation; round and stall safeguards | Token accounting and optional budget | Token tracking and user-defined stop conditions |
| Non-interactive goal | Not via opencode run in the initial version | Depends on the supported interface and workflow | Supported with claude -p |
None of these approaches alone guarantees the quality of the resulting code.
Who decides that the work is finished?
Consider /goal Fix all failing tests. An agent could repair the implementation, but it could also remove a difficult test, weaken an assertion or bypass a check. In both cases the test suite may appear green.
A stronger goal states both the outcome and what makes it acceptable:
/goal Migrate the authentication module to the new client API.
Success criteria:
- All authentication tests pass.
- Lint and build pass.
- No calls to the old API remain.
- No tests are removed or weakened.
- Public interfaces remain compatible.
Review the final diff. If a criterion cannot be met,
explain the blocker and stop.
This provides a stronger basis for evaluating the result, without eliminating every risk.
Autonomy also multiplies model calls
Every iteration may include conversation context, command output and additional tokens. Total cost depends not only on model pricing but also on the number of iterations, context size and evaluation mechanism.
OpenCode's initial reviewer uses the session model, Claude Code uses a smaller configured model, and Codex supports goal-level token accounting and budgets. Poorly defined goals can still cause unproductive attempts in any of them. A more persistent agent is not automatically a more efficient one.
A meaningful comparison would measure success rates, regressions, iteration counts and token consumption on the same tasks. The presence of /goal alone does not show which tool performs best.
What about RouterLab?
RouterLab provides an OpenAI-compatible API and centralizes model usage and credit tracking. Its open-source wrapper-scionos documents how to connect Claude Code, Codex CLI and OpenCode to compatible RouterLab models. OpenCode also supports custom providers using OpenAI-compatible APIs.
Connecting a model is distinct from supporting a recent client feature. Check OpenCode's /goal with the exact client version, model and transport configuration in use. Credit tracking makes consumption visible, but it does not replace an execution or spending limit configured for an autonomous task.
A step forward, not autopilot
Persistent goals let developers specify an outcome, constraints and verification criteria while the agent chooses intermediate steps. The developer remains responsible for the scope and for examining the evidence.
The practical opportunity is to build workflows with a clear objective, verification method, budget and stopping condition. Comparing the tools requires measuring verifiable results, interventions, regressions and resources on equivalent tasks.
Sources and references
Try the RouterLab API
Move from the article to a real request: start a trial, get a key, and call models through an OpenAI-compatible API.