Goal Mode

For long-running, complex tasks, use /goal to set an explicit objective for the current session. Once set, ZCode Agent keeps iterating toward the goal: at the end of each iteration it runs an automatic goal verification — if the goal is not yet met, it continues with another round, and the task only finishes once the goal is verified as complete. Instead of repeatedly prompting "continue", you set a goal and wait for the result.

A goal is not an ordinary prompt, and not a simple auto-continue. When you type /goal, ZCode turns the objective into a session-level runtime object, maintained by the protocol and the session store — the model keeps advancing toward the same objective across a long context, while the goal's status, budget, and verification results are always recorded by the system rather than left to the model's self-assessment.

Best for work that is easy to state in one sentence but takes many rounds to finish, for example:

• "Refactor the whole module and keep the tests passing"
• "Fix all TypeScript compile errors"
• "Get this page's Lighthouse performance score above 90"

Set and manage a goal

Type /goal in the chat input (or type / and pick goal from the suggestions):

/goal <objective>         Set the session goal
/goal replace <objective> Replace the current goal
/goal pause               Pause the goal
/goal resume              Resume the goal
/goal clear               Clear the goal

Tip: make the objective specific and verifiable — e.g. "Fix all TypeScript compile errors and make pnpm test pass" — the clearer the success criteria, the more accurate each round's verification.

A goal is runtime state, not a piece of text

After you set a goal, ZCode does not forward /goal xxx to the model as plain text. It becomes a session-level goal contract that continuously tracks:

This design brings three direct benefits:

• Recoverable: goal state is maintained by the system — the desktop can keep pushing continuously, and mobile remote control can resume the same task without losing progress across devices.
• Verifiable: whether a round is complete is judged by an independent verification step and written to the timeline; failed verification is treated as not complete (failed-closed), so a confident-sounding model cannot falsely wrap up the task.
• Auditable: model-call trajectories and per-round verification results are recorded — what a long task did and what was verified is always inspectable.

What happens after setting a goal

Live tracking in the summary panel

A goal card appears in the top-right summary panel showing the goal status (active / paused / complete) along with elapsed time, total tokens, and the iteration count — you can see at a glance how long the task has been running and what it has cost.

Automatic verification each round

When an iteration finishes, the agent automatically verifies the goal:

• Goal not complete, task continues — the next iteration starts automatically; no need to prompt "continue"
• Goal complete, task finished — the task only wraps up and summarizes after verification passes

Step in anytime

A goal is not set in stone:

• Use /goal replace <new objective> to change direction without starting over
• Use /goal pause to pause, then /goal resume when you are ready to continue
• Use /goal clear when the task no longer needs a goal constraint

Combine with execution modes

Goal Mode works alongside execution modes: the goal defines when the work counts as done, while the execution mode defines how many actions need confirmation along the way. For long goal-driven tasks, pair it with Full Access or Auto Edit to minimize interruptions and keep iterations flowing.

Together with GLM-5.2: 1 + 1 > 2

GLM-5.2 answers "can the model complete long tasks"; Goal answers "how does the system drive the model to complete them continuously, reliably, and verifiably". The two are naturally complementary:

• 1M context × goal anchor: GLM-5.2 executes long tasks stably across a 1M-token context; Goal pins your objective as session-level state, so the model keeps advancing toward the same objective throughout — long context becomes more than just a bigger memory.
• Flexible effort × execution loop: GLM-5.2 adjusts thinking depth to task difficulty; Goal breaks long tasks into a continuously advancing loop via objective, iteration, nextAction, and completion verification, so deep reasoning serves complex objectives instead of being spent indiscriminately.
• Long-horizon agentic training × product-grade control loop: GLM-5.2 is trained on long trajectories, multi-turn tool calls, subtask decomposition, and environment feedback; Goal supplies the full control loop — objective setting, auto-continue, completion verification, failed-closed handling, state recovery, and trajectory auditing — releasing the model's trained abilities in a real product environment.

In one sentence: GLM-5.2 is the execution engine for long tasks; Goal is the control system. Together, it is not just "the model can work" — the system guarantees the model keeps working toward the objective and knows when to stop.

Design philosophy: the goal contract must be reliable

ZCode Goal starts from one principle: the agent may be unreliable, but the goal contract must be reliable.

Models can be swapped, devices can change, sessions can be restored, and a round can even fail — but the goal's status, budget, verification results, next action, and task boundaries should all be recorded by the system. Goal is therefore not a "memory design" but a task-execution protocol design: not to make the agent remember things like a human, but to make it a supervisable, recoverable, auditable execution unit for engineering work.

Next Steps