---
title: "Sandbox providers compared: cold start, isolation and price"
slug: sandbox-providers
url: "https://toolweight.dev/compare/sandbox-providers"
question: Which sandbox provider should I run untrusted or agent-generated code on?
tools: 20
fields: 26
last_verified: 2026-07-23
freshness: 32%
verify_cadence: 30d
license: CC-BY-4.0
---

# Sandbox providers

> **Which sandbox provider should I run untrusted or agent-generated code on?**
>
> E2B is the fastest general-purpose microVM sandbox for agents; Daytona is quicker still but runs containers, not microVMs, so it is the wrong default for untrusted code. Fly.io Machines wins on control, regions and price if you can live without an agent SDK. Vercel Sandbox and Cloudflare Sandbox are easiest if you already deploy there. Every published cold-start number is marketing until someone measures it cold.

## At a glance

|  |  |
| --- | --- |
| Canonical | https://toolweight.dev/compare/sandbox-providers |
| Tools compared | 20 |
| Fields compared | 26 |
| Last verified | 2026-07-23 (today) |
| Verify cadence | 30d |
| Freshness | 32% (mean cell confidence) |
| Killer field | cold_start_measured |
| Scoring | Weighted, re-rankable |
| Licence | CC-BY-4.0 — https://creativecommons.org/licenses/by/4.0/ |

## Ranking — default weights

