Codex and Claude Code Ship Goals: A Second Model Decides When You're Done

Most conversations with a coding agent follow the same rhythm: you ask, it works, it returns a result, and then it waits for you. That pause is the tax. On any task that takes ten attempts to get right — chasing down a flaky test, tuning a slow endpoint, migrating a hundred call sites — you become the loop. You read the output, decide it isn't done, and type "keep going" again and again.

In the past few weeks, both OpenAI's Codex and Anthropic's Claude Code shipped the same idea to kill that tax: a persistent Goal. You state a finish line once, and the agent keeps working across turns until the finish line is verifiably crossed. The twist that makes it trustworthy is subtle but important: a second, separate model decides when you're done — not the one doing the work.

1. The Real Shift: From "Ask → Wait" to "Work → Check → Continue"

A normal prompt is a single transaction. A Goal is a standing objective attached to your session. As OpenAI frames it in the Codex cookbook, this changes the work model from "ask, work, result, wait" into "work, check, continue or complete."

The mechanism is a loop with an evaluator inside it:

•The agent finishes a turn.
•A checker looks at the goal and everything the agent has surfaced so far.
•If the condition holds → the goal clears and control returns to you.
•If it doesn't → the agent immediately starts another turn, using the checker's reason as guidance.

This is built for tasks where the next step depends on what the agent learns along the way: performance optimization, bug investigation, refactors that ripple, research validation. You don't know the path in advance, but you do know the finish line — so you specify the finish line and let the agent find the path.

2. Why a Second Model Grades the Work

Here is the design decision worth stealing for your own agents. In Claude Code, after every turn, the goal condition plus the conversation is sent to a small, fast model (Haiku by default), which returns a yes/no verdict and a short reason. A "no" tells the main agent to keep working and hands it the reason as a hint. A "yes" clears the goal.

Why not let the working model grade itself? Because a model that has spent ten turns trying to fix something is motivated to declare victory. Separating the doer from the judge is a classic reliability pattern — the evaluator arrives with fresh eyes and no sunk-cost bias. Codex applies the same discipline from the opposite direction: when budgets are hit, it is instructed to summarize progress and blockers rather than declare success.

One honest limitation to internalize: the evaluator does not run commands or read files itself. It only judges what the agent has already put into the conversation. That single constraint dictates how you must write the goal.

3. How to Write a Goal That Actually Holds

Because the judge only sees the transcript, your finish line must be something the agent's own output can prove. "The code is better" is unverifiable. "npm test exits 0 and the transcript shows it" is checkable.

Weak goal: "Improve checkout performance."

Strong goal: "Reduce p95 checkout latency below 120 ms, verified by the checkout benchmark, while keeping the correctness suite green."

The strong version names four things the judge can audit. The Codex team formalizes a great goal as six elements — here they are, condensed into a checklist:

•Outcome — the end state you want.
•Verification surface — the concrete evidence: a test, a benchmark, a build exit code, an artifact.
•Constraints — what must not degrade on the way there.
•Boundaries — which tools and resources are fair game.
•Iteration policy — how to decide between attempts.
•Stop condition — when to halt and report a blocker instead of grinding forever.

In Claude Code the condition can run up to 4,000 characters, and you're encouraged to bound it with a clause like "or stop after 20 turns" so a goal can't run away. State the check explicitly ("git status is clean", "the queue is empty") — that is the sentence the evaluator is really reading.

4. Goals vs. Loops vs. Hooks — Pick the Right Trigger

A goal is not the only way to keep a session running. The distinction is simply what starts the next turn:

•Goal — the next turn starts when the previous one finishes, and stops when a model confirms the condition. Best for substantial work with a verifiable end state.
•Loop (e.g. /loop) — the next turn starts when a time interval elapses. Best for polling and periodic checks ("re-run every 5 minutes").
•Stop hook — also fires after every turn, but lives in your settings, applies to every session, and can run a deterministic script instead of a model judgment.

In fact, Claude Code's /goal is a thin wrapper around a session-scoped, prompt-based Stop hook — the productized version of a pattern power users were already hand-rolling. It also composes cleanly with auto mode: auto mode removes the per-tool approval prompt, and a goal removes the per-turn prompt. Together they let a well-scoped objective run unattended to completion.

5. Where Goals Earn Their Keep — and Where They Don't

Reach for a goal when:

•The task has a clear finish line but an uncertain path (debugging, perf tuning, migrations).
•Success is provable from the transcript: tests, benchmarks, a compile, an empty backlog.
•The work genuinely needs multiple iterations driven by what's discovered.

Skip it when:

•It's a one-off edit or a simple explanation — you want one answer and an immediate stop.
•The finish line is vague or unmeasurable ("make it nicer"). A goal with no verifiable surface just loops on vibes.

For research specifically, the Codex guidance is sharp: define your evidence standard before you start, and separate reproduced mechanics from approximate results from blocked/unverifiable from remaining uncertainty. That structure is what stops an eager agent from overclaiming — the same reason we hand grading to a second model in the first place.

Conclusion: State the Finish Line, Not the Steps

The quiet lesson across both tools is a shift in the unit of instruction. You stop micromanaging steps and start declaring outcomes with a verification surface attached — then let a doer and an independent judge run the loop between them. That is exactly how you'd delegate to a strong engineer: agree on "done," agree on how "done" is proven, and get out of the way.

If you're building your own agents, take the pattern even if you never touch these commands: make your finish lines checkable, and never let the worker be its own referee.

Reference sources:

•OpenAI Cookbook — Using Goals in Codex
•Claude Code Docs — Keep Claude working toward a goal

#AIAgents #Codex #ClaudeCode #DeveloperTools #LLM #AgenticWorkflows #SoftwareEngineering

✍️ The Author: Do Ngoc Hoan Founder of CookConnects.ca & Wizy.ca. Bridging the gap between advanced algorithms and business execution. I write for technical founders looking to scale their impact with AI and robust engineering.