Skip to main content
When you choose Goal mode in Quest, you only describe the outcome you want — Quest plans the path on its own, iterates continuously, and verifies the result. It’s a good fit for tasks that take multiple steps and where you’d rather “have a result delivered” than direct each step yourself.

​
Core capabilities

Goal-driven autonomous execution

  • You describe the goal; Quest breaks it down, plans the execution path, and keeps pushing forward without step-by-step instructions.
  • After each round, Quest evaluates the current progress and judges whether the goal is met. If not, it automatically moves on to the next iteration.

Flexible process control

  • Pause, edit the goal, or delete the task at any time during a run. Pausing preserves the full context and intermediate artifacts.
  • After you edit the goal, Quest continues against the new goal from the next round — it doesn’t reset existing progress.

​
Use cases

  • Long-running coding tasks: work with clear success criteria and a verification loop — e.g. raising test coverage, performance tuning, cross-file consistency fixes. Quest autonomously iterates and verifies until the goal is met.
  • Large-scale refactoring: code migrations, whole-repo framework upgrades, batch API replacements — tasks that can’t be planned out step by step in advance. Describe the desired end state as a Goal, and Quest plans the path and keeps iterating.

​
How to use

1

Enable Goal mode

Click the ”+” button on the input box and turn on the Goal toggle, or type /goal in the input box.
2

Describe the goal

Describe the end state you want in natural language. A goal should describe the expected result rather than specific steps — Quest plans the execution path itself.Example: /goal raise the project's test coverage above 80%
3

Autonomous execution

After you send the goal, Quest enters an autonomous execution loop:
  • A Goal progress card appears above the input box, showing the current goal and run status.
  • Quest evaluates progress after each round and continues automatically if the goal isn’t met, ending on its own once the goal is reached.
4

Manage the task during a run

The Goal progress card supports the following actions:
  • Edit: click the edit button in the top-right corner of the card to change the goal description. Editing during a run takes effect after the current round ends; editing while paused takes effect immediately.
  • Pause and resume: pausing preserves the full context and all intermediate artifacts; click resume to pick up from where it stopped.
  • Delete: deletes the current goal task and returns the conversation to a normal chat state. Files and messages already generated are not deleted.
Goal-Driven Execution runs for up to 10 turns by default and stops automatically once the limit is reached. You can raise the maximum turn budget from Settings → Integrations → Built-in Capabilities → Goal-Driven Execution to match the complexity of your task.

​
Goal vs. Spec

​
Best practices

  • Describe a verifiable end state: a good goal is “test coverage reaches 80%,” not “write some tests.” Quest needs a clear completion criterion to judge whether the goal is met.
  • Include key constraints: if there’s something you don’t want changed, say so in the goal. For example, “optimize the internal implementation without modifying the public API.”
  • Keep the scope reasonable: an overly grand goal (such as “make the whole project better”) makes it hard for Quest to stay focused. Breaking it into specific, measurable sub-goals works better.
  • Combine with scheduled tasks: long-running Goal tasks are also well suited to running overnight. Use /schedule to set up a scheduled task trigger.