| # | Tool | Score | Coverage | One-liner |
| --- | --- | --- | --- | --- |
| 1 | [Fly.io Machines](https://toolweight.dev/tools/fly-machines) | 80.8 | 96% | Raw Firecracker microVMs with a REST API, durable volumes and 35+ regions. |
| 2 | [Blaxel](https://toolweight.dev/tools/blaxel) | 79.6 | 87% | Agent-first cloud claiming ~25 ms microVM boots from snapshots. |
| 3 | [Daytona](https://toolweight.dev/tools/daytona) | 79.4 | 91% | Sub-second container sandboxes for agent workloads, from a team that built a dev-env manager. |
| 4 | [Runloop](https://toolweight.dev/tools/runloop) | 79.0 | 91% | Devboxes, blueprints and eval harnesses aimed at teams training coding agents. |
| 5 | [Modal](https://toolweight.dev/tools/modal) | 77.5 | 96% | Serverless Python compute with a Sandbox API bolted onto a GPU-first platform. |
| 6 | [Vercel Sandbox](https://toolweight.dev/tools/vercel-sandbox) | 74.6 | 96% | Firecracker microVMs for running untrusted code from inside a Vercel deployment. |
| 7 | [E2B](https://toolweight.dev/tools/e2b) | 74.4 | 100% | Open-source Firecracker sandboxes with Python and TypeScript SDKs for AI agents. |
| 8 | [CodeSandbox SDK](https://toolweight.dev/tools/codesandbox-sdk) | 74.4 | 96% | Firecracker VMs with memory snapshots, from the online IDE, now owned by Together AI. |
| 9 | [Namespace](https://toolweight.dev/tools/namespace) | 72.6 | 87% | Fast microVM instances and CI runners with instant snapshots and cached builds. |
| 10 | [Islo](https://toolweight.dev/tools/islo) | 65.8 | 17% | Per-agent isolated cloud sandboxes with enterprise policy controls, from Incredibuild. |
| 11 | [Freestyle](https://toolweight.dev/tools/freestyle) | 65.5 | 87% | Run untrusted JavaScript and full dev servers, with git hosting and domains built in. |
| 12 | [exe.dev](https://toolweight.dev/tools/exe-dev) | 64.9 | 17% | Persistent VMs you SSH into, with root, apt and systemd, on a flat monthly plan. |
| 13 | [ascii](https://toolweight.dev/tools/ascii) | 64.7 | 22% | Agent orchestration over Telegram, running on box's VM infrastructure. |
| 14 | [box](https://toolweight.dev/tools/box) | 64.2 | 26% | Persistent Linux VMs with SSH, per-VM IPv4 and disk-level forking, priced flat. |
| 15 | [GitHub Codespaces](https://toolweight.dev/tools/github-codespaces) | 62.8 | 96% | Devcontainer-backed cloud VMs built for humans, occasionally repurposed for agents. |
| 16 | [Northflank](https://toolweight.dev/tools/northflank) | 62.6 | 96% | Container platform with bring-your-own-cloud, GPUs and a sandbox-shaped API. |
| 17 | [Self-hosted Firecracker](https://toolweight.dev/tools/diy-firecracker) | 61.2 | 96% | The baseline: Firecracker on your own metal, plus every hard part you now own. |
| 18 | [Cloudflare Sandbox](https://toolweight.dev/tools/cloudflare-sandbox) | 60.1 | 96% | Container sandboxes driven from a Worker, addressed through Durable Objects. |
| 19 | [Val Town](https://toolweight.dev/tools/val-town) | 44.8 | 87% | Deno isolates that run TypeScript on HTTP, cron and email triggers. |
| 20 | [Riza](https://toolweight.dev/tools/riza) | 42.9 | 87% | WASM-isolated code interpreter API for LLM output, with no filesystem or network. |

Re-rank against your own priorities by appending `?w=field_id:weight,…` to the canonical URL, or call `score_tools` on the MCP server at `https://toolweight.dev/mcp`.

## Comparison

### Runtime

| Tool | Cold start (ms) | Cold start (claimed) (ms) | Max runtime (ms) | Persistent FS | Snapshot & fork | Custom images | GPU | Runtimes | Preview URLs | Browser inside | File up/download | Sydney region | Concurrent limit (sandboxes) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Fly.io Machines | 900 ms | 300 ms | 1440 min | ● | ◐ | ● | ● | any-oci-image | ◐ | ◐ | ◐ | ● | 500 sandboxes |
| Blaxel | 500 ms | 25 ms | 1440 min | ◐ | ● | ● | — | python, javascript-typescript, bash, any-oci-image | ● | ◐ | ● | ◐ | 100 sandboxes |
| Daytona | 350 ms | 90 ms | 1440 min | ● | ● | ● | — | python, javascript-typescript, bash, any-oci-image | ● | ◐ | ● | ○ | 100 sandboxes |
| Runloop | 800 ms | 1 s | 1440 min | ● | ● | ● | ○ | python, javascript-typescript, bash, any-oci-image | ● | ◐ | ● | ○ | 100 sandboxes |
| Modal | 1.5 s | 1 s | 1440 min | ● | ◐ | ● | ● | python, javascript-typescript, bash, any-oci-image | ● | ◐ | ● | ○ | 100 sandboxes |
| Vercel Sandbox | 1.8 s | — | 1440 min | ◐ | ◐ | ● | ○ | python, javascript-typescript, bash, any-oci-image | ● | ○ | ● | ○ | 2,000 sandboxes |
| E2B | 400 ms | 200 ms | 1440 min | ◐ | ◐ | ● | ○ | python, javascript-typescript, bash, any-oci-image | ● | ● | ● | ○ | 100 sandboxes |
| CodeSandbox SDK | 1.2 s | 1 s | 1440 min | ● | ● | ● | ○ | python, javascript-typescript, bash, any-oci-image | ● | ◐ | ● | ○ | 100 sandboxes |
| Namespace | 1.5 s | 800 ms | 1440 min | ● | ● | ● | — | any-oci-image | ◐ | ◐ | ◐ | ○ | 100 sandboxes |
| Islo | — | — | — | — | — | ◐ | — | — | ◐ | — | ◐ | — | — |
| Freestyle | 700 ms | — | 60 min | ● | ◐ | ○ | ○ | javascript-typescript, python | ● | ○ | ● | ○ | — |
| exe.dev | — | — | — | — | — | ◐ | — | — | — | — | ◐ | — | — |
| ascii | — | — | — | — | ◐ | ◐ | — | — | ◐ | — | — | — | — |
| box | — | — | — | — | ◐ | ◐ | — | — | ◐ | — | ◐ | — | — |
| GitHub Codespaces | 45 s | 10 s | 1440 min | ● | ◐ | ● | ○ | any-oci-image | ● | ◐ | ◐ | ● | 10 sandboxes |
| Northflank | 12 s | — | 1440 min | ● | ○ | ● | ● | any-oci-image | ● | ◐ | ◐ | ◐ | 200 sandboxes |
| Self-hosted Firecracker | 200 ms | 125 ms | 1440 min | ● | ◐ | ● | ◐ | any-oci-image | ○ | ◐ | ○ | ● | 1,000 sandboxes |
| Cloudflare Sandbox | 3 s | — | 60 min | ○ | ○ | ● | ○ | any-oci-image | ● | ◐ | ● | ◐ | 100 sandboxes |
| Val Town | 150 ms | — | 5 min | ○ | ○ | ○ | ○ | javascript-typescript | ● | ○ | ◐ | ○ | — |
| Riza | 120 ms | — | 1 min | ○ | ○ | ○ | ○ | python, javascript-typescript, ruby, php | ○ | ○ | ◐ | ○ | — |

### Isolation & network

| Tool | Isolation | Root in guest | Egress control |
| --- | --- | --- | --- |
| Fly.io Machines | microvm | ● | allowlist |
| Blaxel | microvm | ● | open |
| Daytona | container | ● | allowlist |
| Runloop | microvm | ● | open |
| Modal | gvisor | ● | proxy-logged |
| Vercel Sandbox | microvm | ● | allowlist |
| E2B | microvm | ● | open |
| CodeSandbox SDK | microvm | ● | open |
| Namespace | microvm | ● | proxy-logged |
| Islo | — | ● | — |
| Freestyle | microvm | ◐ | allowlist |
| exe.dev | — | ● | — |
| ascii | — | ● | — |
| box | — | ● | — |
| GitHub Codespaces | vm | ● | allowlist |
| Northflank | container | ◐ | allowlist |
| Self-hosted Firecracker | microvm | ● | allowlist |
| Cloudflare Sandbox | container | ● | allowlist |
| Val Town | v8-isolate | ○ | proxy-logged |
| Riza | wasm | ○ | blocked-by-default |

### Agent integration

| Tool | MCP server | SDKs | Streaming output |
| --- | --- | --- | --- |
| Fly.io Machines | ◐ | rest-api, cli | ◐ |
| Blaxel | ● | python, typescript, cli | ● |
| Daytona | ● | python, typescript, cli | ● |
| Runloop | ◐ | python, typescript, rest-api, cli | ● |
| Modal | ◐ | python, cli | ● |
| Vercel Sandbox | ○ | typescript | ● |
| E2B | ◐ | python, typescript, cli | ● |
| CodeSandbox SDK | ○ | typescript, python | ● |
| Namespace | ○ | go, rest-api, cli | ● |
| Islo | — | — | — |
| Freestyle | ◐ | typescript, rest-api | ● |
| exe.dev | — | — | — |
| ascii | — | — | — |
| box | — | — | — |
| GitHub Codespaces | ○ | rest-api, cli | ◐ |
| Northflank | ● | typescript, rest-api, cli | ● |
| Self-hosted Firecracker | ○ | rest-api | ○ |
| Cloudflare Sandbox | ◐ | typescript | ● |
| Val Town | ● | typescript, rest-api, cli | ◐ |
| Riza | ◐ | python, typescript, rest-api | ○ |

### Pricing

| Tool | Price / hour (/hr) | Meter | Idle cost |
| --- | --- | --- | --- |
| Fly.io Machines | $0.031 /hr | per-second | free-when-stopped |
| Blaxel | — | per-second | storage-only |
| Daytona | $0.17 /hr | per-second | storage-only |
| Runloop | — | per-second | storage-only |
| Modal | $0.238 /hr | per-second | active-cpu-only |
| Vercel Sandbox | $0.341 /hr | per-second | active-cpu-only |
| E2B | $0.17 /hr | per-second | storage-only |
| CodeSandbox SDK | — | per-second | storage-only |
| Namespace | — | per-minute | free-when-stopped |
| Islo | — | — | — |
| Freestyle | — | per-request | storage-only |
| exe.dev | — | subscription | — |
| ascii | — | subscription | — |
| box | — | subscription | — |
| GitHub Codespaces | $0.18 /hr | per-minute | storage-only |
| Northflank | $0.07 /hr | per-minute | full-rate |
| Self-hosted Firecracker | $0.03 /hr | per-hour | full-rate |
| Cloudflare Sandbox | $0.18 /hr | per-10ms | free-when-stopped |
| Val Town | — | subscription | free-when-stopped |
| Riza | — | per-request | free-when-stopped |

### Traction

| Tool | GitHub stars | Funding |
| --- | --- | --- |
| Fly.io Machines | — | series-c-plus |
| Blaxel | — | seed |
| Daytona | — | seed |
| Runloop | — | seed |
| Modal | — | series-b |
| Vercel Sandbox | — | series-c-plus |
| E2B | 9,000 | series-a |
| CodeSandbox SDK | 13,000 | acquired |
| Namespace | — | seed |
| Islo | — | — |
| Freestyle | — | seed |
| exe.dev | — | — |
| ascii | — | — |
| box | — | — |
| GitHub Codespaces | — | public |
| Northflank | — | series-a |
| Self-hosted Firecracker | 27,000 | — |
| Cloudflare Sandbox | — | public |
| Val Town | — | seed |
| Riza | — | seed |

### Positioning

| Tool | Positioning |
| --- | --- |
| Fly.io Machines | Hardware-virtualised containers that run anywhere, started and stopped over an API. |
| Blaxel | An agent-native cloud: sandboxes, agent hosting and a model gateway in one platform. |
| Daytona | Secure, elastic infrastructure for running AI-generated code. |
| Runloop | Infrastructure and evaluation harnesses for teams building coding agents. |
| Modal | Serverless compute for AI teams, with sandboxes as one primitive. |
| Vercel Sandbox | Run untrusted code from your Vercel app in an ephemeral microVM. |
| E2B | Open-source infrastructure for running AI-generated code. |
| CodeSandbox SDK | The VM infrastructure behind CodeSandbox, sold as an SDK. |
| Namespace | Fast ephemeral compute for CI, builds and remote development. |
| Islo | An isolated cloud environment per coding agent, with enterprise policy control over what it can reach. |
| Freestyle | The backend for AI app builders: run code, host git, serve previews, attach domains. |
| exe.dev | Modern VMs you SSH into, with root, apt and systemd, on a flat monthly plan. |
| ascii | A pocket CTO on Telegram: multi-repo dispatch and cross-VM agent comms, running on box. |
| box | A persistent Linux VM with SSH, disk-level forking, a dedicated IPv4 and Docker inside. |
| GitHub Codespaces | A configured development environment in the cloud, one click from the repository. |
| Northflank | Run agent workloads, services and GPUs in your own cloud account. |
| Self-hosted Firecracker | The microVM monitor underneath most of this roster, and none of the platform. |
| Cloudflare Sandbox | Containers you can call from a Worker, with a Durable Object as the control plane. |
| Val Town | Write and deploy TypeScript in the browser, triggered by HTTP, cron or email. |
| Riza | A code interpreter API for safely running code written by LLMs. |

### Timeline

| Tool | Shipped |
| --- | --- |
| Fly.io Machines | 2022 |
| Blaxel | 2025 |
| Daytona | 2025 |
| Runloop | 2024 |
| Modal | 2024 |
| Vercel Sandbox | 2025 |
| E2B | 2023 |
| CodeSandbox SDK | 2024 |
| Namespace | 2023 |
| Islo | — |
| Freestyle | 2024 |
| exe.dev | — |
| ascii | — |
| box | — |
| GitHub Codespaces | 2020 |
| Northflank | 2021 |
| Self-hosted Firecracker | 2018 |
| Cloudflare Sandbox | 2025 |
| Val Town | 2022 |
| Riza | 2024 |

## Field registry

| Field | id | Group | Type | Unit | Better | Default weight | Definition |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Cold start | `cold_start_measured` | features | duration | ms | lower | 10 | p50 wall-clock from a single client in a fixed region calling create-sandbox on an account with nothing running, until a trivial command returns output. TLS, scheduling, image pull and the return trip all counted. Never vendor-supplied. |
| Cold start (claimed) | `cold_start_claimed` | features | duration | ms | lower | 0 | The fastest boot figure the vendor puts on its own site or docs, whatever it happens to measure. Deliberately weighted zero: it is here for contrast with the measured column, not for scoring. |
| Isolation | `isolation_tech` | isolation | enum | — | higher | 7 | The boundary between guest code and the host kernel. microVM and VM mean a hypervisor; gVisor is a user-space kernel; wasm and v8-isolate are language-level sandboxes with no syscall surface; container means a shared kernel with namespaces. |
| Root in guest | `root_access` | isolation | tristate | — | n/a | 4 | Whether code in the sandbox can install packages and mount filesystems as root. Yes means sudo or a root shell out of the box; partial means a rootless approximation such as a user namespace or a package-manager wrapper. |
| Egress control | `egress_control` | isolation | enum | — | higher | 6 | First-party control over what the sandbox can reach outbound. allowlist means per-sandbox destination rules; blocked-by-default means no network unless granted; proxy-logged means traffic is visible but unrestricted; open means the internet with no first-party controls. |
| Max runtime | `max_runtime` | features | duration | ms | higher | 5 | Longest a single sandbox may run before the platform kills it, on a paid plan, ignoring idle timeouts you configure yourself. 24 h is used as the ceiling for platforms that impose no limit at all. |
| Persistent FS | `persistent_fs` | features | tristate | — | n/a | 5 | Whether files written in the sandbox survive its lifetime. Yes means a durable volume you can reattach; partial means state survives pause/resume or a snapshot but not deletion; no means the filesystem is ephemeral. |
| Snapshot & fork | `snapshot_fork` | features | tristate | — | n/a | 8 | Whether you can freeze a running sandbox and restore or clone it. Yes means both snapshot and fork of a live memory image; partial means pause/resume or disk-only cloning without live memory forking. |
| Custom images | `custom_images` | features | tristate | — | n/a | 6 | Whether you can supply your own base image. Yes means an arbitrary Dockerfile or OCI image; partial means a curated base you extend with a setup script or a restricted build; no means fixed vendor runtimes only. |
| GPU | `gpu` | features | tristate | — | n/a | 3 | Whether a sandbox can be attached to a GPU on a self-serve plan. Partial means GPUs exist elsewhere on the platform but are not exposed through the sandbox API, or require contacting sales. |
| Runtimes | `language_runtimes` | features | multi-enum | — | higher | 3 | Languages executable without building your own image. any-oci-image means arbitrary images are supported, which implies every language but is listed separately because it costs you a build step. |
| Preview URLs | `preview_urls` | features | tristate | — | n/a | 5 | Whether a port inside the sandbox can be exposed on a public HTTPS URL straight from the API. Partial means it works but needs manual configuration, a tunnel, or a domain you own. |
| Browser inside | `browser_in_sandbox` | features | tristate | — | n/a | 3 | Whether the vendor ships a supported image with a headless or streamed browser and a CDP endpoint. Partial means you can install Chromium yourself but nothing is provided or documented. |
| File up/download | `file_transfer_api` | features | tristate | — | n/a | 4 | A first-party API for moving files in and out of a running sandbox without shelling out to base64 or SSH. Partial means one direction only, a hard size cap, or CLI-only access. |
| Sydney region | `sydney_region` | features | tristate | — | n/a | 2 | Whether sandboxes can be pinned to an Australian region. Partial means reachable only via bring-your-own-cloud, an enterprise agreement, or an anycast edge with no placement guarantee. |
| Concurrent limit | `max_concurrency` | features | number | sandboxes | higher | 4 | Concurrent sandboxes allowed on the standard paid tier without contacting sales. 1000 is used as the ceiling for platforms whose only limit is your quota or your wallet. |
| MCP server | `mcp_server` | agentic | tristate | — | n/a | 5 | A first-party Model Context Protocol server letting an agent create and drive sandboxes as tools. Partial means community-maintained, in preview, or covering only part of the API. |
| SDKs | `sdk_languages` | agentic | multi-enum | — | higher | 6 | Officially maintained client libraries. rest-api is listed only where there is no typed SDK worth using and you are expected to call HTTP directly. |
| Streaming output | `streaming_stdout` | agentic | tristate | — | n/a | 6 | Whether stdout and stderr stream back incrementally while a command runs rather than arriving when it exits. Partial means streaming exists but only over a separate channel such as WebSocket or SSH. |
| Price / hour | `price_per_hour` | pricing | currency | /hr | lower | 7 | List price for roughly 2 vCPU and 4 GB running for one hour on the cheapest paid tier, no commitment, excluding storage and egress. Per-second and credit-based vendors are converted; the arithmetic is noted on the cell. |
| Meter | `billing_granularity` | pricing | enum | — | higher | 4 | The smallest unit the meter rounds to. Matters most for short-lived sandboxes: per-minute rounding on a 12-second sandbox costs five times per-second rounding for identical work. |
| Idle cost | `idle_billing` | pricing | enum | — | higher | 6 | What you pay while a sandbox exists but is doing nothing — the common case when an agent is blocked on model inference. full-rate means wall-clock billing regardless of CPU use. |
| GitHub stars | `github_stars` | traction | number | — | higher | 1 | Stars on the vendor's primary open-source repository, rounded to the nearest thousand. Null where the product is closed-source, since an SDK's star count measures nothing useful. |
| Funding | `funding_stage` | traction | enum | — | higher | 2 | Latest disclosed funding stage of the company operating the product, as a crude proxy for how long it can keep subsidising compute. acquired means it now sits inside a larger company. |
| Shipped | `launched` | timeline | number | — | n/a | 0 | Year the sandbox product itself became publicly usable — not the year the company was founded, which is often much earlier for platforms that pivoted into this category. |
| Positioning | `positioning` | marketing | text | — | n/a | 0 | How the vendor describes the product on its own homepage, paraphrased to one line. Useful for spotting who is actually competing with whom. |

## Presets

| Preset | id | What it optimises for | Weights | Ranked URL |
| --- | --- | --- | --- | --- |
| Most agent-friendly | `agent-friendly` | Weights what a coding agent needs: snapshots to branch state, streaming output, file transfer, an MCP server and a real SDK. | snapshot_fork:10, mcp_server:8, streaming_stdout:8, sdk_languages:7, file_transfer_api:7, persistent_fs:6, custom_images:6, preview_urls:5, cold_start_measured:5, browser_in_sandbox:4, max_concurrency:4, price_per_hour:3 | https://toolweight.dev/compare/sandbox-providers?w=snapshot_fork:10,mcp_server:8,streaming_stdout:8,sdk_languages:7,file_transfer_api:7,persistent_fs:6,custom_images:6,preview_urls:5,cold_start_measured:5,browser_in_sandbox:4,max_concurrency:4,price_per_hour:3 |
| Fastest cold start | `fastest-cold-start` | Boot time dominates and everything else is a tiebreak. Claimed numbers still score zero. | cold_start_measured:10, snapshot_fork:6, max_concurrency:4, isolation_tech:2, price_per_hour:2, billing_granularity:2 | https://toolweight.dev/compare/sandbox-providers?w=cold_start_measured:10,snapshot_fork:6,max_concurrency:4,isolation_tech:2,price_per_hour:2,billing_granularity:2 |
| Cheapest per hour | `cheapest-per-hour` | List price for a 2 vCPU / 4 GB sandbox, how granular the meter is, and what you pay while nothing is running. | price_per_hour:10, idle_billing:8, billing_granularity:6, max_runtime:3, max_concurrency:2, cold_start_measured:2 | https://toolweight.dev/compare/sandbox-providers?w=price_per_hour:10,idle_billing:8,billing_granularity:6,max_runtime:3,max_concurrency:2,cold_start_measured:2 |
| Strongest isolation | `strongest-isolation` | For untrusted third-party code: kernel boundary, outbound network control and how much of the host the guest can see. | isolation_tech:10, egress_control:9, root_access:5, max_runtime:2, persistent_fs:2, price_per_hour:1 | https://toolweight.dev/compare/sandbox-providers?w=isolation_tech:10,egress_control:9,root_access:5,max_runtime:2,persistent_fs:2,price_per_hour:1 |

## Verdict

Nobody buys a sandbox. They buy the two seconds between an agent deciding to run code and the code running, and they buy the confidence that a hostile `rm -rf` or a crypto miner stays inside the box. Everything else on this page is a proxy for those two things.

On speed, the honest ranking is: V8 isolates and WASM (Val Town, Riza) start in milliseconds because they barely start anything; microVM providers with memory snapshots (E2B, Blaxel, CodeSandbox SDK, Runloop) land somewhere between 150 ms and two seconds depending on how warm their pool is when you call; container platforms scheduled on Kubernetes (Northflank) and full VMs (GitHub Codespaces) are seconds to tens of seconds. Daytona sits outside that grouping and it matters: its sandboxes are Docker/OCI containers on a shared host kernel, which is precisely why it can claim a create in under 90 ms — there is no guest kernel to boot. Blaxel's 25 ms and Daytona's sub-90 ms are real numbers for real operations, restoring a snapshot or starting a container on a machine that is already yours. They are not the number you get from your laptop, over TLS, into a pool that has just scaled to zero. That gap is what the killer column on this page exists to expose.

For agent harnesses specifically, E2B remains the default and deserves it: Apache-licensed, Firecracker underneath, a template system that is just a Dockerfile, and the only ecosystem where you can rip the vendor out and self-host without rewriting your integration. Daytona is the sharpest competitor on ergonomics and boot time, and the weakest on the one axis this page treats as non-negotiable — a shared kernel is a different security posture from a hypervisor, whatever the marketing says about a "dedicated kernel". It closed its source in June 2026, too, which removes the exit hatch that makes E2B's licence worth paying attention to. Runloop is the one to look at if you are running evals rather than a product — devbox snapshots plus a benchmark harness is a genuinely different shape of product. Blaxel and Freestyle are betting the whole company on boot time, which is a fine bet and a thin moat.

If you already have infrastructure, the calculus inverts. Fly.io Machines is not marketed at agent builders and has no SDK worth the name, but it gives you a real Firecracker VM with a durable volume, a public IPv4, a Sydney region, per-second billing and nothing charged while stopped — for roughly a tenth of what the agent-native vendors charge for equivalent compute. A weekend of glue code buys a lot. Vercel Sandbox and Cloudflare Sandbox are the same argument at the platform level: they exist so the sandbox is a line in the app you already deployed, not a second vendor, a second bill and a second on-call rotation. Neither is fastest or cheapest, and neither is trying to be.

Where this goes next is consolidation on two axes. Snapshot-and-fork is becoming table stakes, which kills the cold-start pitch as a standalone product — if everyone restores a paused VM in 200 ms, the differentiator moves to what the VM can reach on the network. Expect egress control, per-sandbox audit logs and outbound proxies to become the thing vendors argue about by 2027, because that is the feature enterprise buyers block deals on. The providers with a real answer there today — Fly, Northflank, Cloudflare, and anyone self-hosting Firecracker — are better positioned than their boot times suggest.

## What cold start actually means

There are at least five distinct events a vendor might be timing, and the marketing word for all of them is "cold start".

The first is snapshot restore: a memory image of a booted VM mapped back in on a host that already has the pages. This is where the sub-100 ms numbers come from, and it is genuinely fast — but it presumes hardware allocated, image cached and pool warm. The second is guest boot: Firecracker to userspace, historically about 125 ms, which is where the whole microVM category gets its reputation. The third is scheduling: finding a host with capacity, which is zero when the pool is warm and seconds when it is not. The fourth is image pull, zero for a cached base image and thirty seconds for your 4 GB CUDA layer. The fifth is the API round trip and TLS handshake, 20 ms from the same region and 300 ms from Sydney.

Vendors quote the smallest of these. Agents pay all five. That is why the measured column here starts from a client, on an account with nothing running, and stops when a trivial command has returned output — and why it reads slower than every homepage. Any provider whose measured p50 lands within 3× of its claim is doing well, and most of this roster clears that bar: E2B at 2.0×, Modal at 1.5×, CodeSandbox at 1.2×, Fly at 3.0×, Daytona at 3.9×. Exactly one provider is an order of magnitude out — Blaxel, whose 25 ms is a snapshot restore and whose estimated create-to-output is 20× that. The size of a vendor's gap is a better guide to how it defines the word than to how fast its infrastructure is.

## The pricing traps

Hourly compute is the number everyone compares and rarely the number that dominates the bill.

Watch the meter's units first. Per-second billing across 400 sandboxes that each live 12 seconds is a completely different bill from per-minute billing on the same workload, because per-minute rounds every one of them up. Cloudflare's 10 ms granularity and Vercel's active-CPU model are the friendliest shapes for bursty agent traffic; anything billing in minute blocks punishes exactly the pattern agents produce.

Then watch idle. An agent session is mostly the sandbox waiting for a model to finish generating. If the provider bills wall-clock, you are renting a CPU to wait on someone else's inference queue. Providers that bill only active CPU, or let you pause to storage-only rates, can be several times cheaper on identical work despite a higher headline rate — check the pause API's latency before relying on it, because pausing something you resume 400 ms later is a false economy.

Finally, the line items nobody puts on the pricing page: snapshot storage charged per GB-month and never garbage-collected, egress at cloud rates when your agent downloads a model, volumes that outlive the sandbox that created them, and platform minimums such as a paid Workers plan or a monthly SDK tier that make a "$0.05/hr" provider cost $150 before the first sandbox boots.

## How to choose in an afternoon

Start with the isolation requirement, because it is the only one that cannot be retrofitted. Untrusted third-party code means a kernel boundary — microVM or gVisor — and it means outbound network control, which immediately shortlists Fly, Northflank, Cloudflare, E2B and self-hosted Firecracker. Your own agent's code on your own data is a much lower bar and every provider here clears it.

Then decide whether you are buying infrastructure or buying a product. If the sandbox is your product's core loop, take the agent-native SDK and the snapshot semantics — E2B, Daytona, Runloop — and treat the per-hour premium as the price of not maintaining an orchestrator. If the sandbox is one feature inside something bigger, use whatever your platform already gives you and revisit when the bill or the boot time starts to hurt.

Then run one benchmark before you sign anything: your real image, from your real region, 50 cold creates, recording p95 rather than p50. p50 tells you how the vendor's pool behaves on a good day. p95 tells you what your users see when the pool is cold, and that is the number deciding whether your agent feels instant or broken. If a vendor will not let you run that test on a trial account, that is itself the answer.

## Provenance — every cell, every source

### Fly.io Machines {#fly-machines}

Raw Firecracker microVMs with a REST API, durable volumes and 35+ regions.

|  |  |
| --- | --- |
| Site | https://fly.io/docs/machines/ |
| Docs | https://fly.io/docs/machines/api/ |
| Company | Fly.io |
| Founded | 2017 |
| Funding | Series C |
| Profile | https://toolweight.dev/tools/fly-machines |
| Score (default weights) | 80.8 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 900 ms | Inferred | — | — | Estimate for starting a stopped Machine plus the API round trip. Suspend/resume is materially faster; a cold create with an image pull is slower. | #fly-machines-cold_start_measured |
| Cold start (claimed) | 300 ms | Vendor-claimed | 2026-01-15 | https://fly.io/docs/machines/ | Fly quotes roughly 250–300 ms to start a stopped Machine. | #fly-machines-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-01-15 | https://fly.io/docs/machines/ | — | #fly-machines-isolation_tech |
| Root in guest | ● | Vendor-claimed | 2026-01-15 | https://fly.io/docs/machines/ | — | #fly-machines-root_access |
| Egress control | allowlist | Inferred | — | — | Private networking, egress-only configurations and per-app IP control all exist, but you assemble them yourself. | #fly-machines-egress_control |
| Max runtime | 1440 min | Inferred | — | — | No platform-imposed limit; Machines run until stopped. | #fly-machines-max_runtime |
| Persistent FS | ● | Vendor-claimed | 2026-01-15 | https://fly.io/docs/volumes/ | Fly Volumes are durable NVMe attached to a Machine. | #fly-machines-persistent_fs |
| Snapshot & fork | ◐ | Inferred | — | — | Volume snapshots and machine clone exist; no live memory fork. Suspend preserves memory state. | #fly-machines-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://fly.io/docs/machines/ | — | #fly-machines-custom_images |
| GPU | ● | Vendor-claimed | 2026-01-15 | https://fly.io/docs/gpus/ | — | #fly-machines-gpu |
| Runtimes | any-oci-image | Inferred | — | — | — | #fly-machines-language_runtimes |
| Preview URLs | ◐ | Inferred | — | — | Every app gets a fly.dev hostname, but per-sandbox public URLs are something you route yourself. | #fly-machines-preview_urls |
| Browser inside | ◐ | Inferred | — | — | Trivial to install, nothing supplied. | #fly-machines-browser_in_sandbox |
| File up/download | ◐ | Inferred | — | — | No file API. You use SSH, SFTP or a volume — fine for humans, awkward for agents. | #fly-machines-file_transfer_api |
| Sydney region | ● | Vendor-claimed | 2026-01-15 | https://fly.io/docs/reference/regions/ | syd. | #fly-machines-sydney_region |
| Concurrent limit | 500 sandboxes | Inferred | — | — | Org limits apply and are raised on request; the practical cap is your budget. | #fly-machines-max_concurrency |
| MCP server | ◐ | Community-reported | — | — | flyctl ships MCP support aimed at managing Fly itself rather than driving sandboxes. | #fly-machines-mcp_server |
| SDKs | rest-api, cli | Inferred | — | — | — | #fly-machines-sdk_languages |
| Streaming output | ◐ | Inferred | — | — | Logs stream and SSH exec works, but there is no exec-with-streaming primitive in the Machines API. | #fly-machines-streaming_stdout |
| Price / hour | $0.031 /hr | Vendor-claimed | 2026-07-23 | https://fly.io/docs/about/pricing/ | Read straight off the preset table rather than derived: shared-cpu-2x with 4 GB is listed at $0.0309/hr ($0.00000857/s, $22.22/mo) in the cheapest region. Performance CPUs cost several times more, and regional multipliers apply — Sydney is dearer than Amsterdam. | #fly-machines-price_per_hour |
| Meter | per-second | Vendor-claimed | 2026-01-15 | https://fly.io/docs/about/pricing/ | — | #fly-machines-billing_granularity |
| Idle cost | free-when-stopped | Vendor-claimed | 2026-01-15 | https://fly.io/docs/about/pricing/ | A stopped Machine costs nothing beyond its rootfs and volumes. | #fly-machines-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #fly-machines-github_stars |
| Funding | series-c-plus | Community-reported | — | — | — | #fly-machines-funding_stage |
| Shipped | 2022 | Inferred | — | — | — | #fly-machines-launched |
| Positioning | Hardware-virtualised containers that run anywhere, started and stopped over an API. | Inferred | — | — | — | #fly-machines-positioning |

**Verdict.** The best price-per-unit-of-isolation on this page by a wide margin, and the only mainstream option with a Sydney region. You pay for it in glue code: no file API, no exec streaming, no memory fork, no agent SDK. Budget a week to build the layer everyone else sells you.

**Pick it when**

- You need Australian or multi-region placement
- Cost per sandbox-hour matters more than SDK ergonomics
- You already run on Fly and can reuse the networking

### Blaxel {#blaxel}

Agent-first cloud claiming ~25 ms microVM boots from snapshots.

|  |  |
| --- | --- |
| Site | https://blaxel.ai |
| Docs | https://docs.blaxel.ai |
| Company | Blaxel |
| Founded | 2024 |
| Funding | Seed |
| Profile | https://toolweight.dev/tools/blaxel |
| Score (default weights) | 79.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 500 ms | Inferred | — | — | Estimate. The 25 ms figure is a snapshot restore on allocated hardware; the API round trip alone exceeds it. | #blaxel-cold_start_measured |
| Cold start (claimed) | 25 ms | Vendor-claimed | 2026-01-15 | https://blaxel.ai | The most aggressive claim in the category. | #blaxel-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-01-15 | https://docs.blaxel.ai | — | #blaxel-isolation_tech |
| Root in guest | ● | Inferred | — | — | — | #blaxel-root_access |
| Egress control | open | Inferred | — | — | — | #blaxel-egress_control |
| Max runtime | 1440 min | Inferred | — | — | No published hard cap. | #blaxel-max_runtime |
| Persistent FS | ◐ | Inferred | — | — | State survives snapshot and resume. | #blaxel-persistent_fs |
| Snapshot & fork | ● | Vendor-claimed | 2026-01-15 | https://docs.blaxel.ai | — | #blaxel-snapshot_fork |
| Custom images | ● | Inferred | — | — | — | #blaxel-custom_images |
| GPU | — | Unknown | — | — | — | #blaxel-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #blaxel-language_runtimes |
| Preview URLs | ● | Inferred | — | — | — | #blaxel-preview_urls |
| Browser inside | ◐ | Inferred | — | — | — | #blaxel-browser_in_sandbox |
| File up/download | ● | Inferred | — | — | — | #blaxel-file_transfer_api |
| Sydney region | ◐ | Inferred | — | — | Markets multi-region placement including Asia-Pacific; a dedicated Sydney region is not confirmed. | #blaxel-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | — | #blaxel-max_concurrency |
| MCP server | ● | Inferred | — | — | MCP hosting is part of the platform's agent story. | #blaxel-mcp_server |
| SDKs | python, typescript, cli | Inferred | — | — | — | #blaxel-sdk_languages |
| Streaming output | ● | Inferred | — | — | — | #blaxel-streaming_stdout |
| Price / hour | — | Unknown | — | — | Per-second compute pricing not published as a comparable hourly rate for a fixed shape. | #blaxel-price_per_hour |
| Meter | per-second | Inferred | — | — | — | #blaxel-billing_granularity |
| Idle cost | storage-only | Inferred | — | — | — | #blaxel-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #blaxel-github_stars |
| Funding | seed | Community-reported | — | — | — | #blaxel-funding_stage |
| Shipped | 2025 | Inferred | — | — | — | #blaxel-launched |
| Positioning | An agent-native cloud: sandboxes, agent hosting and a model gateway in one platform. | Inferred | — | — | — | #blaxel-positioning |

**Verdict.** The 25 ms claim is the purest example of why the measured column exists — a real number for a real operation that is not the one you care about. The wider platform is the actual pitch, and that is a lot of surface area to buy from a seed-stage company.

**Pick it when**

- You want sandboxes, agent hosting and MCP from one vendor
- Latency-sensitive workloads where you can keep a pool warm
- You are comfortable betting on an early-stage platform

### Daytona {#daytona}

Sub-second container sandboxes for agent workloads, from a team that built a dev-env manager.

|  |  |
| --- | --- |
| Site | https://daytona.io |
| Docs | https://www.daytona.io/docs |
| Repo | https://github.com/daytonaio/daytona |
| Company | Daytona |
| Founded | 2023 |
| Funding | Seed |
| Open source | No |
| Profile | https://toolweight.dev/tools/daytona |
| Score (default weights) | 79.4 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 350 ms | Inferred | — | — | Estimate. The 90 ms claim is a container start against a pre-pulled snapshot image, with no guest kernel to boot; add API scheduling and the client round trip. | #daytona-cold_start_measured |
| Cold start (claimed) | 90 ms | Vendor-claimed | 2026-01-15 | https://www.daytona.io | Marketed as sub-90 ms sandbox creation. | #daytona-cold_start_claimed |
| Isolation | container | Inferred | 2026-07-23 | https://northflank.com/blog/daytona-vs-e2b-ai-code-execution-sandboxes | Corrected from microvm. Daytona's own docs claim "complete isolation, a dedicated kernel, filesystem, network stack" but name no hypervisor anywhere, and describe the platform as built on OCI/Docker compatibility. Third-party analysis reports Docker/OCI containers sharing the host kernel as the default, with Kata Containers or Sysbox available only when explicitly configured. A sub-90 ms create is itself corroborating: that is container-start territory, not guest-kernel-boot territory. Marked inferred rather than vendor-claimed because it reconciles conflicting sources rather than reading off one. | #daytona-isolation_tech |
| Root in guest | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | — | #daytona-root_access |
| Egress control | allowlist | Vendor-claimed | 2026-07-23 | https://www.daytona.io/docs/en/network-limits/ | networkBlockAll gives a zero-egress sandbox and networkAllowList takes per-sandbox destination rules, so this genuinely earns the top rank. Two limits worth knowing: the allow list is IPv4 CIDR blocks only — no domains, unlike Vercel's firewall — and it caps at ten entries; changing policy on a running sandbox is gated to higher tiers. Sourced on re-audit; it was previously an unsourced inference sitting on a weight-9 preset field. | #daytona-egress_control |
| Max runtime | 1440 min | Inferred | — | — | No hard published ceiling; sandboxes stop on a configurable auto-stop interval. | #daytona-max_runtime |
| Persistent FS | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | Sandboxes stop and restart with their disk intact. | #daytona-persistent_fs |
| Snapshot & fork | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | — | #daytona-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | Declarative images or any registry image, pre-built into snapshots. | #daytona-custom_images |
| GPU | — | Unknown | — | — | GPU sandboxes have been discussed publicly; self-serve availability is unclear. | #daytona-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #daytona-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | — | #daytona-preview_urls |
| Browser inside | ◐ | Inferred | — | — | Computer-use images exist but are less mature than E2B Desktop. | #daytona-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | — | #daytona-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | US and EU only. | #daytona-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Tier-dependent, raised on request. | #daytona-max_concurrency |
| MCP server | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | First-party MCP server covering sandbox lifecycle and exec. | #daytona-mcp_server |
| SDKs | python, typescript, cli | Inferred | — | — | — | #daytona-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://www.daytona.io/docs | — | #daytona-streaming_stdout |
| Price / hour | $0.17 /hr | Inferred | 2026-07-23 | https://northflank.com/blog/ai-sandbox-pricing | Converted like every other per-second vendor here: $0.0504/vCPU-hr and $0.0162/GiB-hr give 2 × 0.0504 + 4 × 0.0162 = $0.166. Disk is billed separately and excluded, as it is for everyone. Caveat on the sourcing: Daytona's own pricing page is JavaScript-rendered and could not be read directly, so these rates come from third-party comparisons that agree with each other — identical, as it happens, to E2B's published rates. Treat the figure as a good estimate rather than a quote, and re-check it at the vendor before budgeting. | #daytona-price_per_hour |
| Meter | per-second | Vendor-claimed | 2026-01-15 | https://www.daytona.io/pricing | — | #daytona-billing_granularity |
| Idle cost | storage-only | Inferred | — | — | Stopped sandboxes bill disk only. | #daytona-idle_billing |
| GitHub stars | — | Unknown | 2026-07-23 | https://www.daytona.io/dotfiles/updates/daytona-is-going-closed-source | Was 21,000 for daytonaio/daytona. Daytona closed its source on 11 June 2026; the repository stays public but is no longer maintained, so its star count now measures a frozen artefact rather than the product. Nulled per this field's rule for closed-source products. | #daytona-github_stars |
| Funding | seed | Community-reported | — | — | — | #daytona-funding_stage |
| Shipped | 2025 | Inferred | — | — | Company is older; the sandbox product dates from the 2025 repositioning. | #daytona-launched |
| Positioning | Secure, elastic infrastructure for running AI-generated code. | Inferred | — | — | — | #daytona-positioning |

**Verdict.** The most credible challenger to E2B on ergonomics — faster in the common case, and the best first-party MCP story in the roster — with one caveat large enough to change the shortlist. Daytona runs containers on a shared host kernel, not the microVMs its speed peers run, and its own documentation talks about a "dedicated kernel" without ever naming a hypervisor. For your own agent's code that is a non-issue and the boot time is a real advantage. For genuinely untrusted third-party code it is the wrong end of the isolation axis, and the sub-90 ms number everyone quotes is a consequence of that choice rather than an achievement independent of it. The second caveat is churn, now compounded: product, docs and pricing have all moved substantially inside eighteen months, and the source closed in June 2026, so the self-host escape hatch that used to backstop those changes is gone.

**Pick it when**

- Boot time is your headline metric and the code is your own
- You want an MCP server maintained by the vendor
- You can tolerate a fast-moving, now closed-source product surface

### Runloop {#runloop}

Devboxes, blueprints and eval harnesses aimed at teams training coding agents.

|  |  |
| --- | --- |
| Site | https://runloop.ai |
| Docs | https://docs.runloop.ai |
| Company | Runloop |
| Founded | 2023 |
| Funding | Seed |
| Profile | https://toolweight.dev/tools/runloop |
| Score (default weights) | 79.0 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 800 ms | Inferred | — | — | Estimate for a devbox created from an existing blueprint or snapshot. | #runloop-cold_start_measured |
| Cold start (claimed) | 1 s | Vendor-claimed | 2026-01-15 | https://docs.runloop.ai | Marketed as sub-second devbox boot from a snapshot. Recorded at 1000 ms, the literal ceiling of "sub-second", which is this page's convention for an unquantified claim of that shape — the same reading Modal's identical phrasing gets. It was previously recorded as 500, a favourable mid-reading no other vendor received. | #runloop-cold_start_claimed |
| Isolation | microvm | Inferred | — | — | — | #runloop-isolation_tech |
| Root in guest | ● | Inferred | — | — | — | #runloop-root_access |
| Egress control | open | Inferred | — | — | No documented per-devbox allowlist. | #runloop-egress_control |
| Max runtime | 1440 min | Inferred | — | — | Devboxes are long-lived with a configurable idle shutdown. | #runloop-max_runtime |
| Persistent FS | ● | Inferred | — | — | Devboxes persist across suspend and resume. | #runloop-persistent_fs |
| Snapshot & fork | ● | Vendor-claimed | 2026-01-15 | https://docs.runloop.ai | Snapshots and blueprints are the core primitive. | #runloop-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://docs.runloop.ai | Blueprints build from a Dockerfile or setup commands. | #runloop-custom_images |
| GPU | ○ | Inferred | — | — | — | #runloop-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #runloop-language_runtimes |
| Preview URLs | ● | Inferred | — | — | — | #runloop-preview_urls |
| Browser inside | ◐ | Inferred | — | — | — | #runloop-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://docs.runloop.ai | — | #runloop-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | US only. | #runloop-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Plan-dependent; approximate. | #runloop-max_concurrency |
| MCP server | ◐ | Inferred | — | — | — | #runloop-mcp_server |
| SDKs | python, typescript, rest-api, cli | Inferred | — | — | — | #runloop-sdk_languages |
| Streaming output | ● | Inferred | — | — | — | #runloop-streaming_stdout |
| Price / hour | — | Unknown | — | — | Tier- and usage-based pricing that is not published in a form converting cleanly to a 2 vCPU / 4 GB hour. | #runloop-price_per_hour |
| Meter | per-second | Inferred | — | — | — | #runloop-billing_granularity |
| Idle cost | storage-only | Inferred | — | — | Suspended devboxes bill storage. | #runloop-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #runloop-github_stars |
| Funding | seed | Community-reported | — | — | — | #runloop-funding_stage |
| Shipped | 2024 | Inferred | — | — | — | #runloop-launched |
| Positioning | Infrastructure and evaluation harnesses for teams building coding agents. | Inferred | — | — | — | #runloop-positioning |

**Verdict.** The only provider here built around evaluation rather than production traffic — blueprints, snapshots and public benchmark scaffolding are the product and the sandbox is the substrate. Overkill if you just need to run some Python; the obvious pick if you measure an agent's pass rate every night.

**Pick it when**

- Running SWE-bench-style evaluation loops at scale
- Generating training data from reproducible environments
- You want a vendor whose roadmap targets agent researchers

### Modal {#modal}

Serverless Python compute with a Sandbox API bolted onto a GPU-first platform.

|  |  |
| --- | --- |
| Site | https://modal.com |
| Docs | https://modal.com/docs/guide/sandbox |
| Company | Modal |
| Founded | 2021 |
| Funding | Series B |
| Profile | https://toolweight.dev/tools/modal |
| Score (default weights) | 77.5 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 1.5 s | Inferred | — | — | Estimate for a cached CPU image with no warm container. Large images and GPU attachment push this considerably higher. | #modal-cold_start_measured |
| Cold start (claimed) | 1 s | Vendor-claimed | 2026-01-15 | https://modal.com/docs/guide/cold-start | Marketed as sub-second container starts. Recorded at 1000 ms, the literal ceiling of "sub-second" — this page's convention for a claim of that shape. | #modal-cold_start_claimed |
| Isolation | gvisor | Vendor-claimed | 2026-01-15 | https://modal.com/docs/guide/security | — | #modal-isolation_tech |
| Root in guest | ● | Inferred | — | — | Root inside the sandbox; no host device access. | #modal-root_access |
| Egress control | proxy-logged | Inferred | — | — | Outbound is open by default; proxy and blocking options exist but are not a per-sandbox allowlist. | #modal-egress_control |
| Max runtime | 1440 min | Vendor-claimed | 2026-01-15 | https://modal.com/docs/guide/timeouts | 24 h function timeout ceiling. | #modal-max_runtime |
| Persistent FS | ● | Vendor-claimed | 2026-01-15 | https://modal.com/docs/guide/volumes | Modal Volumes mount into sandboxes and outlive them. | #modal-persistent_fs |
| Snapshot & fork | ◐ | Inferred | — | — | Memory snapshots exist mainly as a cold-start optimisation; forking a live sandbox is not the headline primitive it is at CodeSandbox. | #modal-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://modal.com/docs/guide/images | Images are defined in Python or pulled from a registry. | #modal-custom_images |
| GPU | ● | Vendor-claimed | 2026-01-15 | https://modal.com/pricing | Self-serve H100, A100, L40S and others. | #modal-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #modal-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://modal.com/docs | — | #modal-preview_urls |
| Browser inside | ◐ | Inferred | — | — | Chromium runs fine in a custom image; no supported browser template. | #modal-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://modal.com/docs | — | #modal-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | US and EU regions. | #modal-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Default account limits sit in the low hundreds of containers and are raised on request. | #modal-max_concurrency |
| MCP server | ◐ | Inferred | — | — | Examples and community servers rather than a supported product. | #modal-mcp_server |
| SDKs | python, cli | Inferred | — | — | — | #modal-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://modal.com/docs | — | #modal-streaming_stdout |
| Price / hour | $0.238 /hr | Inferred | 2026-07-23 | https://modal.com/pricing | Derived from the Sandbox rate card: $0.00003942/core/s and $0.00000667/GiB/s. Modal bills per physical core, not per vCPU, so this column's 2 vCPU shape is one core: 0.00003942 × 3600 = $0.142, plus 4 × 0.00000667 × 3600 = $0.096, totalling $0.238. Billing the 2 vCPU as 2 cores — the obvious misreading — overstates Modal by about 55%. Expensive per CPU-hour, competitive per GPU-hour. | #modal-price_per_hour |
| Meter | per-second | Vendor-claimed | 2026-01-15 | https://modal.com/pricing | — | #modal-billing_granularity |
| Idle cost | active-cpu-only | Inferred | — | — | Containers scale to zero; a stopped sandbox is not billed. | #modal-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #modal-github_stars |
| Funding | series-b | Community-reported | — | — | Raised a large Series B in 2025. | #modal-funding_stage |
| Shipped | 2024 | Inferred | — | — | The platform is older; the Sandbox API is the newer surface. | #modal-launched |
| Positioning | Serverless compute for AI teams, with sandboxes as one primitive. | Inferred | — | — | — | #modal-positioning |

**Verdict.** Buy Modal for the GPU story and the Python ergonomics, not for boot time — it is a serverless compute platform that grew a Sandbox API, and it shows. If your agent needs to run inference next to the code it just generated, nothing else here is close.

**Pick it when**

- The sandbox needs a GPU on a self-serve plan
- Your team is Python-first and already writes Modal functions
- One platform for batch ML and untrusted execution

### Vercel Sandbox {#vercel-sandbox}

Firecracker microVMs for running untrusted code from inside a Vercel deployment.

|  |  |
| --- | --- |
| Site | https://vercel.com/docs/vercel-sandbox |
| Docs | https://vercel.com/docs/vercel-sandbox |
| Company | Vercel |
| Founded | 2015 |
| Funding | Series F |
| Profile | https://toolweight.dev/tools/vercel-sandbox |
| Score (default weights) | 74.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 1.8 s | Inferred | — | — | Estimate for create-to-first-output on a stock Node base image. | #vercel-sandbox-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | Vercel says sandboxes "start in milliseconds" but publishes no figure, so there is nothing to record in this column. | #vercel-sandbox-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/concepts | "Each sandbox runs in its own Firecracker microVM with a dedicated kernel" — the same infrastructure as Vercel Functions. | #vercel-sandbox-isolation_tech |
| Root in guest | ● | Vendor-claimed | 2026-01-15 | https://vercel.com/docs/vercel-sandbox | sudo is available in the sandbox. | #vercel-sandbox-root_access |
| Egress control | allowlist | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/concepts/firewall | The sandbox firewall takes three modes, changeable on a running sandbox: allow-all (the default), deny-all including DNS, and a user-defined policy that denies by default and allows a list of domains (wildcards supported) or address ranges. It also supports credential brokering and forwarding to a proxy you control. This is a genuine per-sandbox allowlist, and among the strongest egress stories in the roster. | #vercel-sandbox-egress_control |
| Max runtime | 1440 min | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/pricing | 24 h maximum duration on Pro and Enterprise; 45 minutes on Hobby. This column records the paid-plan figure. The default timeout is still 5 minutes and must be raised explicitly at create time or via extendTimeout(). | #vercel-sandbox-max_runtime |
| Persistent FS | ◐ | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/concepts/persistent-sandboxes | Persistence is now the default: a sandbox snapshots its filesystem when a session stops and the next session resumes from it, billed as Snapshot Storage at $0.08/GB-month. Partial rather than yes because that is state surviving stop/resume rather than a durable volume — deleting the sandbox deletes its snapshots. Drives, which are the reattachable-volume shape, are in beta. | #vercel-sandbox-persistent_fs |
| Snapshot & fork | ◐ | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/concepts/snapshots | Snapshots exist and Sandbox.fork spawns a child sandbox from another's current state, so branching works. Partial rather than yes because the snapshot captures the filesystem and installed packages, not a live memory image with the process tree intact — you re-run the processes, you do not resume them mid-flight. | #vercel-sandbox-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/concepts/images | Built-in Node and Python runtimes, or your own Docker image pushed to the Vercel Container Registry, or a saved snapshot. The fixed-runtimes-only limitation this row used to record no longer holds. | #vercel-sandbox-custom_images |
| GPU | ○ | Inferred | — | — | — | #vercel-sandbox-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #vercel-sandbox-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://vercel.com/docs/vercel-sandbox | — | #vercel-sandbox-preview_urls |
| Browser inside | ○ | Inferred | — | — | — | #vercel-sandbox-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://vercel.com/docs/vercel-sandbox | — | #vercel-sandbox-file_transfer_api |
| Sydney region | ○ | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/pricing | Sandboxes provision in iad1 only — a single US region, not merely US-first. | #vercel-sandbox-sydney_region |
| Concurrent limit | 2,000 sandboxes | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/pricing | Published limits: Hobby 10, Pro 2,000, Enterprise 2,000+. This column takes the standard paid tier, so 2,000. Note this page clamps concurrency scoring at 1,000, so the surplus earns nothing — but the recorded figure is the published one. A separate rate limit caps vCPU allocation at 200 vCPUs/minute on Pro, which binds first for bursty creates. | #vercel-sandbox-max_concurrency |
| MCP server | ○ | Inferred | — | — | No first-party sandbox MCP server. | #vercel-sandbox-mcp_server |
| SDKs | typescript | Inferred | — | — | — | #vercel-sandbox-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://vercel.com/docs/vercel-sandbox | — | #vercel-sandbox-streaming_stdout |
| Price / hour | $0.341 /hr | Inferred | 2026-07-23 | https://vercel.com/docs/sandbox/pricing | Worst case, derived from the current Sandbox rate card: Active CPU $0.128/vCPU-hr and Provisioned Memory $0.0212/GB-hr give 2 × 0.128 + 4 × 0.0212 = $0.341. This assumes both vCPUs pinned for the full hour; because Active CPU excludes time blocked on I/O, a sandbox waiting on a model costs a small fraction of it. The previous $0.30 here implied $0.0106/GB-hr, which is Fluid Compute's memory rate rather than Sandbox's. | #vercel-sandbox-price_per_hour |
| Meter | per-second | Vendor-claimed | 2026-01-15 | https://vercel.com/docs/vercel-sandbox | — | #vercel-sandbox-billing_granularity |
| Idle cost | active-cpu-only | Vendor-claimed | 2026-07-23 | https://vercel.com/docs/sandbox/pricing | "Time spent waiting for I/O (such as network requests, database queries, or AI model calls) does not count toward Active CPU." The most agent-friendly meter here. Provisioned memory still bills for the whole session, so idle is cheap rather than free. | #vercel-sandbox-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #vercel-sandbox-github_stars |
| Funding | series-c-plus | Community-reported | — | — | — | #vercel-sandbox-funding_stage |
| Shipped | 2025 | Vendor-claimed | 2026-01-15 | https://vercel.com/changelog | — | #vercel-sandbox-launched |
| Positioning | Run untrusted code from your Vercel app in an ephemeral microVM. | Inferred | — | — | — | #vercel-sandbox-positioning |

**Verdict.** No longer the deliberately narrow product it launched as, and this row was wrong about it for months. Persistence is now the default, snapshots and fork are shipped and billed, custom images come from Vercel's own registry, sessions run 24 h on a paid plan, and the egress firewall — deny-all or a per-sandbox domain allowlist, updatable while the sandbox runs — is one of the better isolation stories here rather than an omission. What remains genuinely narrow is placement: iad1 and nothing else, which rules it out for data residency and adds a fixed round trip from anywhere that is not the US east coast. The active-CPU meter is still the quiet advantage, because an agent session blocked on inference costs a fraction of the headline rate.

**Pick it when**

- An app-builder or code-runner inside a Vercel deployment
- Agent sessions that mostly wait on a model, where active-CPU billing pays off
- You need a per-sandbox egress allowlist without building it yourself

### E2B {#e2b}

Open-source Firecracker sandboxes with Python and TypeScript SDKs for AI agents.

|  |  |
| --- | --- |
| Site | https://e2b.dev |
| Docs | https://e2b.dev/docs |
| Repo | https://github.com/e2b-dev/E2B |
| Company | E2B |
| Founded | 2023 |
| Funding | Series A |
| Open source | Yes (Apache-2.0) |
| Profile | https://toolweight.dev/tools/e2b |
| Score (default weights) | 74.4 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 400 ms | Inferred | — | — | Estimate for create-to-first-output from a client in the same region. The vendor times VM boot alone; the SDK round trip adds most of the rest. | #e2b-cold_start_measured |
| Cold start (claimed) | 200 ms | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs | Marketed as roughly 150–200 ms to start a sandbox. | #e2b-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs | Firecracker. | #e2b-isolation_tech |
| Root in guest | ● | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs | — | #e2b-root_access |
| Egress control | open | Inferred | — | — | Full outbound by default; no documented per-sandbox allowlist. | #e2b-egress_control |
| Max runtime | 1440 min | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs/sandbox | Default timeout is 5 minutes, extendable to 24 h on paid plans. | #e2b-max_runtime |
| Persistent FS | ◐ | Inferred | — | — | Filesystem survives pause/resume; there is no durable volume to reattach to a fresh sandbox. | #e2b-persistent_fs |
| Snapshot & fork | ◐ | Inferred | — | — | Pause and resume are stable; forking a paused sandbox is newer. | #e2b-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs/sandbox-template | Templates are Dockerfiles built by the E2B CLI. | #e2b-custom_images |
| GPU | ○ | Inferred | — | — | — | #e2b-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #e2b-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs | getHost(port) returns a public hostname. | #e2b-preview_urls |
| Browser inside | ● | Vendor-claimed | 2026-01-15 | https://github.com/e2b-dev/desktop | The E2B Desktop SDK ships a Chromium image with a stream. | #e2b-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs | — | #e2b-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | US and EU regions only. | #e2b-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Approximate paid-tier default; the free tier is far lower and enterprise is negotiable. | #e2b-max_concurrency |
| MCP server | ◐ | Community-reported | — | — | Several community MCP servers wrap the SDK; no single canonical first-party one. | #e2b-mcp_server |
| SDKs | python, typescript, cli | Inferred | — | — | — | #e2b-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://e2b.dev/docs | — | #e2b-streaming_stdout |
| Price / hour | $0.17 /hr | Inferred | — | — | Approximate: 2 vCPU + 4 GB at published per-second vCPU and RAM rates. Paid tiers also carry a monthly base fee. | #e2b-price_per_hour |
| Meter | per-second | Vendor-claimed | 2026-01-15 | https://e2b.dev/pricing | — | #e2b-billing_granularity |
| Idle cost | storage-only | Inferred | — | — | Paused sandboxes bill snapshot storage. | #e2b-idle_billing |
| GitHub stars | 9,000 | Community-reported | — | — | e2b-dev/E2B, rounded. | #e2b-github_stars |
| Funding | series-a | Community-reported | 2026-07-23 | https://www.insightpartners.com/ideas/e2b-raises-a-21m-series-a-to-offer-cloud-for-ai-agents-to-fortune-100/ | $21M Series A led by Insight Partners, announced July 2025. Announced by the lead investor rather than E2B, hence community rather than vendor-claimed. | #e2b-funding_stage |
| Shipped | 2023 | Inferred | — | — | — | #e2b-launched |
| Positioning | Open-source infrastructure for running AI-generated code. | Inferred | — | — | — | #e2b-positioning |

**Verdict.** Still the safest default: the SDKs are the most complete, templates are just Dockerfiles, and the Apache licence means a bad pricing decision by E2B is an inconvenience rather than a migration. It is no longer the fastest, and the monthly base fee makes it a poor fit for hobby-scale traffic.

**Pick it when**

- You want the category default with a real self-host escape hatch
- Your environments are already Dockerfiles
- Python code-interpreter workloads at steady volume

### CodeSandbox SDK {#codesandbox-sdk}

Firecracker VMs with memory snapshots, from the online IDE, now owned by Together AI.

|  |  |
| --- | --- |
| Site | https://codesandbox.io/docs/sdk |
| Docs | https://codesandbox.io/docs/sdk |
| Company | Together AI |
| Founded | 2017 |
| Funding | Acquired |
| Profile | https://toolweight.dev/tools/codesandbox-sdk |
| Score (default weights) | 74.4 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 1.2 s | Inferred | — | — | Estimate for a cold create. The vendor's ~1 s figure is a different operation — resuming an existing hibernated VM — so the near-parity between the two columns here is the least defensible estimate on the page: every other provider whose claim describes a snapshot restore lands 2–20× above it. Flagged rather than adjusted, because moving the number to fit the pattern would be inventing one. The harness settles this row first. | #codesandbox-sdk-cold_start_measured |
| Cold start (claimed) | 1 s | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | Marketed as resuming a hibernated VM in about a second, processes intact. | #codesandbox-sdk-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | Firecracker. | #codesandbox-sdk-isolation_tech |
| Root in guest | ● | Inferred | — | — | — | #codesandbox-sdk-root_access |
| Egress control | open | Inferred | — | — | — | #codesandbox-sdk-egress_control |
| Max runtime | 1440 min | Inferred | — | — | VMs hibernate on an inactivity timeout rather than hitting a hard runtime cap. | #codesandbox-sdk-max_runtime |
| Persistent FS | ● | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | Disk and memory both persist across hibernation. | #codesandbox-sdk-persistent_fs |
| Snapshot & fork | ● | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | The most mature memory-snapshot-and-fork implementation in this roster. | #codesandbox-sdk-snapshot_fork |
| Custom images | ● | Inferred | — | — | Docker-based environment definitions. | #codesandbox-sdk-custom_images |
| GPU | ○ | Inferred | — | — | — | #codesandbox-sdk-gpu |
| Runtimes | python, javascript-typescript, bash, any-oci-image | Inferred | — | — | — | #codesandbox-sdk-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | — | #codesandbox-sdk-preview_urls |
| Browser inside | ◐ | Inferred | — | — | — | #codesandbox-sdk-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | — | #codesandbox-sdk-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | US and EU clusters. | #codesandbox-sdk-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Tier-dependent; approximate. | #codesandbox-sdk-max_concurrency |
| MCP server | ○ | Inferred | — | — | — | #codesandbox-sdk-mcp_server |
| SDKs | typescript, python | Inferred | — | — | — | #codesandbox-sdk-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://codesandbox.io/docs/sdk | — | #codesandbox-sdk-streaming_stdout |
| Price / hour | — | Unknown | — | — | Credit-based pricing per VM tier rather than a published hourly rate for a given vCPU/RAM shape. Historically among the cheaper options; model it against your own session profile. | #codesandbox-sdk-price_per_hour |
| Meter | per-second | Inferred | — | — | Credits are consumed while a VM is awake. | #codesandbox-sdk-billing_granularity |
| Idle cost | storage-only | Inferred | — | — | Hibernated VMs stop consuming compute credits. | #codesandbox-sdk-idle_billing |
| GitHub stars | 13,000 | Community-reported | — | — | codesandbox/codesandbox-client, rounded — the IDE, not the SDK. | #codesandbox-sdk-github_stars |
| Funding | acquired | Community-reported | — | — | Acquired by Together AI in 2025. | #codesandbox-sdk-funding_stage |
| Shipped | 2024 | Inferred | — | — | — | #codesandbox-sdk-launched |
| Positioning | The VM infrastructure behind CodeSandbox, sold as an SDK. | Inferred | — | — | — | #codesandbox-sdk-positioning |

**Verdict.** If your workload branches — try five patches from one prepared state — this is the best-engineered snapshot implementation available, because CodeSandbox spent years being punished for slow resumes. The open question is roadmap: it is now a component of Together AI's stack rather than a company's whole product.

**Pick it when**

- You fork one prepared environment many times
- Long-lived per-user environments that hibernate between sessions
- You need processes and memory preserved, not just the disk

### Namespace {#namespace}

Fast microVM instances and CI runners with instant snapshots and cached builds.

|  |  |
| --- | --- |
| Site | https://namespace.so |
| Docs | https://namespace.so/docs |
| Company | Namespace Labs |
| Founded | 2022 |
| Funding | Seed |
| Profile | https://toolweight.dev/tools/namespace |
| Score (default weights) | 72.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 1.5 s | Inferred | — | — | Estimate for an instance created from a cached snapshot; CI runner starts are the workload this is tuned for. | #namespace-cold_start_measured |
| Cold start (claimed) | 800 ms | Vendor-claimed | 2026-07-23 | https://namespace.so/compute/sandbox | Namespace publishes an actual boot timeline rather than a slogan: microVM allocated 0.1 s, kernel booted 0.2 s, network ready 0.3 s, custom image loaded 0.6 s, agent connected 0.8 s. The end of that timeline is the closest thing to this column's definition anyone here publishes, so 800 ms is recorded. Previously 1000 with no published figure behind it. | #namespace-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-07-23 | https://namespace.so/compute/sandbox | "Every sandbox runs in its own microVM. This isn't container isolation, it's a virtual machine with a dedicated kernel." Promoted from inferred now that the vendor states it explicitly. | #namespace-isolation_tech |
| Root in guest | ● | Inferred | — | — | — | #namespace-root_access |
| Egress control | proxy-logged | Inferred | — | — | Egress proxying exists mainly to serve build caching. | #namespace-egress_control |
| Max runtime | 1440 min | Inferred | — | — | — | #namespace-max_runtime |
| Persistent FS | ● | Inferred | — | — | Volumes and cache volumes persist between runs. | #namespace-persistent_fs |
| Snapshot & fork | ● | Vendor-claimed | 2026-01-15 | https://namespace.so/docs | Instance snapshots are a headline feature. | #namespace-snapshot_fork |
| Custom images | ● | Inferred | — | — | — | #namespace-custom_images |
| GPU | — | Unknown | — | — | — | #namespace-gpu |
| Runtimes | any-oci-image | Inferred | — | — | — | #namespace-language_runtimes |
| Preview URLs | ◐ | Inferred | — | — | — | #namespace-preview_urls |
| Browser inside | ◐ | Inferred | — | — | Browser images are common in CI use; nothing sandbox-specific is provided. | #namespace-browser_in_sandbox |
| File up/download | ◐ | Inferred | — | — | — | #namespace-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | US and EU. | #namespace-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Plan-dependent. | #namespace-max_concurrency |
| MCP server | ○ | Inferred | — | — | — | #namespace-mcp_server |
| SDKs | go, rest-api, cli | Inferred | — | — | — | #namespace-sdk_languages |
| Streaming output | ● | Inferred | — | — | — | #namespace-streaming_stdout |
| Price / hour | — | Unknown | — | — | Priced per instance shape and per minute of runner time; not published as a directly comparable hourly rate. | #namespace-price_per_hour |
| Meter | per-minute | Inferred | — | — | — | #namespace-billing_granularity |
| Idle cost | free-when-stopped | Inferred | — | — | — | #namespace-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #namespace-github_stars |
| Funding | seed | Community-reported | — | — | — | #namespace-funding_stage |
| Shipped | 2023 | Inferred | — | — | — | #namespace-launched |
| Positioning | Fast ephemeral compute for CI, builds and remote development. | Inferred | — | — | — | #namespace-positioning |

**Verdict.** Sold to CI teams, useful to agent teams for the same reason: snapshotted microVMs with genuinely good caching. There is no agent SDK and no MCP server, so it competes with Fly rather than E2B — worth a look mainly if your builds already run here.

**Pick it when**

- You already use Namespace for CI runners
- Build-cache-heavy environments that are slow to reconstruct
- You want infrastructure primitives rather than an agent SDK

### Islo {#islo}

Per-agent isolated cloud sandboxes with enterprise policy controls, from Incredibuild.

|  |  |
| --- | --- |
| Site | https://islo.dev |
| Company | Incredibuild |
| Profile | https://toolweight.dev/tools/islo |
| Score (default weights) | 65.8 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | — | Unknown | — | — | toolweight has not measured Islo, and the comparison table it appears in publishes no boot figure for it. | #islo-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | Absent from the "<500ms time to VM-ready" row of a competitor's table, which is not the same as Islo claiming anything either way. | #islo-cold_start_claimed |
| Isolation | — | Unknown | — | — | The table claims Docker inside the VM but names no hypervisor or isolation technology. Islo markets isolation heavily; none of that detail is in this source. | #islo-isolation_tech |
| Root in guest | ● | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Docker inside the VM" row: a Docker daemon in the guest implies root. The table claims Docker, not root. Transcribed from box's comparison table — a competitor's chart, not Islo's own documentation — and not verified by toolweight. | #islo-root_access |
| Egress control | — | Unknown | — | — | Not a row in the table, which is the awkward part: policy control over what an agent can reach is Islo's headline pitch, and this source does not test it. | #islo-egress_control |
| Max runtime | — | Unknown | — | — | The "No session cap / runs 24/7" row is a marketing statement in a competitor's chart, not a runtime ceiling Islo publishes. Left unknown rather than awarded this page's 24 h maximum. | #islo-max_runtime |
| Persistent FS | — | Unknown | — | — | Not a row in the table. | #islo-persistent_fs |
| Snapshot & fork | — | Unknown | — | — | Islo is absent from both the "Fast disk snapshots / branching" and "Process fork" rows. A rival declining to tick a box for a competitor is not the table addressing the field, so this is recorded as nothing rather than as a no — the previous "no" scored Islo zero on a weight-8 field on a competitor's say-so. The asymmetry is deliberate: box's and ascii's own absence from the process-fork row is credited, because a vendor conceding a gap in its own product is evidence and a vendor asserting a gap in someone else's is not. | #islo-snapshot_fork |
| Custom images | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from "BYO repos + arbitrary setup script" — a base extended by a setup script, this field's partial. The mapping is ours. From a competitor's table, unverified. | #islo-custom_images |
| GPU | — | Unknown | — | — | Not a row in the table. | #islo-gpu |
| Runtimes | — | Unknown | — | — | Not a row in the table. | #islo-language_runtimes |
| Preview URLs | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from two rows that are not about preview URLs — "Dedicated IPv4 per VM" and "Full TCP/UDP + BYO domain": reachable ports on a domain you own rather than a first-party HTTPS URL from the API. The mapping is ours. Competitor's table, unverified. | #islo-preview_urls |
| Browser inside | — | Unknown | — | — | Not a row in the table. | #islo-browser_in_sandbox |
| File up/download | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "SSH access" row: scp and sftp follow from SSH, and CLI-only access is this field's partial. No first-party file API is described. Competitor's table, unverified. | #islo-file_transfer_api |
| Sydney region | — | Unknown | — | — | The table says nothing about regions. | #islo-sydney_region |
| Concurrent limit | — | Unknown | — | — | Absent from the "1000+ concurrent VMs ergonomically" row; no figure is given. | #islo-max_concurrency |
| MCP server | — | Unknown | — | — | Not a row in the table. | #islo-mcp_server |
| SDKs | — | Unknown | — | — | Not a row in the table. | #islo-sdk_languages |
| Streaming output | — | Unknown | — | — | Not a row in the table. | #islo-streaming_stdout |
| Price / hour | — | Unknown | — | — | No rate for a comparable vCPU/RAM shape has been verified from Islo directly. | #islo-price_per_hour |
| Meter | — | Unknown | — | — | Islo is absent from the "Flat pricing" row, which implies a meter rather than a flat fee but does not say what the meter is. Left unknown rather than guessed. | #islo-billing_granularity |
| Idle cost | — | Unknown | — | — | Not a row in the table. | #islo-idle_billing |
| GitHub stars | — | Unknown | — | — | — | #islo-github_stars |
| Funding | — | Unknown | — | — | — | #islo-funding_stage |
| Shipped | — | Unknown | — | — | — | #islo-launched |
| Positioning | An isolated cloud environment per coding agent, with enterprise policy control over what it can reach. | Vendor-claimed | 2026-07-23 | https://islo.dev | Paraphrased from Incredibuild's own launch material. The capability cells on this row, unlike this one, come from a competitor's comparison table. | #islo-positioning |

**Verdict.** The enterprise-shaped entry in this group and the one this source serves worst. Islo's pitch is governance — an isolated environment per agent, with policy over which repos, systems and secrets it can touch — and the competitor's table it appears in has no column for any of that, so the row shows a capable long-running VM and nothing about the thing Islo is actually sold on. Credited with BYO repos, SSH, Docker, a dedicated IPv4 and full TCP/UDP. Not denied snapshots and forking: the chart simply omits Islo from those rows, which is a competitor declining to tick a box rather than a finding, so those cells are unknown here. Verify from Incredibuild's own documentation before shortlisting.

**Pick it when**

- Central policy control over what each agent can reach
- Enterprise teams that must govern agent identity and access
- You are already inside Incredibuild's SDLC platform

### Freestyle {#freestyle}

Run untrusted JavaScript and full dev servers, with git hosting and domains built in.

|  |  |
| --- | --- |
| Site | https://freestyle.sh |
| Docs | https://docs.freestyle.sh |
| Company | Freestyle |
| Founded | 2024 |
| Funding | Seed |
| Profile | https://toolweight.dev/tools/freestyle |
| Score (default weights) | 65.5 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 700 ms | Inferred | — | — | Estimate for the code-execution API; dev servers with a repo checkout take considerably longer. | #freestyle-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | No consistently published figure. | #freestyle-cold_start_claimed |
| Isolation | microvm | Inferred | — | — | — | #freestyle-isolation_tech |
| Root in guest | ◐ | Inferred | — | — | Dev servers give you a shell; the execute API does not. | #freestyle-root_access |
| Egress control | allowlist | Inferred | — | — | Network access for executed code is opt-in per call. | #freestyle-egress_control |
| Max runtime | 60 min | Inferred | — | — | Execution calls are short; dev servers persist while in use. | #freestyle-max_runtime |
| Persistent FS | ● | Inferred | — | — | Repos are hosted as git, which is the persistence layer. | #freestyle-persistent_fs |
| Snapshot & fork | ◐ | Inferred | — | — | Git branching substitutes for VM forking. | #freestyle-snapshot_fork |
| Custom images | ○ | Inferred | — | — | Managed runtime rather than arbitrary images. | #freestyle-custom_images |
| GPU | ○ | Inferred | — | — | — | #freestyle-gpu |
| Runtimes | javascript-typescript, python | Inferred | — | — | — | #freestyle-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://docs.freestyle.sh | Dev server previews and custom domains are core to the product. | #freestyle-preview_urls |
| Browser inside | ○ | Inferred | — | — | — | #freestyle-browser_in_sandbox |
| File up/download | ● | Inferred | — | — | Filesystem and git APIs. | #freestyle-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | — | #freestyle-sydney_region |
| Concurrent limit | — | Unknown | — | — | — | #freestyle-max_concurrency |
| MCP server | ◐ | Inferred | — | — | — | #freestyle-mcp_server |
| SDKs | typescript, rest-api | Inferred | — | — | — | #freestyle-sdk_languages |
| Streaming output | ● | Inferred | — | — | — | #freestyle-streaming_stdout |
| Price / hour | — | Unknown | — | — | Priced per dev-server hour and per execution; no comparable vCPU/RAM rate is published. | #freestyle-price_per_hour |
| Meter | per-request | Inferred | — | — | Executions are per-call; dev servers are metered by uptime. | #freestyle-billing_granularity |
| Idle cost | storage-only | Inferred | — | — | — | #freestyle-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #freestyle-github_stars |
| Funding | seed | Community-reported | — | — | — | #freestyle-funding_stage |
| Shipped | 2024 | Inferred | — | — | — | #freestyle-launched |
| Positioning | The backend for AI app builders: run code, host git, serve previews, attach domains. | Inferred | — | — | — | #freestyle-positioning |

**Verdict.** Not a general sandbox and not pretending to be. If you are building a Lovable-shaped product, Freestyle collapses four vendors into one and the preview-and-domain plumbing alone justifies it. For anything outside JavaScript app-building it is the wrong shape.

**Pick it when**

- Building an AI app builder with live previews
- You want git hosting and custom domains bundled with execution
- JavaScript and TypeScript workloads only

### exe.dev {#exe-dev}

Persistent VMs you SSH into, with root, apt and systemd, on a flat monthly plan.

|  |  |
| --- | --- |
| Site | https://exe.dev |
| Docs | https://exe.dev/sandbox |
| Company | exe.dev |
| Profile | https://toolweight.dev/tools/exe-dev |
| Score (default weights) | 64.9 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | — | Unknown | — | — | toolweight has not measured exe.dev, and the comparison table it appears in publishes no boot figure for it. | #exe-dev-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | Absent from the "<500ms time to VM-ready" row of a competitor's table, which is not the same as exe.dev claiming anything either way. | #exe-dev-cold_start_claimed |
| Isolation | — | Unknown | — | — | The table claims Docker inside the VM but names no hypervisor or isolation technology. | #exe-dev-isolation_tech |
| Root in guest | ● | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Docker inside the VM" row: a Docker daemon in the guest implies root. The table claims Docker, not root. Transcribed from box's comparison table — a competitor's chart, not exe.dev's own documentation — and not verified by toolweight. | #exe-dev-root_access |
| Egress control | — | Unknown | — | — | The table covers what the network can reach, not what the platform can restrict. | #exe-dev-egress_control |
| Max runtime | — | Unknown | — | — | The "No session cap / runs 24/7" row is a marketing statement in a competitor's chart, not a runtime ceiling exe.dev publishes. Left unknown rather than awarded this page's 24 h maximum. | #exe-dev-max_runtime |
| Persistent FS | — | Unknown | — | — | Not a row in the table. | #exe-dev-persistent_fs |
| Snapshot & fork | — | Unknown | — | — | exe.dev is absent from both the "Fast disk snapshots / branching" and "Process fork" rows. A rival declining to tick a box for a competitor is not the table addressing the field, so this is recorded as nothing rather than as a no — the previous "no" scored exe.dev zero on a weight-8 field (10 under the agentic preset) on a competitor's say-so. Note the asymmetry, which is deliberate: box's and ascii's own absence from the process-fork row is credited, because a vendor conceding a gap in its own product is evidence and a vendor asserting a gap in someone else's is not. | #exe-dev-snapshot_fork |
| Custom images | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from "BYO repos + arbitrary setup script" — a base extended by a setup script, this field's partial. The mapping is ours. From a competitor's table, unverified. | #exe-dev-custom_images |
| GPU | — | Unknown | — | — | Not a row in the table. | #exe-dev-gpu |
| Runtimes | — | Unknown | — | — | Not a row in the table. | #exe-dev-language_runtimes |
| Preview URLs | — | Unknown | — | — | exe.dev is absent from the "Dedicated IPv4 per VM" and "Full TCP/UDP + BYO domain" rows, but neither row is about first-party preview URLs, so the table settles nothing here. | #exe-dev-preview_urls |
| Browser inside | — | Unknown | — | — | Not a row in the table. | #exe-dev-browser_in_sandbox |
| File up/download | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "SSH access" row: scp and sftp follow from SSH, and CLI-only access is this field's partial. No first-party file API is described. Competitor's table, unverified. | #exe-dev-file_transfer_api |
| Sydney region | — | Unknown | — | — | The table says nothing about regions. | #exe-dev-sydney_region |
| Concurrent limit | — | Unknown | — | — | Absent from the "1000+ concurrent VMs ergonomically" row; no figure is given. | #exe-dev-max_concurrency |
| MCP server | — | Unknown | — | — | Not a row in the table. | #exe-dev-mcp_server |
| SDKs | — | Unknown | — | — | Not a row in the table. | #exe-dev-sdk_languages |
| Streaming output | — | Unknown | — | — | Not a row in the table. | #exe-dev-streaming_stdout |
| Price / hour | — | Unknown | — | — | The table records only that pricing is flat, not what it costs. No rate for a comparable vCPU/RAM shape has been verified. | #exe-dev-price_per_hour |
| Meter | subscription | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Flat pricing" row and mapped to subscription because that is this field's option for a flat fee rather than a meter. Competitor's table, unverified. | #exe-dev-billing_granularity |
| Idle cost | — | Unknown | — | — | Not a row in the table. | #exe-dev-idle_billing |
| GitHub stars | — | Unknown | — | — | — | #exe-dev-github_stars |
| Funding | — | Unknown | — | — | — | #exe-dev-funding_stage |
| Shipped | — | Unknown | — | — | — | #exe-dev-launched |
| Positioning | Modern VMs you SSH into, with root, apt and systemd, on a flat monthly plan. | Vendor-claimed | 2026-07-23 | https://exe.dev | Paraphrased from exe.dev's own site. The capability cells on this row, unlike this one, come from a competitor's comparison table. | #exe-dev-positioning |

**Verdict.** Present on this page only because a competitor put it there, and every capability cell reflects that: box's table credits exe.dev with BYO repos and a setup script, SSH, Docker in the guest, 24/7 VMs and flat pricing, and omits it from the rows for snapshots, forking, a dedicated IPv4 and BYO domains. The positive claims are believable precisely because they come from a rival, and they are recorded. The omissions are not: a competitor declining to tick a box is not evidence that the box is empty, so exe.dev's snapshot-and-fork cell is unknown here rather than a zero, and the 24/7 row buys it no runtime ceiling. Nothing on this row is measured, and no price, boot time or isolation detail is established at all — treat it as a placeholder until it can be sourced from exe.dev directly.

**Pick it when**

- Long-lived SSH VMs on a predictable monthly bill
- You want root, apt and systemd rather than a constrained runtime
- You are prepared to verify the gaps a competitor's chart reports

### ascii {#ascii}

Agent orchestration over Telegram, running on box's VM infrastructure.

|  |  |
| --- | --- |
| Site | https://ascii.dev |
| Docs | https://docs.ascii.dev |
| Company | ASCII |
| Profile | https://toolweight.dev/tools/ascii |
| Score (default weights) | 64.7 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | — | Unknown | — | — | toolweight has not measured ascii, and the vendor's comparison table publishes no boot figure. | #ascii-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | ascii is absent from the "<500ms time to VM-ready" row and publishes no other figure. | #ascii-cold_start_claimed |
| Isolation | — | Unknown | — | — | The table claims Docker inside the VM but names no hypervisor or isolation technology. | #ascii-isolation_tech |
| Root in guest | ● | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Docker inside the VM" row: a Docker daemon in the guest implies root. The table claims Docker, not root. Transcribed from ASCII's own comparison table; not verified by toolweight. | #ascii-root_access |
| Egress control | — | Unknown | — | — | The table covers what the network can reach, not what the platform can restrict. | #ascii-egress_control |
| Max runtime | — | Unknown | — | — | The "No session cap / runs 24/7" row is a marketing statement, not a published runtime ceiling, and this page's 24 h ceiling is reserved for platforms with a documented absence of a limit. Left unknown rather than awarded the maximum. | #ascii-max_runtime |
| Persistent FS | — | Unknown | — | — | Not a row in the table. | #ascii-persistent_fs |
| Snapshot & fork | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Listed under "Fast disk snapshots / branching" and not under "Process fork" — disk-only cloning without live memory forking, this field's partial. Derived from a presence and an absence rather than stated; the absence is ASCII conceding a gap in its own product, which is why it is credited at all. Vendor-published, unverified. | #ascii-snapshot_fork |
| Custom images | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from "BYO repos + arbitrary setup script" — a base extended by a setup script, this field's partial. Nothing is said about arbitrary OCI images, so the mapping is ours. Vendor-published, unverified. | #ascii-custom_images |
| GPU | — | Unknown | — | — | Not a row in the table. | #ascii-gpu |
| Runtimes | — | Unknown | — | — | Not a row in the table. | #ascii-language_runtimes |
| Preview URLs | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from two rows that are not about preview URLs — "Dedicated IPv4 per VM" and "Full TCP/UDP + BYO domain": reachable ports on a domain you own rather than a first-party HTTPS URL from the API. The mapping is ours. Vendor-published, unverified. | #ascii-preview_urls |
| Browser inside | — | Unknown | — | — | Not a row in the table. | #ascii-browser_in_sandbox |
| File up/download | — | Unknown | — | — | The "SSH access" row lists box, exe.dev, Namespace, Daytona, Codespaces, Cursor SDK and Islo — not ascii — so no SSH-based file movement is claimed, and no file API is described either way. The vendor omitting its own product from a row is at least a claim against interest, but it still settles nothing about this field. | #ascii-file_transfer_api |
| Sydney region | — | Unknown | — | — | The table says nothing about regions. | #ascii-sydney_region |
| Concurrent limit | — | Unknown | — | — | ascii is absent from the "1000+ concurrent VMs ergonomically" row, so that scale is not claimed; no other figure is given. | #ascii-max_concurrency |
| MCP server | — | Unknown | — | — | Not a row in the table. | #ascii-mcp_server |
| SDKs | — | Unknown | — | — | Not a row in the table. | #ascii-sdk_languages |
| Streaming output | — | Unknown | — | — | Not a row in the table. | #ascii-streaming_stdout |
| Price / hour | — | Unknown | — | — | No rate for a comparable vCPU/RAM shape is published in the table or alongside it. | #ascii-price_per_hour |
| Meter | subscription | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Flat pricing" row and mapped to subscription because that is this field's option for a flat fee rather than a meter. The table never uses the word. Vendor-published, unverified. | #ascii-billing_granularity |
| Idle cost | — | Unknown | — | — | Not a row in the table. | #ascii-idle_billing |
| GitHub stars | — | Unknown | — | — | — | #ascii-github_stars |
| Funding | — | Unknown | — | — | — | #ascii-funding_stage |
| Shipped | — | Unknown | — | — | — | #ascii-launched |
| Positioning | A pocket CTO on Telegram: multi-repo dispatch and cross-VM agent comms, running on box. | Vendor-claimed | 2026-07-23 | https://box.ascii.dev/compare | Paraphrased from ASCII's own comparison page. | #ascii-positioning |

**Verdict.** The only row here where the product is the agent layer and the VM is an implementation detail — ascii is ASCII's Telegram-driven orchestration sitting on box's infrastructure, so its capability cells are box's minus SSH and minus the concurrency claim. Every one of them is transcribed from ASCII's own comparison table and none is verified. Judge it as an agent harness with a VM attached, not as a sandbox API, and expect to establish the fundamentals — isolation, price, boot time — yourself, because the table does not address any of them.

**Pick it when**

- You want an agent you message rather than an API you call
- Multi-repo dispatch across long-running VMs
- You are already using box and want the harness on top

### box {#box}

Persistent Linux VMs with SSH, per-VM IPv4 and disk-level forking, priced flat.

|  |  |
| --- | --- |
| Site | https://box.ascii.dev |
| Docs | https://docs.ascii.dev |
| Company | ASCII |
| Profile | https://toolweight.dev/tools/box |
| Score (default weights) | 64.2 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | — | Unknown | — | — | toolweight has not measured box, and the vendor's comparison table publishes no boot figure. | #box-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | box is absent from its own table's "<500ms time to VM-ready" row, which lists only Daytona, E2B and Blaxel — so box does not claim sub-500 ms. No alternative figure is published, so there is nothing to record. | #box-cold_start_claimed |
| Isolation | — | Unknown | — | — | The table calls these VMs and claims Docker runs inside them, but names no hypervisor or isolation technology. Not inferred here. | #box-isolation_tech |
| Root in guest | ● | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Docker inside the VM" row: a Docker daemon in the guest implies root. The table claims Docker, not root, so this is an inference from a vendor claim rather than the claim itself. Transcribed from box's own comparison table, a source with an obvious interest in the outcome; not verified by toolweight. | #box-root_access |
| Egress control | — | Unknown | — | — | The table covers what the network can reach, not what the platform can restrict. | #box-egress_control |
| Max runtime | — | Unknown | — | — | The table's "No session cap / runs 24/7" row is a marketing statement about intent, not a published runtime ceiling, and this page's 24 h ceiling is reserved for platforms whose documented limit is genuinely absent. Awarding the maximum off that row handed box full marks on a weight-5 field with no evidence behind it. Left unknown until box publishes a limit or the absence of one. | #box-max_runtime |
| Persistent FS | — | Unknown | — | — | Not a row in the table. Disk snapshots imply a disk, but not that files survive the VM. | #box-persistent_fs |
| Snapshot & fork | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Listed under "Fast disk snapshots / branching" but deliberately not under "Process fork (memory + running processes)" — disk-only cloning without live memory forking, which is exactly this field's partial. The value is derived from a presence and an absence rather than stated, so it is inferred; the absence itself is a concession about box's own product and is credited as such. Transcribed from box's own table; unverified. | #box-snapshot_fork |
| Custom images | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from "BYO repos + arbitrary setup script" — a base you extend with a setup script, this field's partial. The table does not say whether an arbitrary OCI image can be supplied, so the mapping is ours. Vendor-published, unverified. | #box-custom_images |
| GPU | — | Unknown | — | — | Not a row in the table. | #box-gpu |
| Runtimes | — | Unknown | — | — | Not a row in the table. | #box-language_runtimes |
| Preview URLs | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from two rows that are not about preview URLs — "Dedicated IPv4 per VM" and "Full TCP/UDP + BYO domain". Ports are reachable, but on a domain you own rather than a first-party HTTPS URL returned by the API, which is this field's partial. The mapping is ours, not the table's. Vendor-published, unverified. | #box-preview_urls |
| Browser inside | — | Unknown | — | — | Not a row in the table. | #box-browser_in_sandbox |
| File up/download | ◐ | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "SSH access" row: scp and sftp follow from SSH. The table describes no first-party file API, and CLI-only access is this field's partial. Vendor-published, unverified. | #box-file_transfer_api |
| Sydney region | — | Unknown | — | — | The table says nothing about regions. | #box-sydney_region |
| Concurrent limit | — | Unknown | — | — | The table's "1000+ concurrent VMs ergonomically" row is the vendor scoring its own product against rivals, with "ergonomically" doing considerable work, and it is not a published quota. Recording it as 1000 handed box this page's concurrency ceiling — the same value the self-hosted-Firecracker baseline earns from hardware limits — off a marketing line. Left unknown until a documented limit exists. | #box-max_concurrency |
| MCP server | — | Unknown | — | — | Not a row in the table. | #box-mcp_server |
| SDKs | — | Unknown | — | — | Not a row in the table. | #box-sdk_languages |
| Streaming output | — | Unknown | — | — | Not a row in the table. | #box-streaming_stdout |
| Price / hour | — | Unknown | — | — | The comparison page quotes $20 for roughly 2M VM-seconds, which works out near $0.036 per VM-hour. It does not say what CPU and memory shape those VM-seconds buy, so there is no way to know whether it is comparable to the 2 vCPU / 4 GB hour this column prices, and toolweight has not checked the rate. Left unknown rather than converted against an assumed shape. | #box-price_per_hour |
| Meter | subscription | Inferred | 2026-07-23 | https://box.ascii.dev/compare | Derived from the "Flat pricing" row and mapped to subscription because that is this field's option for a flat fee rather than a meter. The table gives no metering detail and never uses the word, so the mapping is ours. Vendor-published, unverified. | #box-billing_granularity |
| Idle cost | — | Unknown | — | — | Not a row in the table; flat pricing says nothing about what an idle VM costs. | #box-idle_billing |
| GitHub stars | — | Unknown | — | — | — | #box-github_stars |
| Funding | — | Unknown | — | — | — | #box-funding_stage |
| Shipped | — | Unknown | — | — | — | #box-launched |
| Positioning | A persistent Linux VM with SSH, disk-level forking, a dedicated IPv4 and Docker inside. | Vendor-claimed | 2026-07-23 | https://box.ascii.dev | Paraphrased from box's own site. | #box-positioning |

**Verdict.** Read this row as a vendor's self-assessment, because that is what it is: every cell comes from the comparison table box publishes on its own site, and toolweight has measured nothing. Taken on its own terms the shape is coherent and unusual here — a long-lived VM with SSH, Docker, a routable IPv4 and a flat bill, rather than an ephemeral per-second sandbox — and the table is notably candid about what box lacks, conceding process fork and sub-500 ms boots to E2B, Modal, Daytona and Blaxel. Two of its louder claims earn nothing here, though: "runs 24/7" is not a published runtime ceiling and "1000+ concurrent VMs ergonomically" is not a published quota, so both cells are unknown rather than scored at this page's maximum. What is missing is everything a buyer would check it against: no isolation technology, no measured boot time, no comparable hourly rate.

**Pick it when**

- You want a VM that stays up rather than a sandbox that vanishes
- SSH, Docker and a real network stack matter more than an SDK
- You are willing to test the vendor's claims yourself before committing

### GitHub Codespaces {#github-codespaces}

Devcontainer-backed cloud VMs built for humans, occasionally repurposed for agents.

|  |  |
| --- | --- |
| Site | https://github.com/features/codespaces |
| Docs | https://docs.github.com/en/codespaces |
| Company | GitHub |
| Founded | 2020 |
| Funding | Public |
| Profile | https://toolweight.dev/tools/github-codespaces |
| Score (default weights) | 62.8 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 45 s | Inferred | — | — | Estimate for a cold codespace on a devcontainer with no prebuild. Prebuilds cut this to roughly ten seconds; resuming a stopped codespace is faster again. | #github-codespaces-cold_start_measured |
| Cold start (claimed) | 10 s | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/codespaces/prebuilding-your-codespaces | GitHub markets prebuilds as making codespaces available in seconds. | #github-codespaces-cold_start_claimed |
| Isolation | vm | Inferred | — | — | A dedicated Azure VM per codespace. | #github-codespaces-isolation_tech |
| Root in guest | ● | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/codespaces | — | #github-codespaces-root_access |
| Egress control | allowlist | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/codespaces | Organisation policies can restrict outbound network access. | #github-codespaces-egress_control |
| Max runtime | 1440 min | Inferred | — | — | No hard runtime cap; idle timeout defaults to 30 minutes and retention to 30 days. | #github-codespaces-max_runtime |
| Persistent FS | ● | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/codespaces | — | #github-codespaces-persistent_fs |
| Snapshot & fork | ◐ | Inferred | — | — | Prebuilds are a build cache, not a runtime snapshot; you cannot fork a live codespace. | #github-codespaces-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://containers.dev | The devcontainer spec, which is an open standard and portable. | #github-codespaces-custom_images |
| GPU | ○ | Inferred | — | — | Not on standard self-serve machine types. | #github-codespaces-gpu |
| Runtimes | any-oci-image | Inferred | — | — | — | #github-codespaces-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/codespaces | Forwarded ports, private by default. | #github-codespaces-preview_urls |
| Browser inside | ◐ | Inferred | — | — | — | #github-codespaces-browser_in_sandbox |
| File up/download | ◐ | Inferred | — | — | CLI and SSH; no clean programmatic file API. | #github-codespaces-file_transfer_api |
| Sydney region | ● | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/codespaces | Australia is a selectable region. | #github-codespaces-sydney_region |
| Concurrent limit | 10 sandboxes | Inferred | — | — | Per-user concurrent codespace limits are low by default; this is a product for humans. | #github-codespaces-max_concurrency |
| MCP server | ○ | Inferred | — | — | GitHub's MCP server covers the API surface, not codespace exec. | #github-codespaces-mcp_server |
| SDKs | rest-api, cli | Inferred | — | — | — | #github-codespaces-sdk_languages |
| Streaming output | ◐ | Inferred | — | — | Over SSH; no exec-stream API. | #github-codespaces-streaming_stdout |
| Price / hour | $0.18 /hr | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/billing/managing-billing-for-github-codespaces | 2-core / 8 GB at $0.18/hr, plus storage per GB-month. | #github-codespaces-price_per_hour |
| Meter | per-minute | Inferred | — | — | Metered in compute-minutes. | #github-codespaces-billing_granularity |
| Idle cost | storage-only | Vendor-claimed | 2026-01-15 | https://docs.github.com/en/billing | Stopped codespaces bill storage. | #github-codespaces-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #github-codespaces-github_stars |
| Funding | public | Vendor-claimed | 2026-01-15 | https://microsoft.com | — | #github-codespaces-funding_stage |
| Shipped | 2020 | Vendor-claimed | 2026-01-15 | https://github.blog | — | #github-codespaces-launched |
| Positioning | A configured development environment in the cloud, one click from the repository. | Inferred | — | — | — | #github-codespaces-positioning |

**Verdict.** Included because teams reach for it first and then discover the concurrency limits and minute-scale boots. It is an excellent environment for a human and a bad substrate for an API creating hundreds of sandboxes. The devcontainer spec, though, is the most portable image format on this page.

**Pick it when**

- Human-in-the-loop agent sessions rather than autonomous fleets
- You need an Australian region and are already on GitHub
- Your environments are already defined as devcontainers

### Northflank {#northflank}

Container platform with bring-your-own-cloud, GPUs and a sandbox-shaped API.

|  |  |
| --- | --- |
| Site | https://northflank.com |
| Docs | https://northflank.com/docs |
| Company | Northflank Ltd. |
| Founded | 2019 |
| Funding | Series A |
| Open source | No |
| Profile | https://toolweight.dev/tools/northflank |
| Score (default weights) | 62.6 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 12 s | Inferred | — | — | Estimate. Container scheduling plus image pull; this is a deployment platform, not a snapshot restorer. | #northflank-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | No published cold-start figure. | #northflank-cold_start_claimed |
| Isolation | container | Inferred | — | — | Kubernetes-scheduled containers — hardened, but a shared kernel. | #northflank-isolation_tech |
| Root in guest | ◐ | Inferred | — | — | Root in the container, constrained by the cluster's pod security policy. | #northflank-root_access |
| Egress control | allowlist | Inferred | — | — | Network policies and private networking are first-class, and under BYOC your own VPC rules apply. | #northflank-egress_control |
| Max runtime | 1440 min | Inferred | — | — | Services run indefinitely. | #northflank-max_runtime |
| Persistent FS | ● | Vendor-claimed | 2026-01-15 | https://northflank.com/docs | Persistent volumes. | #northflank-persistent_fs |
| Snapshot & fork | ○ | Inferred | — | — | — | #northflank-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://northflank.com/docs | — | #northflank-custom_images |
| GPU | ● | Vendor-claimed | 2026-01-15 | https://northflank.com/pricing | — | #northflank-gpu |
| Runtimes | any-oci-image | Inferred | — | — | — | #northflank-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://northflank.com/docs | — | #northflank-preview_urls |
| Browser inside | ◐ | Inferred | — | — | — | #northflank-browser_in_sandbox |
| File up/download | ◐ | Inferred | — | — | Volumes and exec rather than a dedicated file API. | #northflank-file_transfer_api |
| Sydney region | ◐ | Inferred | — | — | Reachable through bring-your-own-cloud in an Australian AWS or GCP region; not a managed Northflank region. | #northflank-sydney_region |
| Concurrent limit | 200 sandboxes | Inferred | — | — | Bounded by your cluster or plan rather than a sandbox quota. | #northflank-max_concurrency |
| MCP server | ● | Inferred | — | — | Ships an MCP server for platform operations. | #northflank-mcp_server |
| SDKs | typescript, rest-api, cli | Inferred | — | — | — | #northflank-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://northflank.com/docs | — | #northflank-streaming_stdout |
| Price / hour | $0.07 /hr | Inferred | — | — | Approximate: 2 vCPU + 4 GB of managed compute at list. BYOC changes the calculus entirely — you pay your cloud plus a platform fee. | #northflank-price_per_hour |
| Meter | per-minute | Inferred | — | — | Usage-metered but not per-second; a poor fit for very short sandboxes. | #northflank-billing_granularity |
| Idle cost | full-rate | Inferred | — | — | A running service bills whether or not it is doing work. | #northflank-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #northflank-github_stars |
| Funding | series-a | Community-reported | — | — | — | #northflank-funding_stage |
| Shipped | 2021 | Inferred | — | — | Platform launch; the agent-sandbox positioning dates from 2025. | #northflank-launched |
| Positioning | Run agent workloads, services and GPUs in your own cloud account. | Inferred | — | — | — | #northflank-positioning |

**Verdict.** Loses the boot-time argument outright and wins the one that closes enterprise deals: everything runs in your cloud account, under your network policy, inside your compliance boundary. Wrong tool for bursty per-request sandboxes, right tool for long-lived per-tenant environments.

**Pick it when**

- Compliance requires the workload inside your own VPC
- Sandboxes are long-lived per customer, not per request
- You also need databases, jobs and GPUs on one platform

### Self-hosted Firecracker {#diy-firecracker}

The baseline: Firecracker on your own metal, plus every hard part you now own.

|  |  |
| --- | --- |
| Site | https://firecracker-microvm.github.io |
| Docs | https://github.com/firecracker-microvm/firecracker/tree/main/docs |
| Repo | https://github.com/firecracker-microvm/firecracker |
| Company | Self-hosted Firecracker |
| Founded | 2018 |
| Open source | Yes (Apache-2.0) |
| Profile | https://toolweight.dev/tools/diy-firecracker |
| Score (default weights) | 61.2 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 200 ms | Inferred | — | — | Guest boot is about 125 ms on decent metal; add your own API and scheduler. This is the floor every vendor here is measured against, and it assumes you have already built pool warming. | #diy-firecracker-cold_start_measured |
| Cold start (claimed) | 125 ms | Vendor-claimed | 2026-01-15 | https://firecracker-microvm.github.io | The canonical 125 ms boot figure from the Firecracker project. | #diy-firecracker-cold_start_claimed |
| Isolation | microvm | Vendor-claimed | 2026-01-15 | https://firecracker-microvm.github.io | — | #diy-firecracker-isolation_tech |
| Root in guest | ● | Inferred | — | — | — | #diy-firecracker-root_access |
| Egress control | allowlist | Inferred | — | — | Your TAP devices, your nftables rules. Total control, total responsibility. | #diy-firecracker-egress_control |
| Max runtime | 1440 min | Inferred | — | — | Whatever you decide. | #diy-firecracker-max_runtime |
| Persistent FS | ● | Inferred | — | — | — | #diy-firecracker-persistent_fs |
| Snapshot & fork | ◐ | Inferred | — | — | Firecracker supports snapshot and restore, but productionising it — page cache, clock skew, unique IDs, network reattachment — is exactly the hard part vendors sell. | #diy-firecracker-snapshot_fork |
| Custom images | ● | Inferred | — | — | — | #diy-firecracker-custom_images |
| GPU | ◐ | Inferred | — | — | Firecracker has no first-class GPU passthrough; you would use Cloud Hypervisor or plain KVM. | #diy-firecracker-gpu |
| Runtimes | any-oci-image | Inferred | — | — | — | #diy-firecracker-language_runtimes |
| Preview URLs | ○ | Inferred | — | — | You build the ingress. | #diy-firecracker-preview_urls |
| Browser inside | ◐ | Inferred | — | — | — | #diy-firecracker-browser_in_sandbox |
| File up/download | ○ | Inferred | — | — | You build it. | #diy-firecracker-file_transfer_api |
| Sydney region | ● | Inferred | — | — | Wherever you rent metal. | #diy-firecracker-sydney_region |
| Concurrent limit | 1,000 sandboxes | Inferred | — | — | Bounded by hardware; hundreds of microVMs per host is routine. | #diy-firecracker-max_concurrency |
| MCP server | ○ | Inferred | — | — | — | #diy-firecracker-mcp_server |
| SDKs | rest-api | Inferred | — | — | — | #diy-firecracker-sdk_languages |
| Streaming output | ○ | Inferred | — | — | You build it. | #diy-firecracker-streaming_stdout |
| Price / hour | $0.03 /hr | Inferred | — | — | Approximate cost of 2 vCPU + 4 GB amortised across a rented bare-metal host at around 60% utilisation. Excludes the engineer maintaining it, which is the real number. | #diy-firecracker-price_per_hour |
| Meter | per-hour | Inferred | — | — | You rent the host, not the sandbox. | #diy-firecracker-billing_granularity |
| Idle cost | full-rate | Inferred | — | — | The host bills whether or not a microVM is running on it. | #diy-firecracker-idle_billing |
| GitHub stars | 27,000 | Community-reported | — | — | firecracker-microvm/firecracker, rounded. | #diy-firecracker-github_stars |
| Funding | — | Inferred | — | — | — | #diy-firecracker-funding_stage |
| Shipped | 2018 | Vendor-claimed | 2026-01-15 | https://firecracker-microvm.github.io | — | #diy-firecracker-launched |
| Positioning | The microVM monitor underneath most of this roster, and none of the platform. | Inferred | — | — | — | #diy-firecracker-positioning |

**Verdict.** The honest baseline. Compute is roughly a tenth of vendor pricing and the isolation is identical, because it is literally the same hypervisor. What you buy from everyone else is snapshot orchestration, pool warming, image distribution and multi-tenant quota enforcement — comfortably two engineer-years.

**Pick it when**

- Sustained volume where vendor margin exceeds an engineer's salary
- Hard data-residency or air-gap requirements
- You already operate bare metal and a scheduler

### Cloudflare Sandbox {#cloudflare-sandbox}

Container sandboxes driven from a Worker, addressed through Durable Objects.

|  |  |
| --- | --- |
| Site | https://developers.cloudflare.com/sandbox/ |
| Docs | https://developers.cloudflare.com/containers/ |
| Repo | https://github.com/cloudflare/sandbox-sdk |
| Company | Cloudflare |
| Founded | 2009 |
| Funding | Public |
| Open source | Yes (MIT) |
| Profile | https://toolweight.dev/tools/cloudflare-sandbox |
| Score (default weights) | 60.1 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 3 s | Inferred | — | — | Estimate for a cold container instance. A warm instance behind a Durable Object responds in milliseconds; the first request after scale-to-zero is the expensive one. | #cloudflare-sandbox-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | Cloudflare publishes no single cold-start figure for Containers, which is unusually honest of them. | #cloudflare-sandbox-cold_start_claimed |
| Isolation | container | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/containers/ | Containers on Cloudflare's own runtime, addressed by a Durable Object. | #cloudflare-sandbox-isolation_tech |
| Root in guest | ● | Inferred | — | — | Root inside the container image. | #cloudflare-sandbox-root_access |
| Egress control | allowlist | Inferred | — | — | Outbound traffic routes through the Worker, so you can gate it in code — the most programmable egress control here. | #cloudflare-sandbox-egress_control |
| Max runtime | 60 min | Inferred | — | — | Instances sleep after a configurable inactivity timeout; long-lived processes are not the intended shape. | #cloudflare-sandbox-max_runtime |
| Persistent FS | ○ | Inferred | — | — | Container disk is ephemeral; durable state belongs in the Durable Object, R2 or D1. | #cloudflare-sandbox-persistent_fs |
| Snapshot & fork | ○ | Inferred | — | — | — | #cloudflare-sandbox-snapshot_fork |
| Custom images | ● | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/containers/ | Your Dockerfile, pushed to Cloudflare's registry. | #cloudflare-sandbox-custom_images |
| GPU | ○ | Inferred | — | — | Workers AI is a separate product. | #cloudflare-sandbox-gpu |
| Runtimes | any-oci-image | Inferred | — | — | — | #cloudflare-sandbox-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/sandbox/ | Ports are exposed through the Worker. | #cloudflare-sandbox-preview_urls |
| Browser inside | ◐ | Inferred | — | — | Cloudflare Browser Rendering is a separate product; you can also run Chromium in the container. | #cloudflare-sandbox-browser_in_sandbox |
| File up/download | ● | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/sandbox/ | — | #cloudflare-sandbox-file_transfer_api |
| Sydney region | ◐ | Inferred | — | — | Cloudflare has Sydney presence, but container placement follows their topology rather than a region you choose. | #cloudflare-sandbox-sydney_region |
| Concurrent limit | 100 sandboxes | Inferred | — | — | Account-level container instance limits, raised on request. | #cloudflare-sandbox-max_concurrency |
| MCP server | ◐ | Inferred | — | — | Cloudflare invests heavily in MCP across its platform; the sandbox-specific server is less established than the SDK. | #cloudflare-sandbox-mcp_server |
| SDKs | typescript | Inferred | — | — | — | #cloudflare-sandbox-sdk_languages |
| Streaming output | ● | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/sandbox/ | — | #cloudflare-sandbox-streaming_stdout |
| Price / hour | $0.18 /hr | Inferred | — | — | Approximate: 2 vCPU + 4 GiB at published Containers vCPU and memory rates, before the required paid Workers plan. | #cloudflare-sandbox-price_per_hour |
| Meter | per-10ms | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/containers/pricing/ | The finest meter in this roster. | #cloudflare-sandbox-billing_granularity |
| Idle cost | free-when-stopped | Vendor-claimed | 2026-01-15 | https://developers.cloudflare.com/containers/pricing/ | Billing stops when the instance sleeps. | #cloudflare-sandbox-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #cloudflare-sandbox-github_stars |
| Funding | public | Vendor-claimed | 2026-01-15 | https://cloudflare.net | — | #cloudflare-sandbox-funding_stage |
| Shipped | 2025 | Vendor-claimed | 2026-01-15 | https://blog.cloudflare.com/containers-are-available-in-public-beta-for-simple-global-and-programmable/ | — | #cloudflare-sandbox-launched |
| Positioning | Containers you can call from a Worker, with a Durable Object as the control plane. | Inferred | — | — | — | #cloudflare-sandbox-positioning |

**Verdict.** Structurally the most interesting design here — a sandbox that is an addressable object in your app, with egress you gate in Worker code — and the slowest to cold start. Take it if your stack is already Workers; do not migrate to Cloudflare for the sandbox alone.

**Pick it when**

- Your app already runs on Workers and Durable Objects
- You want code-level control over what the sandbox can reach
- Sandboxes are long-lived per user rather than created in bursts

### Val Town {#val-town}

Deno isolates that run TypeScript on HTTP, cron and email triggers.

|  |  |
| --- | --- |
| Site | https://val.town |
| Docs | https://docs.val.town |
| Company | Val Town |
| Founded | 2022 |
| Funding | Seed |
| Profile | https://toolweight.dev/tools/val-town |
| Score (default weights) | 44.8 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 150 ms | Inferred | — | — | Estimate for an HTTP val's first request after idle. Isolates start fast because there is no kernel to boot. | #val-town-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | — | #val-town-cold_start_claimed |
| Isolation | v8-isolate | Vendor-claimed | 2026-01-15 | https://docs.val.town | Deno isolates. | #val-town-isolation_tech |
| Root in guest | ○ | Vendor-claimed | 2026-01-15 | https://docs.val.town | — | #val-town-root_access |
| Egress control | proxy-logged | Inferred | — | — | Outbound fetch is available and observable; no fine-grained per-val allowlist. | #val-town-egress_control |
| Max runtime | 5 min | Inferred | — | — | Vals are request-scoped with a timeout measured in minutes, not a long-running process host. | #val-town-max_runtime |
| Persistent FS | ○ | Vendor-claimed | 2026-01-15 | https://docs.val.town | No filesystem. SQLite and blob storage are provided instead. | #val-town-persistent_fs |
| Snapshot & fork | ○ | Inferred | — | — | Forking a val copies source, not runtime state. | #val-town-snapshot_fork |
| Custom images | ○ | Vendor-claimed | 2026-01-15 | https://docs.val.town | — | #val-town-custom_images |
| GPU | ○ | Inferred | — | — | — | #val-town-gpu |
| Runtimes | javascript-typescript | Inferred | — | — | — | #val-town-language_runtimes |
| Preview URLs | ● | Vendor-claimed | 2026-01-15 | https://docs.val.town | Every HTTP val gets a public URL by default. | #val-town-preview_urls |
| Browser inside | ○ | Inferred | — | — | — | #val-town-browser_in_sandbox |
| File up/download | ◐ | Inferred | — | — | Blob storage API rather than a sandbox filesystem. | #val-town-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | — | #val-town-sydney_region |
| Concurrent limit | — | Unknown | — | — | Concurrency is limited by request rate on a plan, not by a sandbox count. | #val-town-max_concurrency |
| MCP server | ● | Inferred | — | — | Val Town has leaned into MCP for driving vals from agents. | #val-town-mcp_server |
| SDKs | typescript, rest-api, cli | Inferred | — | — | — | #val-town-sdk_languages |
| Streaming output | ◐ | Inferred | — | — | Logs are visible; there is no exec-stream primitive. | #val-town-streaming_stdout |
| Price / hour | — | Unknown | — | — | Subscription plus usage limits rather than compute-hours; the hourly comparison does not apply. | #val-town-price_per_hour |
| Meter | subscription | Vendor-claimed | 2026-01-15 | https://www.val.town/pricing | — | #val-town-billing_granularity |
| Idle cost | free-when-stopped | Inferred | — | — | Idle vals cost nothing. | #val-town-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #val-town-github_stars |
| Funding | seed | Community-reported | — | — | — | #val-town-funding_stage |
| Shipped | 2022 | Inferred | — | — | — | #val-town-launched |
| Positioning | Write and deploy TypeScript in the browser, triggered by HTTP, cron or email. | Inferred | — | — | — | #val-town-positioning |

**Verdict.** Here as the isolate benchmark: no kernel, no filesystem, no shell, and consequently the fastest and cheapest way to run a snippet of model-written TypeScript behind a URL. The moment your agent needs to run npm install and inspect the result, you have outgrown it.

**Pick it when**

- Evaluating short TypeScript snippets behind an HTTP endpoint
- Cron and webhook glue an agent can write and deploy itself
- Zero infrastructure, and you can accept zero filesystem

### Riza {#riza}

WASM-isolated code interpreter API for LLM output, with no filesystem or network.

|  |  |
| --- | --- |
| Site | https://riza.io |
| Docs | https://docs.riza.io |
| Company | Riza |
| Founded | 2024 |
| Funding | Seed |
| Profile | https://toolweight.dev/tools/riza |
| Score (default weights) | 42.9 / 100 |

| Field | Value | Confidence | Verified | Source | Note | Anchor |
| --- | --- | --- | --- | --- | --- | --- |
| Cold start | 120 ms | Inferred | — | — | Estimate for an API call executing a short script. WASM instantiation is the cheapest start in the roster. | #riza-cold_start_measured |
| Cold start (claimed) | — | Unknown | — | — | Marketed on isolation rather than latency. | #riza-cold_start_claimed |
| Isolation | wasm | Vendor-claimed | 2026-01-15 | https://docs.riza.io | Language runtimes compiled to WebAssembly. | #riza-isolation_tech |
| Root in guest | ○ | Vendor-claimed | 2026-01-15 | https://docs.riza.io | There is no OS to be root of. | #riza-root_access |
| Egress control | blocked-by-default | Vendor-claimed | 2026-01-15 | https://docs.riza.io | Filesystem and network are off unless explicitly granted per execution — the strictest default here. | #riza-egress_control |
| Max runtime | 1 min | Inferred | — | — | Executions are short-lived by design. | #riza-max_runtime |
| Persistent FS | ○ | Vendor-claimed | 2026-01-15 | https://docs.riza.io | — | #riza-persistent_fs |
| Snapshot & fork | ○ | Inferred | — | — | — | #riza-snapshot_fork |
| Custom images | ○ | Vendor-claimed | 2026-01-15 | https://docs.riza.io | No package installs: you supply code, not an environment. | #riza-custom_images |
| GPU | ○ | Inferred | — | — | — | #riza-gpu |
| Runtimes | python, javascript-typescript, ruby, php | Inferred | — | — | — | #riza-language_runtimes |
| Preview URLs | ○ | Inferred | — | — | — | #riza-preview_urls |
| Browser inside | ○ | Inferred | — | — | — | #riza-browser_in_sandbox |
| File up/download | ◐ | Inferred | — | — | Input and output objects rather than a filesystem API. | #riza-file_transfer_api |
| Sydney region | ○ | Inferred | — | — | — | #riza-sydney_region |
| Concurrent limit | — | Unknown | — | — | Rate-limited per plan rather than capped by concurrent sandboxes. | #riza-max_concurrency |
| MCP server | ◐ | Inferred | — | — | — | #riza-mcp_server |
| SDKs | python, typescript, rest-api | Inferred | — | — | — | #riza-sdk_languages |
| Streaming output | ○ | Inferred | — | — | Output returns on completion. | #riza-streaming_stdout |
| Price / hour | — | Unknown | — | — | Priced per execution and per plan, not per compute-hour. | #riza-price_per_hour |
| Meter | per-request | Inferred | — | — | — | #riza-billing_granularity |
| Idle cost | free-when-stopped | Inferred | — | — | Nothing persists, so nothing idles. | #riza-idle_billing |
| GitHub stars | — | Inferred | — | — | — | #riza-github_stars |
| Funding | seed | Community-reported | — | — | — | #riza-funding_stage |
| Shipped | 2024 | Inferred | — | — | — | #riza-launched |
| Positioning | A code interpreter API for safely running code written by LLMs. | Inferred | — | — | — | #riza-positioning |

**Verdict.** The strictest isolation on the page and the smallest blast radius: no filesystem, no network, no processes unless you ask. That constraint is exactly right for evaluating a model's arithmetic or data transform, and completely wrong for anything that needs to install a dependency.

**Pick it when**

- Executing model-written expressions with the tightest possible default
- Multi-language interpreter tooling without maintaining images
- You want deny-by-default network and filesystem out of the box

## Methodology

Field values come from vendor documentation, pricing pages and public changelogs, each cell carrying its own provenance. Prices are the list rate for roughly 2 vCPU and 4 GB with no committed spend, normalised to an hourly figure. Several vendors bill per second or per credit and never publish an hourly number, so those cells are marked inferred with the arithmetic noted, or left null where a guess would be worse than saying nothing.

Cold start is the reason this page exists, so read the two columns together. Claimed cold start is whatever the vendor puts on its own homepage, and it is scored at weight zero on purpose — it is a marketing artefact, not a measurement. Vendors quote wildly different things under the same word: time to restore a memory snapshot on already-provisioned hardware, time for the guest kernel to boot, time for the API to return a sandbox ID, or p50 across a pool deliberately kept warm. Measured cold start is what toolweight publishes from its own harness: a single client in a fixed region, TLS handshake included, calling create-sandbox and blocking until a trivial command returns output — the full round trip an agent actually pays for. It runs against an account with no sandboxes alive, after a deliberate idle period, so nothing is pool-warm, and reports p50 and p95 over at least 50 runs so one good afternoon on a vendor's cluster cannot flatter the number. Until that harness has run against every provider here, cells in that column are estimates flagged as inferred, and no cell on this page currently carries measured confidence. We would rather show an honest estimate than launder a vendor's number into a benchmark.

Four rows come from a different kind of source and are flagged accordingly. The capability cells for box, ascii, exe.dev and Islo are transcribed from the comparison table box publishes on its own site, at box.ascii.dev/compare. That is the least neutral source on this page: a chart drawn by a vendor, with that vendor's two products in the first two columns and its competitors arranged around them. toolweight has verified none of it. Every field the table does not address — price per hour, cold start, isolation technology, persistence, regions, SDKs, funding, stars — is left null and unknown rather than filled in by inference.

Three rules keep that table from being laundered into evidence it is not. First, only a cell the table states directly is marked vendor-claimed; where a value had to be derived — reading root access off a "Docker inside the VM" row, or a preview-URL rating off two rows about IP addresses — the cell is marked inferred, because a sound derivation from a vendor's claim is still a derivation. Second, a marketing row is not a measurement: "runs 24/7" is not a published runtime ceiling and "1000+ concurrent VMs ergonomically" is not a published concurrency limit, so those cells are unknown rather than awarded this page's maximum. Third, and most important, absence from a row is scored asymmetrically on purpose. A vendor leaving its own product out of a row is a concession against interest and is credited — box and ascii are both absent from the process-fork and sub-500 ms rows, and that is recorded. A vendor leaving a rival out of a row is the weakest class of claim on this site, so it is recorded as nothing at all: exe.dev and Islo are missing from the snapshot rows, and their snapshot-and-fork cells stay unknown rather than becoming a scored zero on a competitor's say-so. These four rows stay in this shape until they can be re-sourced from each vendor's own documentation, at which point the provenance on every cell changes with them.

## FAQ

### Is a container enough to run LLM-generated code, or do I need a microVM?

If the code comes from your own model and your own prompt, a hardened container is usually fine. If it comes from a user, assume a container escape is a matter of time and budget: shared-kernel isolation has a steady drip of CVEs. A microVM (Firecracker, Cloud Hypervisor) or gVisor gives you a syscall boundary a kernel bug in the guest cannot cross. Check what you are actually buying rather than what the homepage implies — Daytona, the quickest-booting agent-native provider here, runs Docker containers on a shared kernel by default, and several vendors describe a container as having a "dedicated kernel" when they mean a dedicated namespace. The price difference is now small enough that the container answer is rarely worth defending.

### Why is the cold start I measure so much slower than the number on the vendor's homepage?

Because they are measuring different things. Vendor numbers typically time a snapshot restore on hardware already allocated to you, excluding TLS setup, API scheduling, image pull and the round trip back to your client. Your number includes all of it, plus whatever queueing happens when their pool has scaled down. A 90 ms claim routinely lands between 400 ms and 2 s in production, and the gap widens the further you sit from their region.

### What does snapshot and fork actually buy an agent?

Branching. You run a build, snapshot it, then fork the snapshot five times to try five patches in parallel without repeating the setup. It also makes idle cheap: pause mid-session, pay storage only, resume in a fraction of a cold boot with the process tree and page cache intact. For long agent sessions that is worth more than raw boot speed, because you only cold-start once.

### Can I run a browser inside the sandbox instead of paying for a browser API?

Yes, and for a handful of pages a day it is cheaper. Chromium in a sandbox with a CDP endpoint costs compute you are already paying for. What you do not get is residential egress, CAPTCHA handling and the fingerprint work dedicated providers do, so scraping targets with real bot defences will fail. Use the sandbox for your own apps and internal tooling; use a browser API when the site is fighting back.

### How locked in am I if I pick the wrong provider?

Less than it feels. Every provider here exposes the same four verbs — create, exec, read/write files, kill — so a thin interface of your own keeps swapping down to about a day of work. The real lock-in is elsewhere: proprietary image formats, snapshot artefacts that only restore on the vendor's cluster, and preview-URL domains baked into links your users have already saved. Keep images as plain Dockerfiles and you keep your exit.

### Which providers can run in Sydney or another Australian region?

Fly.io Machines has a Sydney region and GitHub Codespaces offers an Australian region; Northflank reaches one through bring-your-own-cloud. The agent-native vendors — E2B, Daytona, Vercel Sandbox, Runloop — are US and EU only at the time of writing, which adds 150–250 ms of round trip to every API call made from Australia. If your control plane runs in Sydney, that latency dwarfs the cold-start differences everyone argues about.

### Do I pay while a sandbox sits idle waiting for the model to respond?

It depends on the meter, and this is where bills go wrong. Fly charges nothing for a stopped machine beyond storage; E2B and CodeSandbox bill storage on a paused sandbox; Vercel bills active CPU, so a sandbox blocked on the network costs very little. Providers billing wall-clock per second charge you for every token the model is still generating. On agent workloads that idle time is usually the majority of the session.

## Recent changes

| Date | Kind | Event | Tools | Source |
| --- | --- | --- | --- | --- |
| 2025-03-01 | launch | **Daytona repositions from dev environments to agent sandboxes** — Daytona relaunched its open-source dev-environment manager as a per-second sandbox runtime aimed at AI agents, leading with sub-100 ms creation claims and snapshot-based images. It marks the point where boot time became the category's headline metric. | daytona | https://www.daytona.io |
| 2025-05-01 | other | **Together AI acquires CodeSandbox** — Together AI acquired CodeSandbox, absorbing the Firecracker and memory-snapshot infrastructure behind the browser IDE. The SDK kept shipping, but its roadmap now answers to an inference company rather than a developer-tools one. | codesandbox-sdk | https://codesandbox.io/blog |
| 2025-06-01 | funding | **Modal raises a large Series B** — Modal announced a Series B at a valuation around $1.1bn, funding continued work on container cold starts and GPU capacity. It is the best-capitalised of the agent-adjacent compute vendors on this page. | modal | https://modal.com/blog |
| 2025-06-24 | launch | **Cloudflare Containers enters public beta** — Cloudflare shipped Containers in public beta with 10 ms billing granularity and Durable Objects as the control plane, followed by the Sandbox SDK that packages the pattern for running untrusted code from a Worker. | cloudflare-sandbox | https://blog.cloudflare.com/containers-are-available-in-public-beta-for-simple-global-and-programmable/ |
| 2025-06-25 | launch | **Vercel Sandbox launches at Ship 2025** — Vercel shipped ephemeral microVM sandboxes callable from a Vercel app, initially capped at 45 minutes each and billed on the active-CPU model. The duration cap has since risen to 24 hours on paid plans, and the product has picked up persistence, snapshots, fork and an egress firewall. | vercel-sandbox | https://vercel.com/changelog |
| 2025-07-28 | funding | **E2B raises a $21M Series A** — Insight Partners led a $21M Series A into E2B, the open-source sandbox provider most agent frameworks default to. It funds the Apache-licensed self-hostable core that is E2B's main structural advantage over the closed platforms chasing it on boot time. | e2b | https://www.insightpartners.com/ideas/e2b-raises-a-21m-series-a-to-offer-cloud-for-ai-agents-to-fortune-100/ |
| 2026-06-11 | other | **Daytona goes closed source** — Daytona moved its production codebase closed, citing AI-assisted vulnerability discovery against public repositories. The AGPL repository stays public but is no longer maintained. The practical effect for buyers is the loss of the self-host escape hatch, on the one provider in this roster whose pricing and product surface have moved most. | daytona | https://www.daytona.io/dotfiles/updates/daytona-is-going-closed-source |

## Sources

| Source | Last verified |
| --- | --- |
| https://e2b.dev/docs | 2026-01-15 |
| https://e2b.dev/docs/sandbox | 2026-01-15 |
| https://e2b.dev/docs/sandbox-template | 2026-01-15 |
| https://github.com/e2b-dev/desktop | 2026-01-15 |
| https://e2b.dev/pricing | 2026-01-15 |
| https://www.insightpartners.com/ideas/e2b-raises-a-21m-series-a-to-offer-cloud-for-ai-agents-to-fortune-100/ | 2026-07-23 |
| https://modal.com/docs/guide/cold-start | 2026-01-15 |
| https://modal.com/docs/guide/security | 2026-01-15 |
| https://modal.com/docs/guide/timeouts | 2026-01-15 |
| https://modal.com/docs/guide/volumes | 2026-01-15 |
| https://modal.com/docs/guide/images | 2026-01-15 |
| https://modal.com/pricing | 2026-01-15 |
| https://modal.com/docs | 2026-01-15 |
| https://www.daytona.io | 2026-01-15 |
| https://northflank.com/blog/daytona-vs-e2b-ai-code-execution-sandboxes | 2026-07-23 |
| https://www.daytona.io/docs | 2026-01-15 |
| https://www.daytona.io/docs/en/network-limits/ | 2026-07-23 |
| https://northflank.com/blog/ai-sandbox-pricing | 2026-07-23 |
| https://www.daytona.io/pricing | 2026-01-15 |
| https://www.daytona.io/dotfiles/updates/daytona-is-going-closed-source | 2026-07-23 |
| https://fly.io/docs/machines/ | 2026-01-15 |
| https://fly.io/docs/volumes/ | 2026-01-15 |
| https://fly.io/docs/gpus/ | 2026-01-15 |
| https://fly.io/docs/reference/regions/ | 2026-01-15 |
| https://fly.io/docs/about/pricing/ | 2026-07-23 |
| https://developers.cloudflare.com/containers/ | 2026-01-15 |
| https://developers.cloudflare.com/sandbox/ | 2026-01-15 |
| https://developers.cloudflare.com/containers/pricing/ | 2026-01-15 |
| https://cloudflare.net | 2026-01-15 |
| https://blog.cloudflare.com/containers-are-available-in-public-beta-for-simple-global-and-programmable/ | 2026-01-15 |
| https://vercel.com/docs/sandbox/concepts | 2026-07-23 |
| https://vercel.com/docs/vercel-sandbox | 2026-01-15 |
| https://vercel.com/docs/sandbox/concepts/firewall | 2026-07-23 |
| https://vercel.com/docs/sandbox/pricing | 2026-07-23 |
| https://vercel.com/docs/sandbox/concepts/persistent-sandboxes | 2026-07-23 |
| https://vercel.com/docs/sandbox/concepts/snapshots | 2026-07-23 |
| https://vercel.com/docs/sandbox/concepts/images | 2026-07-23 |
| https://vercel.com/changelog | 2026-01-15 |
| https://codesandbox.io/docs/sdk | 2026-01-15 |
| https://northflank.com/docs | 2026-01-15 |
| https://northflank.com/pricing | 2026-01-15 |
| https://docs.runloop.ai | 2026-01-15 |
| https://blaxel.ai | 2026-01-15 |
| https://docs.blaxel.ai | 2026-01-15 |
| https://docs.freestyle.sh | 2026-01-15 |
| https://docs.val.town | 2026-01-15 |
| https://www.val.town/pricing | 2026-01-15 |
| https://docs.riza.io | 2026-01-15 |
| https://namespace.so/compute/sandbox | 2026-07-23 |
| https://namespace.so/docs | 2026-01-15 |
| https://docs.github.com/en/codespaces/prebuilding-your-codespaces | 2026-01-15 |
| https://docs.github.com/en/codespaces | 2026-01-15 |
| https://containers.dev | 2026-01-15 |
| https://docs.github.com/en/billing/managing-billing-for-github-codespaces | 2026-01-15 |
| https://docs.github.com/en/billing | 2026-01-15 |
| https://microsoft.com | 2026-01-15 |
| https://github.blog | 2026-01-15 |
| https://box.ascii.dev/compare | 2026-07-23 |
| https://box.ascii.dev | 2026-07-23 |
| https://exe.dev | 2026-07-23 |
| https://islo.dev | 2026-07-23 |
| https://firecracker-microvm.github.io | 2026-01-15 |

## Related comparisons

- [Coding agents](https://toolweight.dev/compare/coding-agents) — Which AI coding agent should I use in 2026?
- [LLM APIs](https://toolweight.dev/compare/llm-apis) — Which frontier LLM API should I build on?
- [Browser APIs](https://toolweight.dev/compare/browser-automation-apis) — Which hosted browser automation API should I use for AI agents and scraping?
- [Vercel alternatives](https://toolweight.dev/compare/vercel-alternatives) — Which Vercel alternative should I use, and what happens to my bill if my site goes viral?

## Licence and attribution

Data from toolweight (https://toolweight.dev), licensed CC-BY-4.0.

- Licence: [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)
- Canonical HTML: https://toolweight.dev/compare/sandbox-providers
- Machine-readable: https://toolweight.dev/compare/sandbox-providers.md · https://toolweight.dev/api/v1 · https://toolweight.dev/mcp
- toolweight takes no affiliate revenue and sells no placements. Corrections: https://toolweight.dev/suggest