# How to choose a sandbox for AI agents

An agent sandbox is an isolated execution environment where an AI agent can run
programs, install dependencies and work with files. The best sandbox for a project
is the one that completes its real jobs safely, reliably and at an acceptable
total cost. A low hourly rate or a fast empty boot does not establish that.

Runtime provides Firecracker microVM sandboxes on Runtime-operated dedicated
servers, with API, CLI, JavaScript, Python and MCP interfaces. New accounts get a 20-hour free trial. Use the checks below to evaluate Runtime or another provider
against your requirements.

## Start with the workload

Write down one representative task: for example, install a repository's pinned
dependencies, run its test suite, make one change, and export the test report.
Record the language version, CPU and memory needs, required network destinations,
files to preserve, expected duration and acceptable failure rate.

| Requirement             | What to verify                                                | Runtime's current position                                                                |
| ----------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Isolated code execution | Boundary between guest, host and other tenants                | Firecracker microVMs; limited private hardware tests, no completed external audit claimed |
| Agent integration       | Actual remote execution, structured results, file round trip  | API, CLI, Python, JavaScript and MCP; one Runtime Cloud SDK with product namespaces       |
| Easy authentication     | Connection without secrets in prompts or project files        | Browser-approved CLI connection; local MCP reuses it                                      |
| Outbound network        | Your package registries and service destinations work         | Controlled public-web egress; per-sandbox rules; `host:port` access for paid accounts     |
| Public app hosting      | Reachability, ingress auth and abuse controls                 | Previews: an HTTPS address per port, private by default                                   |
| Pause and restoration   | Files and memory survive; expiry and failed wake are explicit | Same-host pause/wake; a full or unavailable host can prevent restoration                  |
| Durable outputs         | Backups, replication and recovery evidence                    | Export important data; a sandbox is not a replicated backup service                       |
| Predictable cost        | CPU, memory, idle time, storage, retries and fees             | Measured CPU with a floor, reserved memory, separately quoted paused storage              |
| Production readiness    | Access, operational evidence and service commitments          | Open signup with a free trial; check current guarantees against the workload              |

For exact terms, read [security](./security), [pricing](./pricing),
[trial access](./trial), and the [API reference](./api).

## Measure completed jobs

Run the same inputs, dependency versions and output checks on every candidate.
Separate cold starts from warm or resumed runs. Use enough repetitions to reveal
slow runs and failures; publish the sample count instead of hiding it behind an
average. Record:

- Time from request to an executable environment.
- Dependency setup, task execution and artifact export time.
- Median and 95th-percentile end-to-end completion time.
- Successful, failed and retried jobs, including exhausted capacity.
- CPU-seconds, allocated memory, running duration and retained storage.
- Total charge divided by successful jobs, including failed attempts.

State hardware, region, concurrency, dates, SDK versions, CPU guarantees and all
pricing assumptions. A shared CPU ceiling is not a reserved physical core. Do
not call equal CPU counts equal performance without measuring them.

## Exercise the failures you will have to handle

Try a lost create response, an execution timeout, a nonzero exit code, a network
destination that is refused, an expired lease, and unavailable capacity on wake.
Check that retrying the same operation does not create duplicate work or charges.
Verify that revoking one agent's credential stops its access without breaking
another agent's connection.

For a pause test, write a file and keep a small in-memory value, pause, restore,
then verify both. Report failed restoration honestly. A new clean boot is not
proof that memory restoration succeeded.

## When Runtime is worth evaluating

Runtime is a candidate for coding agents, test execution, file processing and
multi-step jobs that fit its Linux and public-web network constraints. Its CPU
metering is worth measuring for workloads that spend time waiting on model or
network responses. The CPU floor and reserved memory still accrue charges while
running; pause can introduce separate storage costs and restoration constraints.

If you need arbitrary outbound TCP, replicated durable storage, GPUs or
established production service guarantees today, do not infer those features
from the presence of an SDK method. Check availability first.

## Compared with a specific provider

Side-by-side pages, with published rates and where each rival is stronger:
[E2B](./e2b-alternative), [Daytona](./daytona-alternative),
[Vercel Sandbox](./vercel-sandbox-alternative) and
[Modal Sandboxes](./modal-sandbox-alternative).

## Migrate only after the comparison passes

Keep the existing provider available for rollback. Verify output correctness,
cleanup, cost and failures before increasing traffic. The [migration guide](./migrate)
describes a reversible rollout; the [getting-started guide](./start) covers a new
project. Runtime does not claim universal performance or cost superiority.