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 isawaiting_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
- Run a task and watch it:
aether run. - Manage tasks individually:
aether task. - Over the API: Tasks API.