E2B vs Cloudflare Sandboxes

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

   Cloudflare Sandboxes~partialprobed6/10

   A probe confirms Cloudflare's developer docs expose a working llms.txt (HTTP 200) covering the whole docs site including Sandbox, giving agents a structured entry point. However, a probe for the markdown version of the specific Sandbox get-started page returned 404, showing per-page agent-friendly docs aren't uniformly available. Missing for 10: dedicated llms.txt or .md endpoints scoped to the Sandbox product docs, and no community/hands-on confirmation of agents actually consuming it successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
   • [probe] “PROBE docs-md: HTTP 404 at https://developers.cloudflare.com/sandbox/get-started/.md”

   proof ↗⚑ flag

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

   weight 2 · round to E2B
   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

   Cloudflare Sandboxes~partialcommunity6/10

   Cloudflare Sandboxes are SDK/Workers-driven (exec, code execution, git operations, bindings access) which is inherently headless/programmatic and well-suited to CI/CD automation, and docs explicitly mention CI/CD as a target use case. However there's no dedicated CLI, no CI integration examples (GitHub Actions, etc.), and no evidence of auto-cleanup/idle-timeout controls needed for reliable CI runs — community notes explicitly flag the lack of auto-destroy on idle, requiring manual cleanup logic. missing for 10: explicit CI/CD pipeline examples or integrations, a standalone CLI for headless invocation, documented idle-timeout/auto-teardown controls, and independent verification of headless automation at scale.

   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
   • [claimed-docs] “Access KV, R2, Durable Objects, and other bindings from a sandbox.”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes—none0/10

   Cloudflare Sandboxes is an execution/infrastructure SDK (not itself an agent), so an official MCP server for agent connectivity is a fair axis to ask about—but the evidence pack contains no mention of MCP, an MCP server, or any protocol for connecting AI agents beyond raw SDK APIs (exec, files, sessions, tunnels, etc.).

   ⚑ 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

   Cloudflare Sandboxes—none0/10

   The evidence pack shows the Sandbox SDK is an API/library used from Workers code (exec, files, sessions, etc.) but nowhere mentions an official CLI tool for AI-native workflows; interaction is entirely via SDK calls or the general Wrangler CLI, not a dedicated Sandbox CLI.

   ⚑ flag

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

   weight 3 · round drawn
   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

   Cloudflare Sandboxes✓fullprobed8/10

   Cloudflare publishes extensive, structured API documentation for the Sandbox SDK (exec, file I/O, sessions, code interpreter, ports/tunnels, watch, snapshots, git, Docker, bindings) explicitly marketed for building AI agents that execute code (docs-24, docs-34). The docs are machine-readable (llms.txt, openapi.json probes return 200) and cover the full surface an AI-native developer would need to drive. missing for 10: independent hands-on confirmation that agents successfully integrate via this API in production, and a dedicated REST/OpenAPI spec for the sandbox endpoints themselves (only the SDK is documented, not a standalone HTTP API schema).

   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
   • [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
   • [claimed-docs] “Execute Python, JavaScript, and TypeScript code with support for data visualizations, tables, and rich output formats.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.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

   Cloudflare Sandboxes—none0/10

   The evidence pack documents sandbox execution, filesystem, networking, and session features but contains no mention of scoped or least-privilege API credential/token issuance for agents accessing the sandbox APIs; in fact, community feedback notes egress control is 'all or nothing' rather than fine-grained, suggesting limited scoping capability overall.

   • [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   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

   Cloudflare Sandboxes✓fullclaimed8/10

   Cloudflare publishes an extensive official SDK (TypeScript/JavaScript) with detailed docs covering exec, file I/O, sessions, code interpreter for Python/JS, port exposure, snapshots, and bindings, explicitly positioned for building AI agents that execute code. Community commentary discusses pricing/latency but does not dispute the SDK's functionality or documentation quality. Missing for 10: independent hands-on developer reviews of the SDK's ergonomics/reliability, and confirmation of multi-language SDK parity beyond JS/TS/Python.

   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Execute Python and JavaScript code with rich outputs including charts, tables, and formatted data.”
   • [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [claimed-docs] “Execute Python, JavaScript, and TypeScript code with support for data visualizations, tables, and rich output formats.”
   • [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”

   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

   Cloudflare Sandboxes—none0/10

   No evidence anywhere in the pack of a webhook subscription mechanism for sandbox events; the SDK exposes file watching, SSE streams, and callback-based output but nothing about registering external webhook endpoints for event notifications.

   ⚑ flag

Agentic features

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

   weight 2 · round to Cloudflare Sandboxes
   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

   Cloudflare Sandboxes~partialcommunity6/10

   Docs show sandboxes can run background processes, maintain persistent sessions/state, and reconnect via stable IDs (docs-43, docs-9, docs-37, docs-32), which supports basic autonomous background execution. However, there's no documented native scheduling/trigger mechanism for kicking off automations, and community feedback notes the lack of auto-idle cleanup means developers must manually manage sandbox lifecycle rather than it running fully autonomously (comm-7). Missing for 10: built-in cron/trigger scheduling, evidence of true unattended long-running automation, and confirmation that background processes persist reliably without manual intervention.

   • [claimed-docs] “Execute commands and manage background processes in the sandbox's isolated container environment.”
   • [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
   • [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
   • [claimed-docs] “const buildSession = await sandbox.createSession({ id: "build", env: { NODE_ENV: "production" }, cwd: "/build" });”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes—none0/10

   Cloudflare Sandboxes is a programmatic SDK (sandbox.exec(), writeFile(), createSession(), etc.) intended to be called from Worker code, not a product with a natural-language command interface; while it markets itself for building AI agents (docs-24), there is no evidence of a chat/NL layer for operating the sandbox itself. missing for 10: any NL command parsing/interface, evidence of a conversational control layer, examples of natural-language-driven sandbox operations.

   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [claimed-docs] “Execute commands and manage background processes in the sandbox's isolated container environment.”

   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

   Cloudflare Sandboxes—none0/10

   The evidence pack shows extensive static code snippets across Cloudflare's Sandbox docs (exec, file I/O, sessions, interpreter, etc.) but nothing indicates an interactive, in-browser 'try it now' API reference or runnable playground — the openapi.json probe is for Cloudflare's general API, not a Sandbox-specific interactive explorer. Missing for 10: an in-page runnable code sandbox/playground, an interactive API explorer (e.g., Swagger/Redoc try-it-out), or any embedded live execution environment tied to the docs.

   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “import pandas as pd data = {'product': ['A', 'B', 'C'], 'sales': [100, 200, 150]} df = pd.DataFrame(data) df['sales'].sum() # Last expressi…”
   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE docs-md: HTTP 404 at https://developers.cloudflare.com/sandbox/get-started/.md”

   proof ↗⚑ flag

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

   weight 2 · round to Cloudflare Sandboxes
   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

   Cloudflare Sandboxes~partialprobed4/10

   Cloudflare's developer platform exposes a general openapi.json (HTTP 200, containing an 'openapi' key), but there's no evidence this spec specifically documents the Sandbox SDK's methods (exec, writeFile, sessions, etc.), which is a code-level SDK rather than a REST API; a dedicated machine-readable doc for the sandbox pages itself returned 404. Missing for 10: confirmation that the openapi.json actually covers Sandbox-specific endpoints/methods, and a dedicated llms.txt/OpenAPI export scoped to the Sandbox SDK docs.

   • [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE docs-md: HTTP 404 at https://developers.cloudflare.com/sandbox/get-started/.md”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”

   proof ↗⚑ flag

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

   weight 1 · round to E2B
   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

   Cloudflare Sandboxes✓fullcommunity7/10

   Cloudflare Sandboxes are explicitly designed as isolated VM/container environments for running untrusted code, separate from production infra, with sessions, snapshots, and opt-in bindings to access KV/R2/Durable Objects only when explicitly wired in — matching the AI-native 'test without touching production' need well (docs-34, docs-38, docs-50, docs-20, docs-24). Community feedback doesn't contradict the isolation guarantee itself, though it flags coarse outbound network controls and unclear persistence semantics as caveats (cloudflare-sandbox-comm-2, cloudflare-sandbox-comm-4). Missing for 10: independent hands-on validation that no production data leakage occurs in practice, and finer-grained egress/network isolation controls.

   • [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
   • [claimed-docs] “Access KV, R2, Durable Objects, and other bindings from a sandbox.”
   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
   • [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”

   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

   Cloudflare Sandboxes—none0/10

   The evidence pack contains extensive API documentation for the Sandbox SDK's features (exec, files, sessions, snapshots, etc.) but nowhere mentions API versioning schemes, version numbers, or a documented deprecation policy for the SDK/API surface. No evidence of semver commitments, changelogs with deprecation notices, or migration guides for breaking changes.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Cloudflare Sandboxes~partialcommunity5/10

   Cloudflare Sandboxes supports concurrent/parallel operations via a multiplexed connection that 'avoids subrequest limits when making many concurrent operations' (docs-17) and allows multiple isolated sessions per sandbox for parallel workflows (docs-9, docs-18, docs-39), plus getSandbox() to manage many sandbox instances by ID. However there's no documented batch/bulk API primitive for iterating over large item sets, and community feedback flags unclear resource limits and high per-vCPU pricing that would constrain large-scale bulk workloads (comm-3, comm-6, comm-11). Missing for 10: an explicit bulk/batch operation API or example, documented concurrency/resource ceilings, and independent evidence of successful large-scale parallel execution.

   • [claimed-docs] “Multiplexes all SDK calls over a single persistent connection. It avoids subrequest limits when making many concurrent operations.”
   • [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
   • [claimed-docs] “Create additional sessions for separate workflows in the same sandbox”
   • [claimed-docs] “Create additional sessions for separate workflows in the same sandbox:”
   • [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
   • [community] “Cloudflare Containers (and therefore Sandbox) pricing is way too expensive... vCPU: $51.84 per vCPU (!!!)... These prices are more expensive…”
   • [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”
   • [community] “I am keen to understand how I would limit sandbox resource usage.”

   proof ↗⚑ flag

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

   weight 3 · round to Cloudflare Sandboxes
   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

   Cloudflare Sandboxes~partialclaimed4/10

   The SDK provides a file-system watch capability with an `onEvent` callback (inotify-based) that lets developers trigger custom actions when files change, which is a form of event-driven automation, but this is a narrow, code-level primitive rather than a declarative rules/automation engine. Missing for 10: no declarative rule-definition mechanism, no support for triggering on non-filesystem events (e.g., scheduled/cron, external webhooks, custom event types), and no evidence of a rules/condition-action system beyond raw watcher callbacks.

   • [claimed-docs] “Monitor real-time filesystem changes using native inotify. Build development tools, hot-reload systems, and responsive file processing.”
   • [claimed-docs] “const watcher = await sandbox.watch('/workspace/src', { include: ['*.js', '*.ts'],”
   • [claimed-docs] “const watcher = await sandbox.watch('/workspace/src', { include: ['*.js', '*.ts'], onEvent: (event) => {”

   proof ↗⚑ 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

   Cloudflare Sandboxes—none0/10

   The evidence describes on-demand sandbox execution, sessions, and lifecycle management, but nowhere mentions cron-style scheduling, recurring triggers, or workflow orchestration for repeated runs; community threads even highlight the lack of automatic idle/cleanup logic, implying no built-in scheduling primitives.

   • [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
   • [claimed-docs] “Create additional sessions for separate workflows in the same sandbox”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes—none0/10

   The docs describe Sandboxes as ideal for building AI agents and provide generic exec/git/docker primitives, but there is no vendor-published recipe or guide specifically for running Claude Code or Codex inside a Sandbox. missing for 10: an explicit vendor tutorial/recipe naming Claude Code or Codex, any first-party integration guide, and community confirmation that such agents run inside the sandbox.

   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [claimed-docs] “Run Docker commands inside a sandbox container.”
   • [claimed-docs] “Clone repositories, manage branches, and automate Git 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

   Cloudflare Sandboxes—none0/10

   The evidence pack details shell execution, file I/O, sessions, tunnels, snapshots, and code interpretation, but nowhere mentions running a headless browser (e.g., Playwright/Puppeteer) or a full desktop/GUI environment inside the sandbox. This is a reasonable capability to ask of a code-execution sandbox product, but no docs or community evidence confirm it exists.

   ⚑ 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

   Cloudflare Sandboxes—none0/10

   No evidence anywhere in the docs or community discussion mentions GPU support, GPU attachment, or GPU-accelerated workloads for Cloudflare Sandboxes; the product is described purely in terms of CPU-based containers/VMs for code execution.

   ⚑ flag

Files

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

   weight 2 · round to Cloudflare Sandboxes
   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

   Cloudflare Sandboxes✓fullclaimed9/10

   Docs explicitly cover readFile/writeFile/mkdir with absolute paths, streaming/binary uploads >32MiB via ReadableStream, and directory watching, giving comprehensive first-party coverage of file read/write/upload/download via the SDK. Missing for 10: independent hands-on developer confirmation of file upload/download behavior (community discussion focuses on persistence questions, not concrete failures).

   • [claimed-docs] “await sandbox.writeFile("/workspace/hello.txt", "Hello, Sandbox!"); const file = await sandbox.readFile("/workspace/hello.txt");”
   • [claimed-docs] “This allows binary data and files greater than 32 MiB to be written to the sandbox. It replaces the "base64" encoding option.”
   • [claimed-docs] “the writeFile() method supports passing a ReadableStream as the content parameter. This allows binary data and files greater than 32 MiB”
   • [claimed-docs] “Read, write, and manage files in the sandbox filesystem. All paths are absolute (e.g., `/workspace/app.js`).”
   • [claimed-docs] “the `writeFile()` method supports passing a `ReadableStream` as the `content` parameter.”
   • [claimed-docs] “await sandbox.mkdir('/workspace/project/src', { recursive: true });”

   proof ↗⚑ flag

Runtimes

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

   weight 2 · round to E2B
   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

   Cloudflare Sandboxes—none0/10

   The evidence describes running commands, files, sessions, Python/JS execution, tunnels, and Docker-command execution inside a sandbox, but nothing documents defining a custom sandbox template or supplying a custom base container image for the sandbox environment itself. Since bring-your-own-image is a standard, expected axis for a container/sandbox product, the lack of any supporting evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Run Docker commands inside a sandbox container.”
   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Cloudflare Sandboxes✓fullclaimed8/10

   Docs clearly document a code interpreter API executing Python, JavaScript, and TypeScript with rich outputs (charts, tables, dataframes, stateful contexts), plus shell exec with stdout/stderr capture, matching the story directly. Missing for 10: independent/hands-on verification of the rich-output rendering quality and broader language support beyond the three named runtimes.

   • [claimed-docs] “Execute Python and JavaScript code with rich outputs including charts, tables, and formatted data.”
   • [claimed-docs] “Execute Python, JavaScript, and TypeScript code with support for data visualizations, tables, and rich output formats.”
   • [claimed-docs] “import pandas as pd data = {'product': ['A', 'B', 'C'], 'sales': [100, 200, 150]} df = pd.DataFrame(data) df['sales'].sum() # Last expressi…”
   • [claimed-docs] “Contexts maintain state (variables, imports, functions) across executions.”
   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “you'll create a Worker that can execute Python code and work with files in isolated containers.”

   proof ↗⚑ flag

Untrusted code

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

   weight 3 · round to E2B
   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

   Cloudflare Sandboxes~partialcommunity7/10

   Cloudflare's docs explicitly market Sandboxes for running untrusted, AI-generated code with VM/container-based isolation, file/exec APIs, and strong security boundaries (cloudflare-sandbox-docs-34, -38, -50, -24). However, hands-on community feedback flags real gaps for this exact use case: outbound network access is 'all or nothing' with no fine-grained egress control, and there's no built-in auto-destroy for idle sandboxes, forcing manual cleanup. Missing for 10: granular network egress control, automatic idle sandbox teardown, independent security audit of the VM isolation claims.

   • [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
   • [claimed-docs] “Sandboxes are ideal for building AI agents that need to execute code, interactive development environments, data analysis platforms, CI/CD s…”
   • [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Cloudflare Sandboxes✓fullclaimed9/10

   Docs explicitly document sandbox.exec() for running arbitrary shell commands with stdout/stderr/exit codes, stdin support, streaming/SSE output, background processes, plus Docker command execution and Git operations inside the sandbox, giving developers full shell/package-install capability. Community threads corroborate real-world usage of the sandbox for running containerized workloads, though none specifically contradict shell/package execution. missing for 10: independent hands-on verification of installing arbitrary packages (e.g., apt/pip) beyond docs examples.

   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Pass input via stdin (no shell injection risks)”
   • [claimed-docs] “Execute a command and return a Server-Sent Events stream for real-time processing.”
   • [claimed-docs] “Run Docker commands inside a sandbox container.”
   • [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
   • [claimed-docs] “stdin - Data to pass to the command's standard input (enables arbitrary input without shell injection risks)”
   • [claimed-docs] “onOutput - Callback for real-time output: (stream: 'stdout' | 'stderr', data: string) => void”
   • [claimed-docs] “Execute commands and manage background processes in the sandbox's isolated container environment.”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”

   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

   Cloudflare Sandboxes~partialcommunity7/10

   Docs clearly show an agent-driven lifecycle: getSandbox() to provision/reconnect, exec()/interpreter code execution with stdout/stderr capture, and readFile to retrieve results — all callable programmatically without a human in the loop. However, there is no documented explicit 'destroy/teardown' API, and community feedback confirms there's no built-in idle-timeout auto-destroy, forcing developers to implement their own cleanup logic. Missing for 10: a documented sandbox.destroy()/terminate call or auto-expiry mechanism, and independent hands-on confirmation of a full provision-execute-teardown loop working end-to-end.

   • [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Execute Python and JavaScript code with rich outputs including charts, tables, and formatted data.”
   • [claimed-docs] “await sandbox.writeFile("/workspace/hello.txt", "Hello, Sandbox!"); const file = await sandbox.readFile("/workspace/hello.txt");”
   • [claimed-docs] “Contexts maintain state (variables, imports, functions) across executions.”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes✓fullcommunity7/10

   Cloudflare's own docs explicitly state 'VM-based isolation - Each sandbox runs in its own VM' and that each sandbox 'runs in its own isolated container with a full Linux environment, providing strong security boundaries' for running untrusted code (docs-38, docs-50, docs-34). This gives a documented isolation boundary, though the docs mix 'VM' and 'container' language rather than naming a specific microVM technology, and community discussion raises open questions about network egress granularity rather than disputing the isolation claim itself. Missing for 10: a clearer, consistent technical description of the isolation mechanism (e.g., naming Firecracker or similar) and independent third-party security audit/corroboration.

   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
   • [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
   • [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”

   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 E2B
   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

   Cloudflare Sandboxes~partialcommunity6/10

   Cloudflare documents strong process/VM isolation ('VM-based isolation', 'isolated container with a full Linux environment', 'run untrusted code securely in isolated environments') which implies the host's runtime and secrets aren't directly reachable by sandboxed code, and bindings (KV/R2/DO) are explicitly scoped and passed in rather than ambient. However, there is no explicit documentation describing how host secrets/credentials are excluded or scrubbed from the sandbox environment, and community feedback notes only coarse-grained outbound network control ('all or nothing') rather than fine-grained secret/credential access restrictions, leaving open questions about exfiltration vectors. Missing for 10: explicit documentation on secret/credential isolation guarantees, independent security audit or hands-on test confirming host credentials are unreachable, and finer-grained egress/network controls to prevent secret exfiltration.

   • [claimed-docs] “The Sandbox SDK enables you to run untrusted code securely in isolated environments.”
   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
   • [claimed-docs] “Access KV, R2, Durable Objects, and other bindings from a sandbox.”
   • [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”

   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

   Cloudflare Sandboxes!disputedcontradicted3/10

   Docs mention only a mechanism to 'Intercept and handle outbound HTTP from sandboxes using Workers' (docs-23), which is not the same as a declarative allow/deny egress policy, and no docs describe configurable network egress rules. A named community commenter explicitly states outbound network control is 'all or nothing right now' with no fine-grained control available, directly contradicting the story's requirement for explicit egress policy. missing for 10: documented egress allow/deny policy API, first-party confirmation of granular network restriction, and any independent verification that such a policy exists.

   • [claimed-docs] “Intercept and handle outbound HTTP from sandboxes using Workers.”
   • [community] “Looks like there's one feature missing from this that I care about: I'd like more finely grained control over what outbound internet connect…”

   proof ↗⚑ flag

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

   weight 2 · round to Cloudflare Sandboxes
   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

   Cloudflare Sandboxes✓fullcommunity7/10

   Cloudflare Sandboxes is an API/SDK-first product with no separate management UI described in the evidence; every capability (exec, file I/O, sessions, git, Docker, port exposure, snapshots, code interpreter, filesystem watch, even the browser terminal) is exposed and built entirely through the SDK/API, and the terminal UI itself is just a WebSocket client wired to the same API. Missing for 10: no explicit statement contrasting a Cloudflare dashboard GUI with the API, and no independent/third-party confirmation that no UI-exclusive controls exist (e.g., resource limits raised as unclear in community threads).

   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [claimed-docs] “Connect browser-based terminal UIs to sandbox shells via WebSocket, with the xterm.js SandboxAddon for automatic reconnection and resize han…”
   • [claimed-docs] “Run Docker commands inside a sandbox container.”
   • [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
   • [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
   • [community] “I am keen to understand how I would limit sandbox resource usage.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Cloudflare Sandboxes~partialclaimed4/10

   The SDK exposes standard file I/O (readFile/writeFile), S3-compatible bucket mounting (R2/S3/GCS), and snapshot/restore to R2, which are open, non-proprietary formats a user could use to extract their data. However, there is no documented bulk 'export all my data' feature, no account-level portability tooling, and no independent confirmation that a user can fully migrate off the platform with all state intact. missing for 10: explicit data-export/account-portability feature, independent verification of full data extraction, documentation on non-file state (e.g., session/process state) portability.

   • [claimed-docs] “await sandbox.writeFile("/workspace/hello.txt", "Hello, Sandbox!"); const file = await sandbox.readFile("/workspace/hello.txt");”
   • [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”
   • [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
   • [claimed-docs] “Read, write, and manage files in the sandbox filesystem. All paths are absolute (e.g., `/workspace/app.js`).”
   • [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”

   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

   Cloudflare Sandboxes—none0/10

   No evidence in the pack mentions an open-source license or a public source repository for the Cloudflare Sandbox SDK; all citations are product docs, pricing/feature discussions, or probes, none addressing source availability or licensing.

   ⚑ 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

   Cloudflare Sandboxes—none0/10

   Cloudflare Sandboxes is built entirely on Cloudflare's proprietary Workers/Durable Objects/container infrastructure, and no evidence in the pack mentions any open-source release, self-hosted deployment option, or ability to run the core product outside Cloudflare's platform. Community discussion focuses on pricing, cold-start times, and resource limits, not self-hosting.

   • [claimed-docs] “The SDK supports three transport protocols for communication between the Durable Object and container”
   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”

   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

   Cloudflare Sandboxes—none0/10

   No first-party Cloudflare documentation in the evidence pack states specific cold-start timing (sub-second to few-second) for sandboxes; the community threads discuss competitors' or ambiguous Firecracker boot times without confirming Cloudflare's own documented cold-start figures. missing for 10: official docs quantifying cold-start latency, benchmark data, or a first-party performance page addressing startup time.

   • [community] “We rolled out our own that does pretty much the same thing but perhaps more... It does take 1-5 seconds to boot the environment (firecracker…”
   • [community] “1-5 seconds seems high for Firecracker, depending on your requirements. We boot VMs (using Firecracker) at ~20-50ms.”

   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

   Cloudflare Sandboxes—none0/10

   Docs describe per-sandbox features (sessions, exec, files) and one architectural note that multiplexing avoids subrequest limits, but there is no documentation of concurrency limits, fleet-level scaling guidance, or how many sandboxes/instances can run concurrently. Community comments explicitly flag unanswered questions about resource limits and lack of auto-cleanup, reinforcing the absence of concrete concurrency documentation.

   • [claimed-docs] “Multiplexes all SDK calls over a single persistent connection. It avoids subrequest limits when making many concurrent operations.”
   • [community] “I am keen to understand how I would limit sandbox resource usage.”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes!disputedcontradicted5/10

   Docs describe stable-ID reconnection (getSandbox) and sessions with persistent state/env, suggesting sandboxes could be resumed across long tasks, but community reports explicitly say containers auto-shutdown after idle periods, that there's no built-in idle-timeout control (forcing manual cleanup), and that persistence semantics during idle states are unclear — directly undercutting reliable multi-hour/day continuous operation for unattended agent tasks. Missing for 10: first-party guidance on running sessions continuously for hours/days without disconnection, clear idle-timeout/keep-alive controls, and independent confirmation of long-duration reliability.

   • [claimed-docs] “Create isolated execution contexts within a sandbox. Each session maintains its own shell state, environment variables, and working director…”
   • [claimed-docs] “Create additional sessions for separate workflows in the same sandbox”
   • [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
   • [claimed-docs] “You can also set a default command timeout for all commands in a session”
   • [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
   • [community] “Cloudflares docs are written so hard for web dev. Can you host a monolith app that isn't serving http traffic on cloudflare tech like contai…”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes—none0/10

   The evidence pack documents extensive product capabilities and self-serve pricing figures (e.g., per-vCPU costs debated in community threads) but contains no mention of a free tier, free trial credits, or explicit self-serve signup flow that lets a developer start without contacting sales. missing for 10: explicit free-tier/credit offer, signup flow documentation, confirmation no sales contact is required.

   • [community] “Cloudflare Containers (and therefore Sandbox) pricing is way too expensive... vCPU: $51.84 per vCPU (!!!)... These prices are more expensive…”
   • [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”

   proof ↗⚑ flag

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

   weight 3 · round to E2B
   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

   Cloudflare Sandboxes—none0/10

   No documentation in the evidence pack describes per-second or usage-based billing for sandbox compute; the only pricing-related evidence is community commentary describing flat, expensive per-vCPU pricing (comm-3, comm-6) and the absence of automatic idle shutdown, meaning engineers must build their own cleanup to avoid being billed for idle sandboxes (comm-7). This contradicts rather than supports the story of paying only for actual per-second compute use.

   • [community] “Cloudflare Containers (and therefore Sandbox) pricing is way too expensive... vCPU: $51.84 per vCPU (!!!)... These prices are more expensive…”
   • [community] “The pricing with such offerings is the biggest throwoff. This one comes out to be more than $58/month for just 1vCpu and 1GiB RAM when used …”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   proof ↗⚑ flag

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

   weight 2 · round to E2B
   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

   Cloudflare Sandboxes—none0/10

   No evidence in the pack discusses data residency, region selection, or storage location controls for Cloudflare Sandboxes; docs focus on execution, files, sessions, tunnels, and R2 snapshots without any region/residency configuration options mentioned.

   ⚑ 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

   Cloudflare Sandboxes—none0/10

   The docs describe file read/write, snapshot/restore to R2, and bucket mounting, but there is no documented mechanism for users to control data retention windows or guarantee deletion of sandbox data. Community evidence explicitly states 'it does not seem to be possible to auto destroy a sandbox after certain amount of idle time... forces whoever is implementing this to do their own cleanup,' and persistence semantics are described as unclear, indicating the product does not provide the retention/deletion controls an AI-native user would need.

   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”
   • [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”
   • [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
   • [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”

   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

   Cloudflare Sandboxes—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or opt-out settings for Cloudflare Sandboxes; docs focus purely on execution, filesystem, sessions, and networking features. This is a fair privacy-posture question for a developer platform product, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

Lifecycle

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

   weight 2 · round to E2B
   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

   Cloudflare Sandboxes!disputedcontradicted3/10

   Docs only describe a per-command timeout within sessions (cloudflare-sandbox-docs-19), not an idle-shutdown/auto-destroy mechanism for the whole sandbox tied to billing; one community comment claims the underlying Container platform auto-shuts down after no requests (cloudflare-sandbox-comm-5), but a hands-on developer explicitly states it does not seem possible to auto-destroy a sandbox after an idle period, forcing manual cleanup (cloudflare-sandbox-comm-7). This is a direct contradiction between vendor-adjacent claims and hands-on experience. Missing for 10: explicit first-party docs on idle-timeout auto-shutdown/destroy tied to billing, and independent confirmation it works as described.

   • [claimed-docs] “You can also set a default command timeout for all commands in a session”
   • [community] “Cloudflares docs are written so hard for web dev. Can you host a monolith app that isn't serving http traffic on cloudflare tech like contai…”
   • [community] “I browsed through the documents but it does not seem to be possible to auto destroy a sandbox after certain amount of idle time. This forces…”

   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

   Cloudflare Sandboxes✓fullcommunity8/10

   Docs show a single call (getSandbox()) creates or reconnects to an isolated VM/container sandbox with immediate access to exec, file, and session APIs (docs-37, docs-38, docs-50), and community discussion corroborates boot times in the 1-5 second range consistent with 'seconds' provisioning (comm-1, comm-8). Missing for 10: an independent benchmark or first-party latency SLA confirming consistent sub-few-second cold starts across load, since community notes it's slower than some Firecracker-based competitors.

   • [claimed-docs] “getSandbox() - Gets or creates a sandbox instance by ID. Use a stable ID to reconnect to the same sandbox.”
   • [claimed-docs] “VM-based isolation - Each sandbox runs in its own VM”
   • [claimed-docs] “Each sandbox runs in its own isolated container with a full Linux environment, providing strong security boundaries while maintaining perfor…”
   • [claimed-docs] “sandbox.exec() - Execute shell commands in the sandbox and capture stdout, stderr, and exit codes.”
   • [community] “We rolled out our own that does pretty much the same thing but perhaps more... It does take 1-5 seconds to boot the environment (firecracker…”
   • [community] “1-5 seconds seems high for Firecracker, depending on your requirements. We boot VMs (using Firecracker) at ~20-50ms.”

   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 Cloudflare Sandboxes
   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

   Cloudflare Sandboxes✓fullclaimed9/10

   Docs explicitly describe exposing a sandbox port and getting a public preview URL, including zero-config *.trycloudflare.com URLs via sandbox.tunnels.get(port) and Worker-side routing of HTTP/WebSocket requests to the correct sandbox container, directly matching the story. Missing for 10: independent/hands-on confirmation of preview URL reliability beyond first-party docs.

   • [claimed-docs] “Expose services running in the sandbox via preview URLs. Access web servers and APIs from the internet.”
   • [claimed-docs] “Expose services on zero-config `*.trycloudflare.com` URLs via `sandbox.tunnels.get(port)`. Best for quick development and `.workers.dev` dep…”
   • [claimed-docs] “Expose a port and get a preview URL for accessing services running in the sandbox.”
   • [claimed-docs] “Expose services on zero-config `*.trycloudflare.com` URLs via `sandbox.tunnels.get(port)`.”
   • [claimed-docs] “Expose services running in your sandbox via public preview URLs.”
   • [claimed-docs] “Route incoming HTTP and WebSocket requests to the correct sandbox container.”

   proof ↗⚑ flag

Snapshots

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

   weight 2 · round to E2B
   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

   Cloudflare Sandboxes~partialcommunity5/10

   Docs confirm directory-level snapshot/restore to R2 ('Create point-in-time snapshots of directories and restore them from R2') and idle-state persistence claims, giving filesystem-level pause/resume support, but there's no documented mechanism for preserving in-memory/process execution state across a pause, and community discussion notes ambiguity about exactly how idle-state persistence works. missing for 10: explicit memory/process-state preservation on pause, clear docs on what 'idle state' persistence actually preserves, independent verification that restored sandboxes resume mid-execution rather than just filesystem contents.

   • [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
   • [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
   • [claimed-docs] “Mount S3-compatible buckets (R2, S3, GCS) as local filesystems for persistent data storage across sandbox lifecycles.”
   • [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”

   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

   Cloudflare Sandboxes~partialcommunity5/10

   Docs confirm directory-level snapshot/restore via R2 (docs-8, docs-48), but there's no evidence of forking new independent sandbox instances from a snapshot — only restoring a directory's state, and community reports flag ambiguity in how persistence/restore actually behaves (comm-4). missing for 10: explicit 'fork sandbox from snapshot' API, clarity on full sandbox-state (not just directory) restoration, and independent confirmation that restore reliably recreates a working sandbox.

   • [claimed-docs] “Create point-in-time snapshots of directories and restore them from R2.”
   • [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
   • [community] “There is an open question about how file persistence works. The docs claim they persist the filesystem even when they move the container to …”

   proof ↗⚑ flag