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

# Performance

> Timeouts, queue waits, and task sizing for fast, reliable runs.

Phone tasks execute on real hardware at real-UI speed. Performance work here is not about shaving milliseconds - it is about sizing tasks correctly and setting the three timeout knobs deliberately.

## The three timeout knobs

| Knob                                                                            | Default | Max   | Governs                                                                                                 |
| ------------------------------------------------------------------------------- | ------- | ----- | ------------------------------------------------------------------------------------------------------- |
| `per_call_timeout_s` on [`phone_run_task`](/api-reference/tools/phone-run-task) | 300 s   | 900 s | How long the task may execute. Exceeding it → `terminal: "timeout"`.                                    |
| `queue_wait_timeout_s` on `phone_run_task`                                      | 60 s    | 300 s | How long the task may wait for the phone to start it. Exceeding it → `terminal: "queue_wait_exceeded"`. |
| `timeout_s` on [`phone_task_monitor`](/api-reference/tools/phone-task-monitor)  | 120 s   | 120 s | How long one monitor call waits. Expiring → `monitor_timed_out: true`; just call again.                 |

Two useful properties:

* **Paused time is free** - time spent `paused` does not count against
  `per_call_timeout_s`.
* **The monitor is not a deadline** - `monitor_timed_out: true` never affects
  the task; it exists so your client never blocks forever.

## Size tasks like functions

The biggest performance lever is task granularity:

* **One errand per task.** Small tasks finish inside the default timeout,
  stay far from the agent's action limit, and preserve progress on failure.
* **`iteration_limit` is a design signal**, not a retry candidate - the task
  exceeded the agent's action budget and must be split.
* **Chain in a session.** Several focused tasks reusing one `session_id`
  outperform one mega-task on wall clock *and* reliability, because failures
  only repeat one step. See
  [Cross-app workflows](/guides/use-cases/cross-app-workflows).

## Reduce queue contention

Each device runs one task at a time:

* Check [`phone_device_status`](/api-reference/tools/phone-device-status)
  before dispatching - an offline or busy device is wasted queue wait.
* Tasks started in the phone app hold the execution lane and keep MCP tasks
  `pending`; raise `queue_wait_timeout_s` when that is legitimate, or use a
  dedicated device for automation.
* Spread genuinely parallel workloads across multiple registered devices -
  one workflow per device.

## Keep the monitor loop lean

* Use `phone_task_monitor` as the wait primitive - one long-poll call -
  instead of hammering
  [`phone_task_status`](/api-reference/tools/phone-task-status) in a tight
  loop.
* Fetch steps incrementally: `include_steps: true` with `since_step` returns
  only new steps (screenshots, thinking) instead of the full history each
  time. Skip steps entirely when you only need the outcome.

## Prompt for speed

* Point the agent at the exact app and screen - "open WhatsApp, tab Chats" -
  so no time is spent exploring.
* Bound the ask: "first three events", "the three cheapest flights".
* Pre-answer predictable questions in the prompt ("if a dialog asks about
  notifications, dismiss it") to avoid a round-trip through
  `needs_user_control`.

## Related

<CardGroup cols={2}>
  <Card title="Task design" icon="pen-to-square" href="/guides/best-practices/task-design">
    Granularity and precision
  </Card>

  <Card title="Session management" icon="window-restore" href="/guides/best-practices/session-management">
    Devices, lanes, and parallelism
  </Card>
</CardGroup>