E2B vs Vercel Sandbox

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to E2B
   E2B✓fullprobed9/10

   E2B serves a live llms.txt index (HTTP 200) and .md-suffixed doc pages explicitly designed for agent consumption, with the quickstart page itself pointing agents to the llms.txt index. missing for 10: no independent/community confirmation that agents actually consume llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.e2b.dev/llms.txt # E2B Docs - [E2B Documentation](https://docs.e2b.dev/index.md) - [Running your f…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.e2b.dev/quickstart.md > ## Documentation Index > Fetch the complete documentation index at: https://…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullprobed8/10

   Probes confirm both a working llms.txt at the root domain (vercel.com/llms.txt, HTTP 200) and a markdown-formatted docs endpoint for Sandbox specifically (sandbox.md, HTTP 200), which are exactly the agent-oriented docs formats this story asks for. Missing for 10: no explicit evidence llms.txt itself deep-links to sandbox-specific docs, and no independent/community confirmation of an agent successfully consuming these files.

   • [probe] “PROBE llms.txt: HTTP 200 at https://vercel.com/llms.txt # Vercel > Vercel is a cloud platform for building, deploying, and scaling web appl…”
   • [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs/sandbox.md --- title: Vercel Sandbox product: vercel url: /docs/sandbox canonical_url: "h…”
   • [claimed-docs] “Connect to and manage Sandboxes from the dashboard”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   E2B✓fullclaimed8/10

   E2B has a documented CLI, SDK, and non-interactive auth mode explicitly recommended for CI/CD pipelines, servers, and containers, plus scriptable sandbox lifecycle (create, exec with --background, shutdown, snapshot) and webhooks for lifecycle events — all consistent with headless/CI automation. missing for 10: no independent third-party report of a real CI pipeline using E2B, and no explicit CI provider integration examples (e.g., GitHub Actions workflow snippet).

   • [claimed-docs] “This is the recommended option for non-interactive environments like CI/CD pipelines, servers, and containers. Set a single environment vari…”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”
   • [claimed-docs] “Use the `--background` flag to run a command in the background and return immediately.”
   • [claimed-docs] “You can shutdown single or all running sandboxes with the E2B CLI.”
   • [claimed-docs] “Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur.”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or BYOC or self-hosted deployments — create an `E2B` client and…”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or [BYOC or self-hosted deployments](/byoc) in a single process…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullprobed8/10

   Vercel Sandbox is designed for headless/programmatic use via SDKs (@vercel/sandbox) and a CLI, with access tokens explicitly documented for external CI/CD systems and non-Vercel environments, plus OpenAPI-backed REST access confirmed by probe. missing for 10: no explicit third-party/independent CI pipeline case study or GitHub Actions example demonstrating real-world headless automation.

   • [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
   • [claimed-docs] “Use access tokens when `VERCEL_OIDC_TOKEN` is unavailable, such as in external CI/CD systems or non-Vercel environments.”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
   • [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   E2B—none0/10

   E2B is a sandbox/code-execution infrastructure product (not itself an agent), so an official MCP server exposing its sandbox tools to agents is a fair, applicable axis. The evidence pack documents SDKs, CLI, templates, and LLM tool-use integration (e2b-docs-32) but never mentions an MCP server, official MCP integration, or MCP protocol support anywhere.

   • [claimed-docs] “E2B can work with any LLM and AI framework. The easiest way to connect an LLM to E2B is to use the tool use capabilities of the LLM”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”
   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Vercel Sandbox is an execution/infrastructure product (not itself an agent), so an official MCP server exposing it to agents is a fair, applicable axis; however no evidence in the pack mentions MCP, an MCP server, or any agent-protocol integration—only SDKs, CLI, and REST/OpenAPI docs are described.

   ⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to E2B
   E2B✓fullprobed8/10

   E2B ships an official CLI documented extensively (create/connect/exec/list/shutdown/snapshot/auth/metrics commands) covering sandbox lifecycle management, well-suited for AI-native agentic workflows. missing for 10: independent/hands-on community validation of the CLI itself (community evidence only covers SDK usage, not CLI) and no evidence of CLI-specific agent integration examples.

   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”
   • [claimed-docs] “You can create a sandbox and connect an interactive terminal to it.”
   • [claimed-docs] “This will return running sandboxes, you can specify `--state` to get paused or both.”
   • [claimed-docs] “You can shutdown single or all running sandboxes with the E2B CLI.”
   • [claimed-docs] “You can manage sandbox snapshots with the `e2b sandbox snapshot` (alias `snap`) commands.”
   • [claimed-docs] “If your E2B account has access to more than one project, you can choose which one the CLI uses”
   • [claimed-docs] “This is the recommended option for non-interactive environments like CI/CD pipelines, servers, and containers. Set a single environment vari…”
   • [claimed-docs] “e2b sandbox create <template>”
   • [claimed-docs] “Unlike the `create` command, `connect` does not kill the sandbox when you disconnect.”
   • [claimed-docs] “Use the `--background` flag to run a command in the background and return immediately.”
   • [claimed-docs] “To shutdown all running sandboxes, run the following command:”
   • [claimed-docs] “You can name the snapshot template with the `--name` flag. If a template with that name already exists, it is reused.”
   • [probe] “official CLI documented at https://docs.e2b.dev/cli”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed7/10

   Vercel Sandbox ships an official `sandbox` CLI explicitly positioned for manual testing, agentic workflows, debugging, and one-off operations, with documented commands like `sandbox create --name` and `sandbox run`. missing for 10: independent/hands-on corroboration beyond vendor docs, and no CLI reference/full command list shown.

   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “Create with an explicit name sandbox create --name my-sandbox”
   • [claimed-docs] “sandbox run echo "Hello Sandbox!"”
   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Vercel Sandbox
   E2B✓fullprobed8/10

   E2B ships extensive documented SDK/CLI APIs (Sandbox.create, files.read/write, commands.run, timeouts, metrics, snapshots, webhooks) with quickstart and reference docs, and explicit LLM/agent integration guides (connect-llms, coding-agents), demonstrating a fully documented public API surface for AI-native use. Missing for 10: no discoverable formal OpenAPI/swagger spec (probe found 404s across candidate paths) and no independent third-party audit of API completeness beyond vendor docs/community anecdotes.

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “You can write single files to the sandbox filesystem using the `files.write()` method.”
   • [claimed-docs] “You can run terminal commands inside the sandbox using the `commands.run()` method.”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or BYOC or self-hosted deployments — create an `E2B` client and…”
   • [claimed-docs] “E2B can work with any LLM and AI framework. The easiest way to connect an LLM to E2B is to use the tool use capabilities of the LLM”
   • [claimed-docs] “Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.e2b.dev/openapi.json, https://docs.e2b.dev/swagger.json, https://docs.e2b.dev/api/opena…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullprobed9/10

   Vercel Sandbox is explicitly built for agentic/AI use cases and exposes a documented SDK (@vercel/sandbox), CLI, and REST API (openapi.json) for programmatic control—creating sandboxes, running commands, streaming logs, managing files, images, and persistence. This directly satisfies driving the product via a documented public API for AI-native workflows. Missing for 10: independent third-party corroboration beyond vendor docs/probe checks.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs/sandbox.md --- title: Vercel Sandbox product: vercel url: /docs/sandbox canonical_url: "h…”
   • [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   E2B—none0/10

   Evidence shows E2B supports multiple API keys per team/project (e2b-docs-30, e2b-docs-31, e2b-docs-34, e2b-docs-35) but no documentation of scoped or least-privilege permissions (e.g., read-only, sandbox-restricted, rate-limited keys) that would let an AI-native user issue a restricted credential to an agent.

   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or BYOC or self-hosted deployments — create an `E2B` client and…”
   • [claimed-docs] “If your E2B account has access to more than one project, you can choose which one the CLI uses”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or [BYOC or self-hosted deployments](/byoc) in a single process…”
   • [claimed-docs] “This is the recommended option for non-interactive environments like CI/CD pipelines, servers, and containers. Set a single environment vari…”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Evidence only describes authentication mechanisms (automatic OIDC token in production, access tokens for CI/CD) but nowhere documents scoped or least-privilege permission models for these credentials — no mention of granular scopes, role restrictions, or per-agent credential limits.

   • [claimed-docs] “In production on Vercel, authentication is automatic.”
   • [claimed-docs] “Use access tokens when `VERCEL_OIDC_TOKEN` is unavailable, such as in external CI/CD systems or non-Vercel environments.”
   • [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to E2B
   E2B✓fullprobed8/10

   E2B ships official SDKs (JS/Python) with extensive first-party docs covering sandbox creation, code execution, filesystem, commands, metrics, persistence, and explicit guidance for connecting LLMs/agent frameworks (e2b-docs-1,7,8,32,42-44), plus a CLI (e2b-docs-9, e2b-probe-4) and community confirmation of Python/TS SDK availability (e2b-comm-1). missing for 10: broader independent/hands-on validation beyond one HN thread, and no discoverable OpenAPI spec for programmatic SDK generation (e2b-probe-3).

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “You can write single files to the sandbox filesystem using the `files.write()` method.”
   • [claimed-docs] “You can run terminal commands inside the sandbox using the `commands.run()` method.”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”
   • [claimed-docs] “E2B can work with any LLM and AI framework. The easiest way to connect an LLM to E2B is to use the tool use capabilities of the LLM”
   • [claimed-docs] “E2B provides a pre-built `claude` template with Claude Code already installed.”
   • [claimed-docs] “With the E2B backend, the agent's built-in tools all execute inside an isolated sandbox instead of your machine”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”
   • [community] “E2B does support Python, AgentKit is only available in TypeScript for now.”
   • [probe] “official CLI documented at https://docs.e2b.dev/cli”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed7/10

   Vercel Sandbox offers an official `@vercel/sandbox` SDK for JS/TS plus a CLI, with docs on authentication, commands, and sandbox lifecycle management — evidence that AI-native builders have a first-party SDK to integrate against. missing for 10: no mention of official SDKs for other languages (e.g., Python), no independent/hands-on corroboration of SDK usage beyond vendor docs.

   • [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
   • [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to E2B
   E2B✓fullclaimed6/10

   E2B docs explicitly describe webhooks that deliver notifications to an external server on sandbox lifecycle events, directly matching the story. Missing for 10: detailed docs on event types/payload schema, setup/configuration steps, and independent/community corroboration of webhook usage.

   • [claimed-docs] “Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Evidence covers sandbox creation, execution modes, persistence, and streaming logs from detached commands, but there is no mention of webhooks or event subscription mechanisms for external systems to receive Sandbox events.

   ⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   E2B~partialclaimed5/10

   E2B provides persistent, resumable sandboxes, background command execution (--background flag), webhooks for lifecycle events, and long-running session support (up to 24h, pause/resume), which are building blocks for autonomous background automation. However, there's no evidence of a native scheduler/cron, no first-party 'automation' orchestration layer, and no documented trigger system beyond webhooks — the user must build the autonomy logic themselves using an external agent/LLM. missing for 10: native scheduling/cron or trigger orchestration, evidence of fully autonomous multi-step agent loops running unattended, independent case studies of long-running unattended automations.

   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”
   • [claimed-docs] “A paused sandbox is kept indefinitely with no automatic deletion.”
   • [claimed-docs] “Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base). For longer workloads, use pause and resume”
   • [claimed-docs] “Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur.”
   • [claimed-docs] “Use the `--background` flag to run a command in the background and return immediately.”
   • [claimed-docs] “Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access.”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed5/10

   Vercel Sandbox supports running agent-generated code, detached/background commands with log streaming, timeouts/extension, and persistence/resume, which enable building autonomous background automations. However, there's no built-in scheduler, trigger system, or native 'automation' orchestration layer — users must build their own scheduling/trigger logic around the SDK/CLI. missing for 10: native scheduling/cron or event-trigger mechanism, independent evidence of long-running unattended automations in production, and explicit 'autonomous background job' framing beyond detached commands.

   • [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
   • [claimed-docs] “Stream logs from a detached command”
   • [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
   • [claimed-docs] “Persistent sandboxes: Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot m…”
   • [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
   • [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to E2B
   E2B~partialclaimed5/10

   E2B's own interface is programmatic (SDK calls like Sandbox.create(), files.read(), commands.run()) and a CLI (e2b-docs-9), not a natural-language command surface; however docs explicitly describe connecting LLMs via tool-use so an AI agent can drive E2B through natural-language-triggered function calls (e2b-docs-32, e2b-docs-28, e2b-docs-43). This shows AI-native operation is possible only indirectly through an LLM/agent layer, not as a built-in NL command mode of the product itself. missing for 10: no first-party NL chat/command interface for E2B itself, no evidence of a natural-language CLI or prompt-driven control plane, only indirect LLM tool-use integration documented.

   • [claimed-docs] “E2B can work with any LLM and AI framework. The easiest way to connect an LLM to E2B is to use the tool use capabilities of the LLM”
   • [claimed-docs] “Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access.”
   • [claimed-docs] “With the E2B backend, the agent's built-in tools all execute inside an isolated sandbox instead of your machine”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Vercel Sandbox is designed to run agent-generated code and is explicitly marketed for 'agent workflows,' but the evidence only describes CLI commands (`sandbox create`, `sandbox run`) and SDK calls, not a natural-language interface for operating the product itself. No documentation shows a chat/NL command layer for creating or managing sandboxes. Missing for 10: any NL command parser, chat-driven CLI, or natural-language API for controlling Sandbox operations.

   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “Create with an explicit name sandbox create --name my-sandbox”
   • [claimed-docs] “sandbox run echo "Hello Sandbox!"”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   E2B—none0/10

   Evidence shows extensive static documentation with code snippets (e2b-docs-1, e2b-docs-2, etc.) but no evidence of an interactive, runnable API reference — the probe explicitly found no OpenAPI/Swagger spec (e2b-probe-3), and no playground or 'try it' console is mentioned anywhere in the pack.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.e2b.dev/openapi.json, https://docs.e2b.dev/swagger.json, https://docs.e2b.dev/api/opena…”
   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “We’ll write the minimal code for starting Sandbox, executing Python inside it and listing all files inside the root directory.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Evidence shows Vercel has an OpenAPI spec and Sandbox docs, but nothing describes an interactive API reference with runnable/live examples for Sandbox itself — no docs playground, no 'try it' console, no runnable code snippets in-page. missing for 10: interactive API reference UI, runnable example execution in docs, evidence of a docs playground feature.

   • [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Vercel Sandbox
   E2B—none0/10

   E2B exposes SDKs and a CLI, but active probing found no OpenAPI/swagger spec at any standard location (all candidate paths returned 404), and no documentation page references a machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.e2b.dev/openapi.json, https://docs.e2b.dev/swagger.json, https://docs.e2b.dev/api/opena…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullprobed9/10

   A probe confirms Vercel publishes a machine-readable OpenAPI spec at https://vercel.com/openapi.json which validly contains the 'openapi' key, and Sandbox is part of Vercel's documented API/SDK surface. Missing for 10: no explicit confirmation that Sandbox-specific endpoints are included in that spec versus general Vercel API.

   • [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   E2B✓fullclaimed8/10

   E2B provides fully isolated, ephemeral cloud sandboxes (Firecracker microVMs) for running AI-generated code, with no connection to production systems — sandboxes are created fresh from templates, have their own filesystem/network, and can be killed or auto-expire, ensuring test isolation. Persistence/pause-resume and metrics further support safe iterative testing without touching real data. Missing for 10: explicit documentation or case study contrasting sandbox vs production data separation, and independent/hands-on verification beyond vendor docs.

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”
   • [claimed-docs] “You can shutdown the sandbox any time even before the timeout is up by calling the `kill` method.”
   • [claimed-docs] “Every sandbox has outbound internet access by default. Control and restrict it with a simple on/off switch or fine-grained allow and deny li…”
   • [claimed-docs] “E2B templates allow you to define custom sandboxes. You can define the base image, environment variables, files to copy, commands to run, an…”
   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Vercel Sandbox is explicitly designed to run untrusted/agent-generated code in isolated Linux microVMs 'without exposing your production systems,' with per-agent isolation, ephemeral or persistent state, and no shared access to production infrastructure. This directly matches the AI-native story of testing agent code safely away from production data. missing for 10: independent/hands-on evidence of real-world isolation guarantees, and explicit documentation on data-boundary controls preventing production data leakage into sandboxes.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
   • [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   E2B—none0/10

   The evidence pack covers SDK usage, CLI commands, sandbox lifecycle, and self-hosting, but contains no mention of API versioning scheme, changelog, or a documented deprecation policy; the openapi probe even returned 404s. This is a fair axis for an API-first product, but no evidence supports it.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.e2b.dev/openapi.json, https://docs.e2b.dev/swagger.json, https://docs.e2b.dev/api/opena…”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   The evidence pack shows SDK/CLI docs, features, and an OpenAPI spec, but no mention of API versioning scheme or a documented deprecation policy for Vercel Sandbox's APIs. Some features are explicitly marked 'beta' (docs-14, docs-44), suggesting instability without a stated deprecation process. missing for 10: explicit API version numbers, a deprecation/sunset policy, changelog entries documenting breaking-change handling.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to E2B
   E2B~partialclaimed5/10

   E2B supports several bulk-adjacent capabilities: up to 100 concurrent sandboxes, writing multiple files at once, listing all sandboxes, and shutting down single or all running sandboxes via CLI. However there is no unified batch/bulk API (e.g., no evidence of submitting a list of code executions or files to process as one bulk call) — bulk behavior is assembled from separate CLI/SDK primitives rather than a first-class bulk-operations feature. Missing for 10: a documented batch execution or bulk-processing API, evidence of bulk operations on non-sandbox resources (e.g., bulk template management), and independent/hands-on validation of bulk workflows at scale.

   • [claimed-docs] “Up to 24-hour sandbox session length Up to 100 concurrently running sandboxes”
   • [claimed-docs] “You can also write multiple files to the sandbox.”
   • [claimed-docs] “This will return running sandboxes, you can specify `--state` to get paused or both.”
   • [claimed-docs] “You can shutdown single or all running sandboxes with the E2B CLI.”
   • [claimed-docs] “To shutdown all running sandboxes, run the following command:”
   • [claimed-docs] “Use the `--background` flag to run a command in the background and return immediately.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Vercel Sandbox docs describe creating/running individual sandboxes, multi-agent isolation, and SDK-driven command execution, but there is no evidence of a bulk/batch operation feature for processing many items at once (e.g., batch job APIs, fan-out orchestration, or bulk file/task processing).

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to E2B
   E2B~partialclaimed3/10

   E2B offers webhooks that deliver notifications for sandbox lifecycle events, which is a minimal building block for event-triggered automation, but there is no evidence of an actual rule-engine (defining conditional actions that execute automatically) beyond forwarding notifications to an external server. missing for 10: built-in conditional rule definitions, in-product automatic action execution, and any hands-on evidence of the webhook mechanism working end-to-end.

   • [claimed-docs] “Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   E2B—none0/10

   E2B provides sandbox creation, execution, persistence (pause/resume), and lifecycle webhooks, but nothing in the evidence pack describes a native scheduler, cron-like trigger, or recurring workflow mechanism — scheduling would have to be built by the user via external tooling. This axis is fair for an automation-focused sandbox platform, so absence of evidence means 'none' rather than 'na'.

   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”
   • [claimed-docs] “A paused sandbox is kept indefinitely with no automatic deletion.”
   • [claimed-docs] “Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur.”
   • [claimed-docs] “When you call the set timeout method, the sandbox timeout will be reset to the new value that you specified.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Vercel Sandbox provides on-demand ephemeral/persistent execution environments with manual creation, timeouts, and resumption, but no evidence of a scheduler, cron-like trigger, or recurring job orchestration feature; scheduling would need to be built externally (e.g., Vercel Cron) which isn't documented here as part of Sandbox itself.

   • [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
   • [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
   • [claimed-docs] “Or retrieve an existing sandbox by name (resumes if stopped)”

   proof ↗⚑ flag

Agent workloads

1. ai-native userRun coding agents like Claude Code or Codex inside the sandbox following the vendor's own recipe

   weight 2 · round to E2B
   E2B✓fullclaimed8/10

   E2B provides a dedicated vendor recipe ('Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access') and a pre-built `claude` template with Claude Code already installed, plus similar guides for other agent frameworks. This is a first-party documented recipe with concrete setup instructions. Missing for 10: independent/hands-on confirmation that Codex specifically runs smoothly (community evidence only discusses a different agent framework's rough edges, not Claude Code/Codex directly), and no third-party benchmark of the recipe's reliability.

   • [claimed-docs] “Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access.”
   • [claimed-docs] “E2B provides a pre-built `claude` template with Claude Code already installed.”
   • [claimed-docs] “With the E2B backend, the agent's built-in tools all execute inside an isolated sandbox instead of your machine”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed6/10

   Docs confirm the default 'vercel/sandbox/universal' image ships with coding agents preinstalled and highlight agent workflows (e.g. Claude Code/Codex-style use), but the evidence pack lacks an explicit vendor 'recipe' walkthrough naming Claude Code or Codex step-by-step. missing for 10: a dedicated vendor tutorial/recipe explicitly running Claude Code or Codex inside the sandbox, and independent hands-on confirmation of this exact workflow.

   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
   • [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”

   proof ↗⚑ flag

Workloads

1. developerRun a headless browser or full desktop environment inside the sandbox

   weight 2 · round to E2B
   E2B~partialclaimed6/10

   E2B's GitHub README confirms a separate 'Desktop SDK' providing mouse, keyboard, screenshot, application, and desktop streaming APIs for full desktop environments, but this is an add-on SDK rather than a built-in feature of the core Sandbox class documented elsewhere. There's no first-party doc page (e.g., under docs.e2b.dev) detailing headless browser support or code examples for it. missing for 10: dedicated docs/quickstart for the Desktop SDK, headless browser (e.g., Chromium/Playwright) usage examples, independent hands-on confirmation of desktop streaming reliability.

   • [github] “For mouse, keyboard, screenshot, application, and desktop streaming APIs, install the Desktop SDK”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Evidence describes Linux microVMs, custom OCI images, and general code execution, but nothing mentions headless browser support, display/VNC, GUI desktop environments, or browser automation tooling. missing for 10: any mention of headless browser (e.g., Chromium/Playwright) support, GPU/display capabilities, or desktop environment provisioning.

   ⚑ flag

2. developerAttach GPUs to sandboxed workloads

   weight 2 · round drawn
   E2B—none0/10

   No evidence anywhere in the pack mentions GPU support, GPU attachment, or GPU-enabled sandboxes; docs only reference customizable CPU & RAM, disk, and memory metrics. This is a fair question for a sandbox/compute infrastructure product, but nothing indicates GPU capability is offered.

   • [claimed-docs] “Customize your Sandbox CPU & RAM”
   • [claimed-docs] “Up to 24-hour sandbox session length Up to 100 concurrently running sandboxes”
   • [claimed-docs] “The sandbox metrics allows you to get information about the sandbox's CPU, memory and disk usage.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   No evidence anywhere in the docs mentions GPU support or GPU attachment for Vercel Sandbox; sandboxes are described only as CPU-based Linux microVMs with system-privileged process support, storage/drives, and networking. missing for 10: any mention of GPU hardware, GPU-enabled images, or GPU pricing/quota.

   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need.”
   • [claimed-docs] “System-privileged processes: Run workloads that need system-level privileges, such as container runtimes like Docker, VPN clients, and FUSE …”
   • [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”

   proof ↗⚑ flag

Files

1. developerRead, write, upload, and download files in the sandbox filesystem via the SDK

   weight 2 · round to E2B
   E2B✓fullclaimed8/10

   E2B SDK docs clearly document files.write() and files.read() for single and multiple files, plus files.list() for directory listing, covering read/write/list operations via the SDK. Upload/download is implicit in write/read of file content but not explicitly named as 'upload/download' with byte-stream examples. missing for 10: explicit upload/download terminology or examples (e.g., binary file transfer, streaming), independent/hands-on corroboration beyond docs.

   • [claimed-docs] “You can write single files to the sandbox filesystem using the `files.write()` method.”
   • [claimed-docs] “You can read files from the sandbox filesystem using the `files.read()` method.”
   • [claimed-docs] “You can also write multiple files to the sandbox.”
   • [claimed-docs] “const files = await sbx.files.list('/')”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed6/10

   Docs confirm the SDK provides a programmatic interface to manage files (mount remote storage, drives, filesystem persistence via snapshots) and general file access is implied through 'file edits' and FUSE-mounted storage, but no explicit documentation of discrete SDK methods like sandbox.writeFiles(), readFile(), or upload/download APIs is present. missing for 10: explicit SDK method documentation/examples for read, write, upload, and download file operations, and independent/hands-on confirmation of these specific API calls.

   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [claimed-docs] “Mount an external object store such as Amazon S3 with a FUSE driver, and read and write remote files through the sandbox filesystem.”
   • [claimed-docs] “Drives (beta): Attach persistent filesystem storage to sandboxes and reuse data across sandbox runs.”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
   • [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”

   proof ↗⚑ flag

Runtimes

1. developerDefine custom sandbox templates or bring my own container image

   weight 2 · round drawn
   E2B✓fullclaimed9/10

   E2B templates explicitly let developers define a custom base image, environment variables, files, commands, and start command, and the CLI supports building/naming/snapshotting templates for reuse; this is well-documented first-party functionality with CLI tooling support. Missing for 10: no independent/hands-on third-party confirmation of custom template builds succeeding in practice.

   • [claimed-docs] “E2B templates allow you to define custom sandboxes. You can define the base image, environment variables, files to copy, commands to run, an…”
   • [claimed-docs] “This gives you fully configured sandboxes with running processes ready to use with zero wait time for your users.”
   • [claimed-docs] “You can name the snapshot template with the `--name` flag. If a template with that name already exists, it is reused.”
   • [claimed-docs] “You can manage sandbox snapshots with the `e2b sandbox snapshot` (alias `snap`) commands.”
   • [claimed-docs] “e2b sandbox create <template>”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed9/10

   Docs explicitly support custom sandbox templates and BYO container images: users can build custom OCI images stored in Vercel Container Registry, start sandboxes from managed, shared/public, or custom images, and Docker-image-based workflows are directly supported. Also supports snapshotting for reusable custom environments. missing for 10: independent/hands-on corroboration of custom image builds beyond first-party docs.

   • [claimed-docs] “Build your system packages and tooling into an image, and share it across projects and teams.”
   • [claimed-docs] “If you already use Docker images to define your environment, store the image in Vercel Container Registry (VCR) and create the sandbox with …”
   • [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”
   • [claimed-docs] “Managed and custom images: Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel C…”
   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”

   proof ↗⚑ flag

2. developerExecute code in multiple language runtimes (Python, JavaScript, and more) and get rich results back

   weight 2 · round to E2B
   E2B✓fullclaimed8/10

   E2B's docs show runCode execution (e2b-docs-1, e2b-docs-21) with sandboxes supporting Python and JavaScript SDKs, plus file I/O and terminal command execution for rich interaction with results (e2b-docs-7, e2b-docs-8, e2b-docs-19). It's explicitly positioned for running AI-generated code across languages with tool-use integration (e2b-docs-32, e2b-docs-33). missing for 10: explicit enumeration of all supported language runtimes beyond Python/JS/CLI, and independent hands-on confirmation of 'rich results' (e.g., charts/images) beyond docs claims.

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “We’ll write the minimal code for starting Sandbox, executing Python inside it and listing all files inside the root directory.”
   • [claimed-docs] “You can write single files to the sandbox filesystem using the `files.write()` method.”
   • [claimed-docs] “You can run terminal commands inside the sandbox using the `commands.run()` method.”
   • [claimed-docs] “You can read files from the sandbox filesystem using the `files.read()` method.”
   • [claimed-docs] “E2B can work with any LLM and AI framework. The easiest way to connect an LLM to E2B is to use the tool use capabilities of the LLM”
   • [claimed-docs] “You can use E2B Sandbox to run AI-generated code to analyze data.”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed7/10

   Docs confirm sandboxes run Linux images with Python 3.14 and Node.js LTS pre-installed by default, plus support for any other Linux distro via custom OCI images, enabling multi-language execution (JS/TS, Python, and more) (docs-5, docs-8, docs-34, docs-30). Execution results are surfaced via logs, streamed output, and file access (docs-19, docs-20, docs-26), but there's no explicit mention of structured/rich result formats (e.g., images, dataframes, plots) beyond logs and files. Missing for 10: explicit support for rich/structured output types (charts, tables, media) and independent hands-on confirmation of multi-language fidelity.

   • [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need.”
   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
   • [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”
   • [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
   • [claimed-docs] “Stream logs from a detached command”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”

   proof ↗⚑ flag

Untrusted code

1. developerExecute untrusted, AI-generated code without risking my own infrastructure

   weight 3 · round drawn
   E2B✓fullclaimed9/10

   E2B is explicitly designed as isolated sandbox infrastructure (Firecracker microVMs) to run AI-generated/untrusted code without touching the developer's own machine, with persistence, network controls, resource limits, and self-hosting/BYOC options for stricter isolation needs (e2b-gh-3, e2b-docs-44, e2b-docs-10, e2b-gh-2). Docs also show direct integration for coding agents (Claude Code, Codex, Amp) executing in these sandboxes with full filesystem/terminal access (e2b-docs-28, e2b-docs-42). Missing for 10: independent third-party security audit or hands-on penetration-test evidence beyond vendor docs/GitHub description.

   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”
   • [claimed-docs] “Every sandbox has outbound internet access by default. Control and restrict it with a simple on/off switch or fine-grained allow and deny li…”
   • [github] “Read the self-hosting guide to learn how to set up the E2B infrastructure on your own. The infrastructure is deployed using Terraform.”
   • [claimed-docs] “Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access.”
   • [claimed-docs] “E2B provides a pre-built `claude` template with Claude Code already installed.”
   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed9/10

   Vercel Sandbox's docs directly describe running untrusted or AI agent-generated code in isolated Linux microVMs without exposing production systems, with per-agent isolation, configurable timeouts, and managed images—precisely matching the story. Missing for 10: independent/hands-on verification beyond first-party docs.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
   • [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”

   proof ↗⚑ flag

2. developerRun arbitrary shell commands and install packages inside the sandbox

   weight 2 · round to E2B
   E2B✓fullclaimed9/10

   E2B docs explicitly document commands.run() for executing arbitrary shell commands inside sandboxes, plus CLI exec-command support with background flag, and templates allow custom package installation via build commands. Combined with file read/write and persistent sandbox sessions, this directly delivers arbitrary shell execution and package installation. Missing for 10: independent hands-on benchmark specifically verifying package installation success/failure rates.

   • [claimed-docs] “You can run terminal commands inside the sandbox using the `commands.run()` method.”
   • [claimed-docs] “Use the `--background` flag to run a command in the background and return immediately.”
   • [claimed-docs] “E2B templates allow you to define custom sandboxes. You can define the base image, environment variables, files to copy, commands to run, an…”
   • [claimed-docs] “You can create a sandbox and connect an interactive terminal to it.”
   • [claimed-docs] “e2b sandbox create <template>”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Docs clearly show running arbitrary commands (blocking/detached modes, `sandbox run echo ...`, CLI and SDK) inside Linux microVMs, with custom images and full Linux distros allowing package installs (e.g., Ubuntu/Arch, custom OCI images, system-privileged processes). missing for 10: no independent/hands-on report confirming package installation workflows beyond first-party docs.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need.”
   • [claimed-docs] “System-privileged processes: Run workloads that need system-level privileges, such as container runtimes like Docker, VPN clients, and FUSE …”
   • [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “Sandboxes run Linux images, with Ubuntu, Arch Linux, or any other Linux distribution you need. The default image is `vercel/sandbox/universa…”
   • [claimed-docs] “sandbox run echo "Hello Sandbox!"”
   • [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”

   proof ↗⚑ flag

Agent lifecycle

1. ai-native userMy agent can provision its own sandbox, execute code, read the results, and tear it down — end to end without a human

   weight 3 · round to E2B
   E2B✓fullclaimed9/10

   E2B's SDK API directly supports programmatic sandbox creation, code execution, filesystem read/write, and teardown/kill — all callable by an agent without human intervention (e2b-docs-1, e2b-docs-6, e2b-docs-19, e2b-docs-8). Docs explicitly describe running AI coding agents like Claude Code/Codex end-to-end in sandboxes with full terminal/filesystem access (e2b-docs-28, e2b-docs-42, e2b-docs-43), and timeouts/kill provide automated teardown. Missing for 10: no independent hands-on benchmark of a fully autonomous end-to-end agent loop (only vendor docs and one community note about agent friction, not a failure of the core provision/execute/teardown flow).

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “You can shutdown the sandbox any time even before the timeout is up by calling the `kill` method.”
   • [claimed-docs] “You can read files from the sandbox filesystem using the `files.read()` method.”
   • [claimed-docs] “You can run terminal commands inside the sandbox using the `commands.run()` method.”
   • [claimed-docs] “Run AI coding agents like Claude Code, Codex, and Amp in secure E2B sandboxes with full terminal, filesystem, and git access.”
   • [claimed-docs] “E2B provides a pre-built `claude` template with Claude Code already installed.”
   • [claimed-docs] “With the E2B backend, the agent's built-in tools all execute inside an isolated sandbox instead of your machine”
   • [claimed-docs] “When you call the set timeout method, the sandbox timeout will be reset to the new value that you specified.”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Vercel Sandbox provides a full programmatic SDK/CLI to create sandboxes (with names, custom images, regions), run blocking or detached commands, stream logs/output, and stop/tear down sandboxes, with API-based authentication (OIDC/tokens) suitable for unattended agent use — no human-in-the-loop required. missing for 10: no independent/hands-on third-party report confirming an agent autonomously completing the full provision-execute-teardown loop, and no explicit example showing an agent reading command output/results programmatically end-to-end.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
   • [claimed-docs] “Commands can run in blocking mode (wait for completion) or detached mode (return immediately).”
   • [claimed-docs] “Stream logs from a detached command”
   • [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [claimed-docs] “For local development, run `vercel link` and `vercel env pull` to get a development token. In production on Vercel, authentication is automa…”
   • [claimed-docs] “Create with an explicit name sandbox create --name my-sandbox”
   • [claimed-docs] “sandbox run echo "Hello Sandbox!"”

   proof ↗⚑ flag

Isolation

1. platform-engineerRely on a documented hard isolation boundary (microVM or equivalent) between sandboxes and my systems

   weight 3 · round to E2B
   E2B✓fullclaimed8/10

   E2B docs explicitly state that code runs 'in an isolated Firecracker microVM instead of your server' with network controls and pause/resume, directly documenting the hard isolation boundary platform engineers need. Missing for 10: independent third-party security audit or pentest report, and more detail on the isolation boundary's guarantees beyond a single doc line.

   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”
   • [claimed-docs] “With the E2B backend, the agent's built-in tools all execute inside an isolated sandbox instead of your machine”
   • [claimed-docs] “Every sandbox has outbound internet access by default. Control and restrict it with a simple on/off switch or fine-grained allow and deny li…”
   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed6/10

   Vercel's first-party docs repeatedly and explicitly claim microVM-based isolation for running untrusted/agent-generated code without exposing production systems, plus additional isolation features (per-agent Linux users, system-privileged process support). However, all evidence is vendor documentation with no independent security audit, third-party penetration test, or technical deep-dive into the underlying microVM technology (e.g. Firecracker) confirming the boundary in practice. missing for 10: independent/third-party verification of the isolation boundary, technical detail on the hypervisor/microVM implementation, and any hands-on security assessment.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”
   • [claimed-docs] “System-privileged processes: Run workloads that need system-level privileges, such as container runtimes like Docker, VPN clients, and FUSE …”
   • [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”

   proof ↗⚑ flag

2. ai-native userGive an agent a sandbox where host secrets and credentials are unreachable by the code it runs

   weight 2 · round to Vercel Sandbox
   E2B✓fullclaimed7/10

   E2B's docs and repo repeatedly describe sandboxes as isolated Firecracker microVMs separate from the host/server ('your agent's code runs in an isolated Firecracker microVM instead of your server', 'isolated sandbox instead of your machine'), and network access to the sandbox can be restricted via allow/deny lists, all supporting the claim that a sandboxed agent cannot reach host resources. However, there is no explicit documentation or hands-on test specifically confirming host secrets/credentials (e.g., env vars, cloud IAM creds) are unreachable from sandboxed code, nor independent security audit evidence. Missing for 10: explicit secret/credential-isolation guarantees, third-party security audit or hands-on penetration test confirming host secrets are unreachable.

   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”
   • [claimed-docs] “With the E2B backend, the agent's built-in tools all execute inside an isolated sandbox instead of your machine”
   • [claimed-docs] “Every sandbox has outbound internet access by default. Control and restrict it with a simple on/off switch or fine-grained allow and deny li…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Vercel Sandbox docs explicitly describe running agent-generated/untrusted code in isolated Linux microVMs 'without exposing your production systems,' and support per-agent Linux user isolation, which directly implies host secrets/credentials are not reachable by sandboxed code. missing for 10: explicit documentation of how host secrets/env vars are excluded or scoped from the sandbox environment, and independent/hands-on verification of this isolation guarantee.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Execute untrusted code safely: Run AI agent output, user uploads, or third-party scripts without exposing your production systems.”
   • [claimed-docs] “Multi-agent isolation: Give each AI agent its own Linux user with a private home directory, and share files between agents with groups.”
   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs.”

   proof ↗⚑ flag

Network policy

1. platform-engineerRestrict or allow the sandbox's network egress with explicit policy

   weight 3 · round to E2B
   E2B✓fullclaimed8/10

   E2B docs explicitly document network egress control: outbound internet access is on by default and can be restricted via 'a simple on/off switch or fine-grained allow and deny lists,' directly matching the platform-engineer's need for explicit egress policy. missing for 10: independent/hands-on verification of allow/deny list behavior, and detailed policy syntax/API reference beyond the summary.

   • [claimed-docs] “Every sandbox has outbound internet access by default. Control and restrict it with a simple on/off switch or fine-grained allow and deny li…”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   No evidence in the pack mentions network egress controls, firewall rules, or outbound traffic policy for Vercel Sandbox—coverage focuses on isolation via microVMs, filesystem, images, and multi-agent user separation but never explicit egress allow/deny configuration.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Vercel Sandbox
   E2B~partialprobed6/10

   E2B is API/SDK-first, so most core operations (sandbox create, exec, filesystem, commands, metrics, templates, snapshots, webhooks) are documented as API/CLI actions rather than gated behind a UI, and the CLI mirrors sandbox lifecycle management. However, some UI-surfaced features like Desktop streaming (mouse/keyboard/screenshot) require a separate Desktop SDK, and no public OpenAPI spec was found, making full parity hard to verify. Missing for 10: a confirmed OpenAPI/full REST spec, explicit confirmation that dashboard-only features (e.g., billing, team management) are also API-accessible, independent verification of full UI/API parity.

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “E2B CLI is a command line tool that allows you to manage and interact with sandboxes and templates.”
   • [claimed-docs] “E2B templates allow you to define custom sandboxes. You can define the base image, environment variables, files to copy, commands to run, an…”
   • [claimed-docs] “You can manage sandbox snapshots with the `e2b sandbox snapshot` (alias `snap`) commands.”
   • [claimed-docs] “Webhooks provide a way for notifications to be delivered to an external web server whenever certain sandbox lifecycle events occur.”
   • [github] “For mouse, keyboard, screenshot, application, and desktop streaming APIs, install the Desktop SDK”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.e2b.dev/openapi.json, https://docs.e2b.dev/swagger.json, https://docs.e2b.dev/api/opena…”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or BYOC or self-hosted deployments — create an `E2B` client and…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullprobed7/10

   Vercel Sandbox is fundamentally API/SDK-driven (creation, commands, snapshots, tags, drives, custom images all documented via SDK/CLI), and the dashboard only offers a subset (viewing/stopping sandboxes) that mirrors API capability rather than adding unique UI-only features, and an OpenAPI spec exists confirming programmatic access. Missing for 10: an explicit vendor statement confirming full UI/API parity, and independent confirmation that every dashboard action (e.g., tag/drive management) is scriptable via API with no UI-exclusive features.

   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
   • [claimed-docs] “Connect to and manage Sandboxes from the dashboard”
   • [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to E2B
   E2B~partialclaimed4/10

   E2B is open-source and self-hostable (Terraform-based), and sandbox files can be read/downloaded via files.read()/CLI, giving a technical path to extract data and avoid lock-in, but there is no documented 'export all account data' feature or guarantee of open data formats for account-level artifacts like snapshots/templates. missing for 10: explicit data-export tooling, documented open format guarantees for exported data, account-level export across all sandboxes/snapshots.

   • [github] “Read the self-hosting guide to learn how to set up the E2B infrastructure on your own. The infrastructure is deployed using Terraform.”
   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”
   • [claimed-docs] “You can read files from the sandbox filesystem using the `files.read()` method.”
   • [claimed-docs] “You can manage sandbox snapshots with the `e2b sandbox snapshot` (alias `snap`) commands.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Vercel Sandbox stores state via drives, snapshots, and container images, so data portability is a fair question, but no evidence describes an explicit data-export feature or guarantee of open, exportable formats for that stored state. Missing for 10: any documented export/download-all-data capability, explicit open-format guarantees for drives/snapshots, or migration tooling to leave the platform.

   • [claimed-docs] “Drives (beta): Attach persistent filesystem storage to sandboxes and reuse data across sandbox runs.”
   • [claimed-docs] “Snapshotting: Save the state of a running sandbox to resume later. Skip dependency installation on subsequent runs.”
   • [claimed-docs] “If you already use Docker images to define your environment, store the image in Vercel Container Registry (VCR) and create the sandbox with …”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to E2B
   E2B✓fullclaimed7/10

   GitHub repo description explicitly states 'E2B is an open-source infrastructure' and provides a self-hosting guide with Terraform, corroborating that the source is publicly available and usable, not just marketing docs. Missing for 10: explicit citation of the license name (e.g., Apache/MIT) and independent confirmation of license terms.

   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”
   • [github] “Read the self-hosting guide to learn how to set up the E2B infrastructure on your own. The infrastructure is deployed using Terraform.”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   No evidence that Vercel Sandbox's source code is published under an open license; the evidence pack only covers docs, features, pricing, and API surface, with no mention of a public repo or license.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to E2B
   E2B~partialclaimed6/10

   E2B is explicitly open-source and provides a documented self-hosting guide using Terraform to deploy the infrastructure on your own, plus BYOC/self-hosted deployment options referenced in client docs. However, the evidence lacks depth on self-hosting: no details on required components, hardware/scale limits, maintenance burden, or independent reports of someone successfully self-hosting. missing for 10: detailed self-hosting setup docs/tutorial, independent verification of a working self-hosted deployment, and clarity on feature parity between self-hosted and cloud versions.

   • [github] “Read the self-hosting guide to learn how to set up the E2B infrastructure on your own. The infrastructure is deployed using Terraform.”
   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or BYOC or self-hosted deployments — create an `E2B` client and…”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or [BYOC or self-hosted deployments](/byoc) in a single process…”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Vercel Sandbox is a fully managed, hosted service running on Vercel's own microVM infrastructure (iad1/sfo1/cle1/cdg1 regions); there is no evidence of any self-hostable core, open-source runtime, or on-prem deployment option — it is inherently tied to Vercel's cloud.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Vercel Sandbox is available in the `iad1` (default), `sfo1`, `cle1`, and `cdg1` regions. You can choose the region per sandbox or set a proj…”
   • [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”

   proof ↗⚑ flag

Latency

1. developerStart sandboxes with documented sub-second-to-few-second cold starts

   weight 3 · round drawn
   E2B—none0/10

   The evidence pack describes sandbox creation, persistence, pausing/resuming, and templates with 'zero wait time,' but contains no documented benchmark or specific claim of sub-second-to-few-second cold start times. Missing for 10: any explicit startup latency figures, benchmark data, or documentation stating cold-start speed in seconds.

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “This gives you fully configured sandboxes with running processes ready to use with zero wait time for your users.”
   • [claimed-docs] “E2B templates allow you to define custom sandboxes. You can define the base image, environment variables, files to copy, commands to run, an…”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   The docs describe microVM isolation, snapshotting for faster restarts, and persistence, but no evidence gives concrete cold-start latency figures (e.g., sub-second or few-second boot times) for starting a fresh sandbox. Missing for 10: documented benchmark numbers or explicit cold-start time claims, any independent performance measurement.

   • [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
   • [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”

   proof ↗⚑ flag

Scale

1. platform-engineerRun large concurrent fleets of sandboxes with documented concurrency limits

   weight 3 · round to E2B
   E2B~partialclaimed6/10

   E2B publishes concrete documented concurrency limits (up to 100 concurrently running sandboxes, up to 24-hour session length on Pro plans) and metrics/CLI tooling to manage fleets, giving platform engineers real numbers to plan around. However missing for 10: no documentation of how limits scale for enterprise/self-hosted deployments, no guidance on requesting higher concurrency, no independent/hands-on benchmarks validating fleet behavior at scale, and no discussion of failure modes or queuing when limits are hit.

   • [claimed-docs] “Up to 24-hour sandbox session length Up to 100 concurrently running sandboxes”
   • [claimed-docs] “Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base). For longer workloads, use pause and resume”
   • [claimed-docs] “The sandbox metrics allows you to get information about the sandbox's CPU, memory and disk usage.”
   • [claimed-docs] “Getting the metrics of a sandbox returns an array of timestamped metrics containing CPU, memory and disk usage information.”
   • [github] “Read the self-hosting guide to learn how to set up the E2B infrastructure on your own. The infrastructure is deployed using Terraform.”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed3/10

   Docs mention that Sandbox usage is metered and that quotas apply per plan, plus region availability and spend management for cost control, but no concrete documented concurrency limits (e.g., max simultaneous sandboxes) are shown in the evidence. missing for 10: explicit concurrency limit numbers, guidance on running large fleets of sandboxes concurrently, and any performance/scale benchmarks.

   • [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
   • [claimed-docs] “Vercel Sandbox is available in the `iad1` (default), `sfo1`, `cle1`, and `cdg1` regions. You can choose the region per sandbox or set a proj…”
   • [claimed-docs] “To control costs, configure Spend Management to receive alerts or pause projects when you reach a specified amount.”

   proof ↗⚑ flag

2. developerKeep a sandbox session running for hours or days for long agent tasks

   weight 2 · round to E2B
   E2B~partialclaimed7/10

   E2B sandboxes can run continuously for hours (up to 24h on Pro plans, with configurable/resettable timeouts via setTimeout), covering the 'hours' part of the story fully, and for multi-day tasks E2B explicitly recommends pause/resume to preserve full memory and filesystem state indefinitely rather than true continuous execution. This satisfies long-running agent tasks but with a documented architectural limitation (base tier capped at 1h, Pro at 24h continuous) requiring the pause/resume workaround for day-scale persistence. Missing for 10: evidence of truly continuous multi-day execution without pause/resume, and independent/hands-on confirmation of stability over such long sessions.

   • [claimed-docs] “Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base). For longer workloads, use pause and resume”
   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”
   • [claimed-docs] “A paused sandbox is kept indefinitely with no automatic deletion.”
   • [claimed-docs] “When you call the set timeout method, the sandbox timeout will be reset to the new value that you specified.”
   • [claimed-docs] “You can change the sandbox timeout when it's running by calling the `setTimeout` method in JavaScript or `set_timeout` method in Python.”
   • [claimed-docs] “Up to 24-hour sandbox session length Up to 100 concurrently running sandboxes”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed6/10

   Docs show sandboxes have a default 5-minute timeout that can be explicitly extended via `timeout` option or `sandbox.extendTimeout()`, and persistent sandboxes auto-snapshot on stop so you can quickly resume a long agent task across sessions rather than losing state. However, there's no evidence of an unbounded or multi-day continuous session—developers must actively manage/extend timeouts or rely on stop/resume snapshotting rather than a single always-on session. missing for 10: documented maximum extendable duration or explicit support for a single continuous multi-hour/day session without developer-managed timeout extensions, independent corroboration of long-running stability.

   • [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
   • [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
   • [claimed-docs] “Persistent sandboxes: Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot m…”
   • [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
   • [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
   • [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”

   proof ↗⚑ flag

Pricing

1. developerStart building with a free tier or included credits without talking to sales

   weight 1 · round to E2B
   E2B✓fullclaimed8/10

   E2B explicitly gives every new account $100 in credits with no sales contact required (e2b-docs-41), and the pricing page details a self-serve tier with concrete limits (24-hour sessions, 100 concurrent sandboxes, e2b-docs-14) alongside quickstart docs showing immediate SDK usage without any account-approval step. missing for 10: no independent/community confirmation of the signup flow or credit amount, and no explicit mention of a free tier distinct from trial credits.

   • [claimed-docs] “Every new E2B account get $100 in credits.”
   • [claimed-docs] “Up to 24-hour sandbox session length Up to 100 concurrently running sandboxes”
   • [claimed-docs] “Customize your Sandbox CPU & RAM”
   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   The evidence pack mentions billing, plans, and quotas (e.g., vercel-sandbox-docs-42, docs-24) but never explicitly states a free tier or included credits usable without contacting sales. Missing for 10: explicit free-tier/plan pricing details, evidence of self-serve signup without sales contact.

   • [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
   • [claimed-docs] “To control costs, configure Spend Management to receive alerts or pause projects when you reach a specified amount.”

   proof ↗⚑ flag

2. platform-engineerPay per second only for the compute a sandbox actually uses

   weight 3 · round drawn
   E2B~partialclaimed4/10

   The pricing page confirms usage-based configuration (customizable CPU/RAM, session-length/concurrency tiers) and the SDK/CLI let you kill a sandbox or reset its timeout at any moment, plus real-time CPU/memory/disk metrics — all consistent with paying only for compute actually consumed. However, no evidence pack item explicitly states a per-second billing granularity or shows a billing/invoice example. Missing for 10: explicit per-second billing rate documentation, an invoice/billing dashboard example, or a stated billing unit (e.g., 'billed per second of sandbox uptime').

   • [claimed-docs] “Customize your Sandbox CPU & RAM”
   • [claimed-docs] “Up to 24-hour sandbox session length Up to 100 concurrently running sandboxes”
   • [claimed-docs] “When you call the set timeout method, the sandbox timeout will be reset to the new value that you specified.”
   • [claimed-docs] “You can shutdown the sandbox any time even before the timeout is up by calling the `kill` method.”
   • [claimed-docs] “The sandbox metrics allows you to get information about the sandbox's CPU, memory and disk usage.”
   • [claimed-docs] “Getting the metrics of a sandbox returns an array of timestamped metrics containing CPU, memory and disk usage information.”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed4/10

   Docs confirm Sandbox usage is metered on a pricing page with configurable timeouts and spend-management alerts to control costs, implying granular, usage-based billing, but no evidence explicitly states billing is charged 'per second' of compute used. missing for 10: explicit per-second billing granularity documentation, real-world billing statement/invoice examples showing sub-minute metering.

   • [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”
   • [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
   • [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
   • [claimed-docs] “To control costs, configure Spend Management to receive alerts or pause projects when you reach a specified amount.”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Vercel Sandbox
   E2B~partialclaimed4/10

   E2B docs mention BYOC and self-hosted deployment options (Terraform-based) which would let an organization control where infrastructure/data physically resides, but there is no evidence of an explicit region/residency selector or documented list of hosting regions for the standard managed service. missing for 10: explicit region-selection UI/API, documented list of available data-residency regions, compliance certifications tied to specific regions.

   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or BYOC or self-hosted deployments — create an `E2B` client and…”
   • [claimed-docs] “If you need an explicit configuration — for example several API keys, teams, or [BYOC or self-hosted deployments](/byoc) in a single process…”
   • [github] “Read the self-hosting guide to learn how to set up the E2B infrastructure on your own. The infrastructure is deployed using Terraform.”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed5/10

   Docs confirm region selection (iad1, sfo1, cle1, cdg1) can be set per sandbox or as a project default, giving users some control over where sandboxes execute, and one changelog note claims availability 'in all regions.' However, there is no explicit data residency/compliance guarantee, no mention of where persistent Drives/snapshots/data-at-rest are stored, and no discussion of data sovereignty controls beyond compute region choice. missing for 10: explicit data-at-rest residency guarantees, compliance/certification details tied to region choice, documentation on storage location for Drives/snapshots, and independent confirmation of region enforcement.

   • [claimed-docs] “Vercel Sandbox is available in the `iad1` (default), `sfo1`, `cle1`, and `cdg1` regions. You can choose the region per sandbox or set a proj…”
   • [claimed-docs] “Vercel Sandbox is now available in all regions”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to E2B
   E2B~partialclaimed6/10

   E2B gives concrete lifecycle controls over sandbox data: sandboxes can be killed/shutdown anytime, timeouts set/reset, and paused sandboxes are 'kept indefinitely with no automatic deletion' until explicitly resumed or removed via CLI shutdown/kill commands, giving users direct control over when sandbox state (filesystem, memory) persists or is destroyed. However, there's no evidence of broader data-retention policy documentation (e.g., logs, telemetry, backups) or explicit deletion/export guarantees at the account or compliance level (GDPR/SOC2-style retention statements). Missing for 10: explicit data-retention/deletion policy documentation beyond sandbox kill/pause mechanics, account-level data deletion guarantees, and compliance/regulatory retention statements.

   • [claimed-docs] “A paused sandbox is kept indefinitely with no automatic deletion.”
   • [claimed-docs] “You can shutdown the sandbox any time even before the timeout is up by calling the `kill` method.”
   • [claimed-docs] “You can change the sandbox timeout when it's running by calling the `setTimeout` method in JavaScript or `set_timeout` method in Python.”
   • [claimed-docs] “You can shutdown single or all running sandboxes with the E2B CLI.”
   • [claimed-docs] “To shutdown all running sandboxes, run the following command:”
   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”

   proof ↗⚑ flag

   Vercel Sandbox—none0/10

   Docs describe sandbox lifecycle (timeouts, stopping, persistence, snapshots) but there is no explicit statement about data retention policies, deletion guarantees, or privacy controls for stored sandbox data/drives. missing for 10: explicit data retention policy, explicit deletion/purge controls, privacy/compliance documentation for stored data.

   • [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
   • [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
   • [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
   • [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   E2B—none0/10

   No evidence pack item mentions telemetry, analytics collection, or an opt-out/opt-in setting for usage tracking; E2B's self-hosting option (e2b-gh-2) implies infrastructure control but does not document any telemetry toggle for the hosted product.

   ⚑ flag

   Vercel Sandbox—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out for Vercel Sandbox; documentation covers execution, isolation, images, and pricing but nothing about telemetry controls.

   ⚑ flag

Lifecycle

1. developerSet timeouts so sandboxes shut down automatically and stop billing when idle or done

   weight 2 · round drawn
   E2B✓fullclaimed8/10

   E2B documents explicit timeout controls (setTimeout/set_timeout), default and configurable session lengths (24h Pro/1h Base), automatic kill on timeout, and manual kill/shutdown via SDK and CLI, directly enabling idle sandboxes to auto-terminate. missing for 10: explicit first-party confirmation that billing stops precisely at timeout/kill (only inferred from lifecycle docs), and independent/hands-on verification of billing behavior.

   • [claimed-docs] “When you call the set timeout method, the sandbox timeout will be reset to the new value that you specified.”
   • [claimed-docs] “You can shutdown the sandbox any time even before the timeout is up by calling the `kill` method.”
   • [claimed-docs] “You can change the sandbox timeout when it's running by calling the `setTimeout` method in JavaScript or `set_timeout` method in Python.”
   • [claimed-docs] “Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base). For longer workloads, use pause and resume”
   • [claimed-docs] “You can shutdown single or all running sandboxes with the E2B CLI.”
   • [claimed-docs] “To shutdown all running sandboxes, run the following command:”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Docs explicitly state sandboxes have a default 5-minute timeout, configurable via the `timeout` option at creation, extendable via `sandbox.extendTimeout()`, and can be manually stopped from the dashboard, directly supporting automatic shutdown to stop billing when idle or done. Missing for 10: independent/hands-on confirmation that billing actually stops immediately upon timeout, and documentation of any maximum timeout limits or edge cases.

   • [claimed-docs] “You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.extendTimeout()`.”
   • [claimed-docs] “The default timeout is 5 minutes. You can configure this using the `timeout` option when creating a sandbox, and extend it using `sandbox.ex…”
   • [claimed-docs] “You can also stop sandboxes from the Vercel Dashboard by navigating to Observability > Sandboxes and clicking Stop Sandbox.”
   • [claimed-docs] “Vercel Sandbox usage is metered across several dimensions. This page explains how billing works for each plan, what quotas apply, and how to…”

   proof ↗⚑ flag

2. developerSpin up an isolated sandbox with one API/SDK call and get a live environment in seconds

   weight 3 · round to E2B
   E2B✓fullclaimed9/10

   Docs clearly show a single SDK call (Sandbox.create()) provisions an isolated sandbox with near-instant readiness, plus templates offering 'zero wait time' startup, CLI equivalents, and evidence of the core create/run/kill/timeout lifecycle. missing for 10: independent hands-on benchmarking of actual boot latency beyond vendor claims.

   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session const execution = await sbx.runCode('print("hello world")')”
   • [claimed-docs] “This gives you fully configured sandboxes with running processes ready to use with zero wait time for your users.”
   • [claimed-docs] “const sbx = await Sandbox.create() // Creates a persistent sandbox session”
   • [claimed-docs] “We’ll write the minimal code for starting Sandbox, executing Python inside it and listing all files inside the root directory.”
   • [claimed-docs] “e2b sandbox create <template>”
   • [github] “E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud.”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Docs show a clear SDK/CLI path (`@vercel/sandbox`, `sandbox create`/`sandbox run`) to spin up isolated Linux microVMs, with fast startup via managed images or snapshots that skip dependency installation, matching the 'one call, live environment in seconds' story. Missing for 10: independent/hands-on timing benchmarks confirming 'seconds' latency and third-party corroboration beyond first-party docs.

   • [claimed-docs] “Run untrusted or agent-generated code in isolated Linux microVMs. Use Vercel Sandbox for agent workflows, debugging, and one-off commands.”
   • [claimed-docs] “Use `@vercel/sandbox` for JavaScript and TypeScript”
   • [claimed-docs] “Use the `sandbox` CLI for manual testing, agentic workflows, debugging, and one-off operations”
   • [claimed-docs] “The Sandbox SDKs are the recommended way to integrate Vercel Sandbox into your applications. They provide a programmatic interface to create…”
   • [claimed-docs] “sandbox run echo "Hello Sandbox!"”
   • [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
   • [claimed-docs] “Start sandboxes from Vercel's Managed Images, a shared or public image, or your own OCI images stored in Vercel Container Registry.”

   proof ↗⚑ flag

Preview access

1. developerExpose a port from the sandbox on a public preview URL to reach services running inside

   weight 2 · round to Vercel Sandbox
   E2B—none0/10

   The evidence pack covers sandbox lifecycle (create, pause/resume, timeouts, files, commands, metrics, CLI) but contains no mention of exposing ports or generating public preview URLs to reach services running inside a sandbox. This is a fair capability question for a sandbox execution platform, so the axis applies, but nothing in the evidence supports it.

   ⚑ flag

   Vercel Sandbox~partialclaimed5/10

   Docs mention running dev servers with 'live previews' and testing agent-generated code with access to 'live previews', implying some port-exposure/public-URL capability, but no evidence pack item describes the actual API/CLI mechanism (e.g., a domain/getUrl method, port argument, or URL format) for exposing a sandboxed port publicly. missing for 10: explicit documentation of the port-exposure API or CLI command, example of the resulting public URL, and confirmation of access control/authentication on that URL.

   • [claimed-docs] “Run development servers: Spin up and test applications with live previews.”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self-contained environment with access to logs, file edit…”
   • [claimed-docs] “Test in isolation: Preview how user-submitted or agent-generated code behaves in a self”

   proof ↗⚑ flag

Snapshots

1. developerPause a running sandbox and resume it later with filesystem and memory state intact

   weight 2 · round drawn
   E2B✓fullclaimed8/10

   E2B's docs explicitly document pausing a sandbox and resuming it later 'from the exact state it was in, including the filesystem and the memory, so running processes and loaded variables survive,' with paused sandboxes kept indefinitely, plus CLI support for snapshot/pause management (e2b sandbox snapshot, list --state paused). This directly matches the story's core claim. missing for 10: independent/hands-on third-party verification of state fidelity after resume, and more detail on any limitations (e.g., GPU/network state, long-running process edge cases) beyond first-party docs.

   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”
   • [claimed-docs] “A paused sandbox is kept indefinitely with no automatic deletion.”
   • [claimed-docs] “Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base). For longer workloads, use pause and resume”
   • [claimed-docs] “You can manage sandbox snapshots with the `e2b sandbox snapshot` (alias `snap`) commands.”
   • [claimed-docs] “This will return running sandboxes, you can specify `--state` to get paused or both.”
   • [claimed-docs] “your agent's code runs in an isolated Firecracker microVM instead of your server, with a real Debian toolchain, pause/resume persistence, an…”

   proof ↗⚑ flag

   Vercel Sandbox✓fullclaimed8/10

   Docs explicitly describe persistent sandboxes that auto-save filesystem state on stop and resume where left off by default, with configuration preserved across sessions, plus explicit snapshotting to skip dependency reinstallation and resuming an existing sandbox by name. This directly matches the pause/resume-with-state story via first-party documentation. Missing for 10: independent hands-on verification that memory/process state (not just filesystem) is preserved across pause/resume, and no third-party corroboration beyond vendor docs.

   • [claimed-docs] “Persistent sandboxes: Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot m…”
   • [claimed-docs] “Snapshotting: Save the state of a running sandbox to resume later. Skip dependency installation on subsequent runs.”
   • [claimed-docs] “Or retrieve an existing sandbox by name (resumes if stopped)”
   • [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
   • [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”
   • [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”

   proof ↗⚑ flag

2. developerSnapshot a sandbox and later restore or fork new sandboxes from that snapshot

   weight 3 · round to E2B
   E2B✓fullclaimed8/10

   E2B explicitly supports pause/resume of a sandbox preserving filesystem and memory, and exposes CLI/SDK snapshot management (`e2b sandbox snapshot`), naming snapshot templates that can be reused to create new sandboxes, effectively enabling fork-like behavior from a saved state. missing for 10: explicit documentation/example of forking multiple independent sandboxes from a single snapshot simultaneously, and independent hands-on verification of restore/fork fidelity beyond vendor docs.

   • [claimed-docs] “Pause a sandbox and resume it later from the exact state it was in, including the filesystem and the memory, so running processes and loaded…”
   • [claimed-docs] “A paused sandbox is kept indefinitely with no automatic deletion.”
   • [claimed-docs] “Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base). For longer workloads, use pause and resume”
   • [claimed-docs] “You can manage sandbox snapshots with the `e2b sandbox snapshot` (alias `snap`) commands.”
   • [claimed-docs] “You can name the snapshot template with the `--name` flag. If a template with that name already exists, it is reused.”

   proof ↗⚑ flag

   Vercel Sandbox~partialclaimed6/10

   Vercel Sandbox docs clearly describe automatic snapshotting of a sandbox's filesystem/state on stop and restoring it on resume, with named sandboxes resumable and snapshots speeding up subsequent runs by skipping setup. However, the evidence only shows resuming the *same* sandbox from its own snapshot, not explicitly forking multiple independent new sandboxes from one saved snapshot. Missing for 10: explicit support/documentation for forking multiple new sandboxes off a single snapshot, and any hands-on/independent confirmation of this fork workflow.

   • [claimed-docs] “Snapshotting: Save the state of a running sandbox to resume later. Skip dependency installation on subsequent runs.”
   • [claimed-docs] “Sandboxes that auto-save state on stop and resume where you left off. Persistence is the default. No manual snapshot management needed.”
   • [claimed-docs] “when a sandbox stops, the SDK automatically snapshots its filesystem, and the sandbox configuration is preserved across sessions, so both ar…”
   • [claimed-docs] “Or retrieve an existing sandbox by name (resumes if stopped)”
   • [claimed-docs] “Using a snapshot is much faster than creating from scratch because it avoids reinstalling dependencies and repeating setup steps.”

   proof ↗⚑ flag