# Sandbox Router — One API. Every sandbox.

Run workloads across sandbox providers through a single integration. Optimize for cost, performance, and availability without vendor lock-in.

Get started in the [console](https://console.sandboxrouter.io/), or [browse the providers](https://sandboxrouter.io/providers).

## Use your agent

Hand the setup to your agent. Paste this into Claude Code, Cursor, Codex or any agent that can read a URL and run commands in your repo:

```text
Set up Sandbox Router in this project.
1. Read https://sandboxrouter.io/docs/cli.md and https://sandboxrouter.io/docs/api.md, and follow the current documentation.
2. Inspect this project and identify its setup and test commands.
3. Help me configure workspace access using the documented CLI or API.
4. Ask which sandbox providers I use, then guide me through connecting their keys in the console.
5. Run this project's tests in a sandbox. Show me the sandbox ID, the provider used and the test results.
```

The website shows this routing preview: runs start from GitHub, Linear, webhooks or the API and CLI. One run, started by a GitHub event, is placed on Provider X, which is out of capacity, and moves on to Daytona, with E2B next in line. Sandbox Router's Standby Pool stays on standby:

```text
sandboxrouter runs events run_8f2k --follow
14:02:07.081  attempt.started      github pull_request.opened
14:02:07.094  execution.placing    [provider-x, daytona, e2b]
14:02:07.233    ↳ provider-x       out of capacity → next
14:02:08.517  execution.started    currentProvider=daytona ✓
```

## At a glance

- **13,348** Sandboxes
- **0** Failover
- **5** Providers

The homepage refreshes these aggregates from [the public statistics endpoint](https://sandboxrouter.io/api/stats); this Markdown carries the verified release snapshot.

## Find the right sandbox for the job

Compare providers on the benchmark that matters for your workload. Each card’s info control explains its ranking and links to its source.

| Workload | Metric | First | Second | Third |
| --- | --- | --- | --- | --- |
| Interactive tool calls | Median start | Superserve: 0.50s | Daytona: 0.60s | Cloudflare: 0.67s |
| Parallel evals and fan-out | P99 start | Daytona: 0.83s | Superserve: 0.99s | Cloudflare: 1.19s |
| Coding agents and CI | Build time | Superserve: 59.4s | TensorLake: 73.1s | Daytona: 81.5s |
| Long-running agents | Start score | Superserve: 93.2 | E2B: 87.3 | TensorLake: 83.4 |
| GPU workloads | Start score | Daytona: 93.2 | TensorLake: 83.4 | |
| Batch and background jobs | Cost per workload | Superserve: $0.011 | Daytona: $0.015 | TensorLake: $0.016 |

Start times and scores come from [ComputeSDK Burst TTI](https://www.computesdk.com/benchmarks/sandboxes/burst-tti), a burst of 100 sandbox starts. Median start measures time to the first successful command; P99 captures the slowest starts. The start score combines median, p95 and p99 times with success rate.

Long-running agents includes providers with memory snapshots and fork; its start score is not a persistence benchmark. GPU workloads includes GPU-capable providers, using their general sandbox start score. It measures neither GPU throughput nor GPU provisioning time.

Build times and workload costs come from [ComputeSDK DAX](https://www.computesdk.com/benchmarks/sandboxes/dax): prepare a fresh sandbox, clone OpenCode, install dependencies and typecheck it. These published benchmark costs are not quotes for your workload.

## Latency, uptime, cost. Optimize all three.

Compare the trade-offs, choose your provider order, and let Sandbox Router handle placement and failover. [Compare providers](https://sandboxrouter.io/providers/compare?p=daytona,e2b,cloudflare).

The routing illustration shows runs moving to the next provider when one is at capacity. Its failover counter is 0.

## Keep running through provider limits

When a provider can't start a sandbox, Auto tries the next eligible provider. The Standby Pool is there when the providers in your order can't take the run. [How failover works](https://sandboxrouter.io/docs/routing#creation-failover).

The timeline illustrates requests moving between example Providers A, B and C, then reaching the Standby Pool when all three are unavailable.

## One dashboard for every provider

Keep sandbox activity and provider usage in view from one console, without switching between dashboards. [See the console](https://console.sandboxrouter.io/).

The static example workspace shows 12,403 runs, 318 failovers and $170.35 spend over fourteen days. Its stacked chart and provider breakdown use illustrative data:

| Provider | Runs | Spend |
| --- | --- | --- |
| Daytona | 5,752 | $63.27 |
| E2B | 3,554 | $53.31 |
| Cloudflare | 2,107 | $37.93 |
| Other | 990 | $15.84 |

## Control where your code runs

Compare isolation and security requirements, then choose the providers that fit your workload. [Explore provider capabilities](https://sandboxrouter.io/providers).

The interactive illustration compares six example providers against microVM, SOC 2 and Confidential Compute requirements.

## Route your first run

One API for every sandbox provider. Get started in the [console](https://console.sandboxrouter.io/).

## Explore

- [Providers](https://sandboxrouter.io/providers)
- [Features](https://sandboxrouter.io/features)
- [Pricing](https://sandboxrouter.io/pricing)
- [Docs](https://sandboxrouter.io/docs)