Long-running work

Use a long-running goal for work that needs repeated analysis, changes, validation, and follow-up instead of relying on one oversized message. EvoX keeps the objective, rounds, budget, progress, and stop reason attached to the goal and shows its state in Chat or Code.

Start a goal

In Chat, Cowork, or Code, open + > Set goal, check that the Goal chip appears in the composer, then enter and send the objective. The chip applies to the next accepted message only. Normal input resumes afterward; this does not stop the running goal.

You can also enter /goal <objective>. Entering /goal alone arms goal input so the next message supplies the objective. Goal mode and plan mode are mutually exclusive: plan first, then start the goal once its completion criteria are clear.

State the outcome, scope, and verification method. Starting a goal does not expand access to files, plugins, or external services. Existing approvals, sandbox rules, and workspace boundaries still apply.

Define completion criteria

A goal should read like a completion contract so EvoX can tell when it is actually done:

For example:

Migrate the client login flow to the new authentication API while preserving behavior.
Done when the related tests pass and the project builds with strict type checking.
Scope: change only the login module and its tests; do not touch unrelated infrastructure.
Rerun the relevant checks after each change. Stop and ask before widening the scope.

/write-goal organizes an intention around an end state, observable proof, boundaries, an iteration method, and a stop rule. More specific criteria make progress easier to inspect and reduce the chance of reporting success without evidence.

Inspect and control a goal

The goal status strip shows the objective, elapsed time, rounds, and reported progress. Hover over the round information to inspect the budget and round limit. This is a view of the execution limits, not a separate budget editor.

Controls are temporarily disabled while their request is pending. The composer’s Goal chip only controls the next message; it does not pause or delete an active goal.

Achievement, a blocker, the round limit, and the token budget are distinct stopping reasons. Inspect the stopping reason and verification results. A hidden strip or a stopped run is not proof of completion.

Elapsed time and rounds are tracked in application memory. Do not rely on quitting or restarting the app to preserve this execution state. Before interrupting work, keep the completed items, verification results, and remaining tasks in the conversation so work can continue from that record.

The illustration explains the information hierarchy:

Run goals in parallel

Code includes a split-and-parallel entry point. Enter multiple sub-goals at once to create multiple independent local Code sessions. Each session has its own context and initial sub-goal, which is useful for parallel analysis, implementation, and verification.

There are important boundaries:

• The feature creates multiple Code sessions; it is not the same as remote agent dispatch.
• Check each session’s workspace source before running it. Each sub-goal does not automatically receive a separate worktree.
• Batch fan-out requires the selected directory to be a usable Git worktree; otherwise EvoX blocks the operation or reports why it cannot proceed.

Code also provides a managed task-worktree panel for creating, viewing, switching, and cleaning up task worktrees. Cleanup handles uncommitted changes and can remove the corresponding EvoX task branch when Git permits it. Fan-out provides session parallelism; worktrees provide file isolation and lifecycle management. They are separate capabilities.

Keep the machine awake and receive notifications

Supported macOS environments provide Settings > Advanced > Prevent sleep while running. Consider power and heat; shutdown, quitting the app, and lost connectivity can still interrupt local work.

Use Activity, system notifications, or pet bubbles when work needs attention. Notification delivery depends on background state, channel, and system settings. Inspect the conversation and goal state for full results; see Notifications.

Scheduled tasks versus goals

A scheduled task answers when the same work should run again. A goal answers what the next step is until an outcome is reached. They can be combined, but recurrence does not replace completion criteria. Creating a scheduled task also does not automatically create a worktree; a Code task uses the workspace selected when it was saved.

Related documentation

• Scheduled tasks
• Projects and chats
• Notifications
• Commands
• Slash commands
• Permissions

EvoX Docs · Features · Workflows