Skip to main content
A task is a unit of agent work bound to exactly one workspace VM. You start it with a prompt; an agent runs inside an isolated VM until it finishes a turn or needs your input. This page describes the states a task actually moves through.

Persisted states

A task’s persisted status is one of four values: There is no terminal “completed” state. When the agent finishes a turn successfully, the task parks back in awaiting_input — ready for your next message. A task lives across many turns this way. Starting a task is gated by an admission check: Aether confirms your plan allows the VM size, your billing state is in good standing, and you have enough credits. If a check fails, the start is refused with credits_exhausted, tier_forbids_vm_size, or billing_blocked.

Awaiting-input kinds

When a task is awaiting_input, the reason is one of three kinds. This is what drives the question-and-answer (halt/resume) flow: You resume the task by responding — see aether task respond or the respond endpoint.

Display statuses

The persisted status is the execution contract. The web app, the CLI, and usage reports surface a slightly different set of display statuses that fold in pull-request and CI outcomes:
Display statuses are presentation labels for the UI and usage filters. The persisted contract is the four states above — queued, processing, awaiting_input, errored.

Working with tasks