Tasks
The task lifecycle and what each state means
Tasks
A task is one unit of work owned by a single coding agent - typically one pull request. Each task has a prompt, a chosen model and backend, a budget ceiling, and a lifecycle you can follow on the Tasks page.
Lifecycle
A task moves through these states:
| State | Meaning |
|---|---|
queued | Accepted, waiting for a container to come up. |
running | The coding agent is active in its VM. |
review | The agent paused (usually with a PR open) and is waiting for your input. |
merged | The pull request was merged - work complete. |
failed | The agent errored out. |
cancelled | You stopped it. |
merged, failed, and cancelled are terminal. A task in review is the only one you can resume in place; see Resume from review. A terminal task can still be retried, which reuses its session storage so git state and installed packages survive.
Tasks are async-first. Launching a task returns immediately - the agent keeps running in its VM and streams output back to your browser. You can close the tab and come back; the task and its terminal history are preserved.
Subtasks and Task Documents
When the orchestrator plans multi-PR work, the Task Document holds the checkboxes and each checkbox is a subtask. Subtasks have their own status (pending, running, review, done, failed, cancelled) and the plan completes when every subtask reaches a terminal state.
Live terminal
Each agent runs a real coding CLI inside a PTY, so the Tasks page streams genuine terminal output - colors, spinners, and syntax highlighting included. The full scrollback is kept, so when an agent pauses for review you can read everything it did before deciding how to reply.