> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runaether.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Tasks & Lifecycle

> The persisted task states, the display statuses you see, and the awaiting-input kinds

A task is a unit of agent work bound to exactly one workspace VM. You start it with a prompt and an explicit [VM size](/concepts/pricing-and-tiers#vm-sizes); Aether initially creates the workspace at that size. If you later [resize the workspace](/guides/workspaces#updating-vm-size), its current size can differ from the task's original `vm_size`. An agent runs inside the 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:

| Status | Meaning |
| - | - |
| `queued` | The task is created and waiting to start — its prompt and any follow-up messages are queued. |
| `processing` | The agent is actively working inside the task's workspace. |
| `awaiting_input` | The agent finished a turn or paused, and the task is waiting for you. |
| `errored` | The task hit an error and stopped. |

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.

```mermaid theme={"dark"}
stateDiagram-v2
    [*] --> queued
    queued --> processing: agent starts
    processing --> awaiting_input: turn finishes / agent pauses
    processing --> errored: error
    awaiting_input --> queued: you respond
    awaiting_input --> processing: resume
    awaiting_input --> [*]
    errored --> [*]
```

Starting a task is gated by an admission check: Aether confirms your billing state is in good standing and you have enough [credits](/concepts/billing-and-credits) for the selected [VM size](/concepts/pricing-and-tiers). If a check fails, the start is refused with `credits_exhausted` 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:

| Kind | Triggered by | What it means |
| - | - | - |
| `message` | A finished turn or a user stop | The agent is idle, ready for your next message. |
| `questions` | The agent asking a question | The agent needs answers before it can continue. |
| `plan` | The agent proposing a plan | The agent wants you to approve a plan before acting. |

You resume the task by responding — see [`aether task respond`](/cli/task) or the [respond endpoint](/api-reference/v1/tasks/post-tasks-by-taskid-respond).

## Display statuses

The persisted status is the execution contract. The web app, the CLI, and [usage reports](/guides/usage) surface a slightly different set of **display statuses** that fold in pull-request and CI outcomes:

| Display status | Meaning |
| - | - |
| `running` | The agent is actively working. |
| `awaiting_input` | The task is waiting for you. |
| `awaiting_ci` | The task's pull request is waiting on CI. |
| `merged` | The task's pull request was merged. |
| `unmerged` | The agent is idle and nothing has been merged — the task's pull request is still open or was closed, or the task has no pull request at all. |
| `errored` | The task stopped on an error. |
| `archived` | The task was archived. |

<Note>
  Display statuses are presentation labels for the UI and usage filters. The persisted contract is the four states above — `queued`, `processing`, `awaiting_input`, `errored`.
</Note>

## Working with tasks

* Run a task and watch it: [`aether run`](/cli/run).
* Manage tasks individually: [`aether task`](/cli/task).
* Over the API: [Tasks API](/api-reference/v1/tasks/get-tasks).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.