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

# Limits and usage

> Design around sandbox lifetime, concurrency, request safeguards, and usage billing.

The authenticated dashboard and `archal usage` are the source of truth for a
workspace's current balance, reserved usage, and limits.

## Lifetime

`ttlSeconds` can be reduced by plan or server policy. Read `expiresAt` and the
optional `lease` object from the response. Current API and web facade TTL
enforcement are not yet uniform, so do not publish or assume one plan-wide
maximum.

Sandboxes can also have an idle boundary. Activity and renewal do not permit a
sandbox to cross `hardExpiresAt`.

## Concurrency and request safeguards

* workspace policy limits concurrent sandboxes
* sandbox, key, and workspace request limits apply before provider proxying
* state and create bodies have bounded sizes
* `429` can include `Retry-After`
* capacity can reject new work even when a balance is positive

These controls protect the shared service. They do not replace a deliberate CI
parallelism limit.

## Enforced request limits

| Boundary                                       |      Limit |
| ---------------------------------------------- | ---------: |
| Portable sandbox-create body                   |     64 KiB |
| State or diff input                            |      2 MiB |
| Returned diff changes                          |      1,000 |
| Sandboxes returned by one list request         |        200 |
| Configurable provider-call ceiling per sandbox |    100,000 |
| Hosted lifecycle MCP request body              |    256 KiB |
| Coding-agent pairing code lifetime             | 10 minutes |

The web create facade enforces the 64 KiB body limit. The direct control plane
has a wider general request limit, but portable clients should stay within the
smaller boundary. A diff can report a larger total while returning at most
1,000 individual changes.

## Usage

Each environment begins billing when it is ready. Cold-start time and failed
provisioning are free. Runtime is \$0.10 per active environment-minute and is
prorated by the billed second.

Billing stops after durable teardown intent, expiry, or a policy stop. Physical
runtime deletion can complete afterward.

## Cost control

* create only the environments one test needs
* use one sandbox per independent test group or shard
* keep TTL close to the expected job length
* cap parallel jobs below the workspace limit
* destroy in always-run cleanup
* monitor initial CI runs before increasing parallelism

See [Pricing and usage](/pricing-usage) for the current credit offer.