# Persistence and limits

Sandboxes have finite compute, memory, disk, execution time, and API capacity. Exact limits depend on the account and product plan.

## What persists

Files, configuration, and Git history belong to the sandbox. Stopping a sandbox does not delete them; deleting the sandbox does.

| Operation | Effect on the sandbox |
| --- | --- |
| `stop()` | Stops the sandbox while keeping its files and configuration. |
| `restart()` | Prepares and starts the same sandbox again. |
| `destroy()` | Permanently deletes the sandbox. |

SDK-created and SDK-forked sandboxes are ephemeral by default and can be removed automatically after becoming stale. Accounts with the required entitlement can request a persistent sandbox when creating or forking one. The sandbox policy returned by the SDK describes the retention policy that was applied.

## Resource limits

Commands, file transfers, API requests, and preparation can fail when a resource or account limit is reached. Common signals include:

- HTTP `413` when a request or payload is too large.
- HTTP `429` when a flow is rate limited.
- A disk quota error when a restored or imported project exceeds the sandbox's capacity.
- Command exit codes, timeouts, and abort signals for work that cannot complete.

Retry transient connection and rate-limit failures with backoff. Quota and payload failures require a concrete change such as reducing an archive, clearing generated files, or changing the account entitlement.

## Design bounded work

Prefer targeted file reads over downloading a project, bounded log tails over retaining an entire stream, and explicit command timeouts or abort signals for automation. Cancel streams and watchers when their consumer finishes.

Checkpoint meaningful work before builds, migrations, merges, or automated edits. Delete a sandbox only when its retained work is no longer needed.

See [Lifecycle](/docs/concepts/runtime) for lifecycle transitions and recovery guidance.