> ## 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; 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:

| 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={null}
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 plan allows the [VM size](/concepts/pricing-and-tiers), your billing state is in good standing, and you have enough [credits](/concepts/billing-and-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:

| 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 task's pull request was closed without merging. |
| `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).