Cloudflare Sandboxes vs Blaxel

Agent access

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

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

   Blaxel✓fullprobed9/10

   A probe directly confirms llms.txt is live and returns HTTP 200 with a structured documentation summary at docs.blaxel.ai/llms.txt, and Blaxel also ships agent-oriented skills/MCP docs for agents to consume. Missing for 10: no independent third-party confirmation that agents actually consume/parse this llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.blaxel.ai/llms.txt # Documentation > Blaxel documentation: cloud sandboxes, AI agent hosting, MCP …”
   • [claimed-docs] “Install the Blaxel skill to give your agent the ability to deploy AI agents, create sandboxes for code execution, host MCP servers, run batc…”
   • [claimed-docs] “The open source Blaxel migration skill gives agents the knowledge they need to migrate sandbox code from other providers to Blaxel.”

   proof ↗⚑ flag

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

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

   Blaxel✓fullprobed8/10

   Blaxel documents an official CLI/SDK, API keys for CLI/SDK/API use, and a dedicated GitHub Action for CI pipeline integration, plus serverless jobs and headless sandbox operations suited to automation. Missing for 10: independent/hands-on confirmation of CI usage and more detail on non-interactive scripting workflows beyond the GitHub Action doc.

   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”
   • [claimed-docs] “The easiest way to integrate the Blaxel CLI into a CI pipeline is with the official Blaxel GitHub Action.”
   • [claimed-docs] “Blaxel employs two main authentication paradigms: **short-lived tokens** (OAuth) and **long-lived tokens** (API keys).”
   • [claimed-docs] “Jobs allow you to run many AI tasks in parallel using batch processing.”
   • [claimed-docs] “Run batch processing tasks for AI workflows on Blaxel as scheduled or on-demand jobs that scale automatically and run on serverless infrastr…”
   • [probe] “official CLI documented at https://docs.blaxel.ai/cli-reference/introduction”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Blaxel
   Cloudflare Sandboxes—none0/10

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

   ⚑ flag

   Blaxel~partialprobed5/10

   Blaxel's docs confirm it can host and serve MCP servers (its own sandboxes expose MCP endpoints, and it offers 'MCP Server Hosting' for remote MCP servers) and its agent-building SDK implies agents can call MCP tools, but there is no explicit documentation showing a user configuring an agent to consume arbitrary third-party/external MCP servers as a client. Missing for 10: explicit client-side MCP server registration/config docs, and independent confirmation of consuming non-Blaxel MCP servers.

   • [claimed-docs] “Install the Blaxel skill to give your agent the ability to deploy AI agents, create sandboxes for code execution, host MCP servers, run batc…”
   • [claimed-docs] “Every sandbox is exposed via an MCP server that allows agents to operate it using tool calls.”
   • [claimed-docs] “MCP Server Hosting is a serverless computing service that allows you to host remote MCP servers without having to manage infrastructure.”
   • [claimed-docs] “MCP Server Hosting is a **serverless computing service that allows you to host remote MCP servers** without having to manage infrastructure.”
   • [claimed-docs] “Every Blaxel sandbox exposes a built-in MCP server so agents can operate the sandbox using tool calls for files, processes, ports, and previ…”
   • [probe] “official MCP server documented at https://docs.blaxel.ai/skills-mcp”

   proof ↗⚑ flag

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

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

   Blaxel✓fullprobed8/10

   Blaxel is an infrastructure/agent-hosting platform (not itself an agent), so the MCP-server axis clearly applies, and Blaxel explicitly ships MCP Server Hosting as a serverless remote MCP hosting service and exposes every sandbox via a built-in MCP server for tool-call operation, with dedicated docs and a skills-mcp reference. Missing for 10: independent/hands-on third-party confirmation beyond first-party docs, and no live API schema/probe validation (openapi probe 404s).

   • [claimed-docs] “Every sandbox is exposed via an MCP server that allows agents to operate it using tool calls.”
   • [claimed-docs] “Every Blaxel sandbox exposes a built-in MCP server so agents can operate the sandbox using tool calls for files, processes, ports, and previ…”
   • [claimed-docs] “MCP Server Hosting is a serverless computing service that allows you to host remote MCP servers without having to manage infrastructure.”
   • [claimed-docs] “MCP Server Hosting is a **serverless computing service that allows you to host remote MCP servers** without having to manage infrastructure.”
   • [claimed-docs] “The open source Blaxel migration skill gives agents the knowledge they need to migrate sandbox code from other providers to Blaxel.”
   • [probe] “official MCP server documented at https://docs.blaxel.ai/skills-mcp”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Blaxel✓fullprobed7/10

   Blaxel has an official CLI documented at a dedicated CLI reference, integrable into CI via a GitHub Action, and used for API key auth alongside SDK/API — consistent with AI-native, agentic workflows (deploying agents, sandboxes, MCP servers, jobs). Missing for 10: no independent/hands-on corroboration of CLI usage, no detailed command list or examples in the evidence pack beyond the reference page's existence.

   • [probe] “official CLI documented at https://docs.blaxel.ai/cli-reference/introduction”
   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”
   • [claimed-docs] “The easiest way to integrate the Blaxel CLI into a CI pipeline is with the official Blaxel GitHub Action.”

   proof ↗⚑ flag

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

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

   Blaxel✓fullprobed7/10

   Docs describe a REST API (accessible via SDK, MCP server, or REST API for sandbox filesystem/processes), API keys usable across APIs/CLI/SDK, and OAuth/API-key auth paradigms, indicating a genuine documented public API surface for driving Blaxel programmatically. However, direct probes for a formal OpenAPI/swagger spec returned 404s, so there's no single canonical machine-readable API reference confirmed. missing for 10: a published OpenAPI/swagger spec or interactive API reference, independent third-party confirmation of API usage.

   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”
   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”
   • [claimed-docs] “Blaxel employs two main authentication paradigms: **short-lived tokens** (OAuth) and **long-lived tokens** (API keys).”
   • [claimed-docs] “The easiest way to integrate the Blaxel CLI into a CI pipeline is with the official Blaxel GitHub Action.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.blaxel.ai/openapi.json, https://docs.blaxel.ai/swagger.json, https://docs.blaxel.ai/api…”

   proof ↗⚑ flag

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

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

   Blaxel~partialclaimed6/10

   Blaxel documents both short-lived OAuth tokens and long-lived API keys, plus time-limited scoped session tokens for sandbox access from frontends, and private preview URLs requiring tokens, showing genuine support for scoped/least-privilege credentials. However, there's no explicit fine-grained permission/scope model for API keys themselves (e.g., restricting an agent's key to specific resources or actions), missing for 10: documented scope/permission granularity for API keys, independent verification of least-privilege enforcement, and a unified credential-scoping API/CLI reference.

   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”
   • [claimed-docs] “Blaxel employs two main authentication paradigms: **short-lived tokens** (OAuth) and **long-lived tokens** (API keys).”
   • [claimed-docs] “Operate Blaxel sandboxes directly from a frontend client using time-limited, scoped session tokens generated by your backend, with no proxy …”
   • [claimed-docs] “When you create a private preview URL a token is required to access the URL.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

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

   Blaxel✓fullclaimed7/10

   Docs repeatedly reference official Blaxel SDKs (TypeScript, Python, Go) for core operations like filesystem access, process execution, and log streaming, plus API keys usable across CLI/API/SDK, indicating a first-party multi-language SDK ecosystem. Missing for 10: direct links to SDK repos/package registries, version/release info, and independent developer corroboration of SDK usage.

   • [claimed-docs] “Execute and manage processes in your sandboxes with Blaxel SDK. Run shell commands, retrieve process information, and control process execut…”
   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”
   • [claimed-docs] “Retrieve process output logs from sandboxes in batch or real-time streaming mode using the Blaxel SDK in TypeScript, Python, or Go.”
   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

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

   Blaxel—none0/10

   No evidence pack item mentions webhooks or event subscription mechanisms; documentation covers sandboxes, MCP servers, jobs, and infra but nothing about webhook subscriptions.

   ⚑ flag

Agentic features

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

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

   Blaxel✓fullclaimed7/10

   Blaxel provides Jobs for scheduled/on-demand batch AI processing and a Schedules feature to run sandbox commands on cron schedules, future datetimes, or delays with execution history, enabling autonomous background automation without manual triggering. Missing for 10: independent/hands-on verification of these automation features actually running unattended, and detail on triggering via external events (webhooks) beyond cron/jobs.

   • [claimed-docs] “Run a command inside a Blaxel sandbox on a recurring cron schedule, a future datetime, or after a delay, with execution history per run.”
   • [claimed-docs] “Run batch processing tasks for AI workflows on Blaxel as scheduled or on-demand jobs that scale automatically and run on serverless infrastr…”
   • [claimed-docs] “Jobs allow you to run many AI tasks in parallel using batch processing.”
   • [claimed-docs] “MCP Server Hosting is a serverless computing service that allows you to host remote MCP servers without having to manage infrastructure.”

   proof ↗⚑ flag

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

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

   Blaxel~partialprobed6/10

   Blaxel's skill (installable via MCP/agent integration) explicitly lets an agent deploy agents, create sandboxes, host MCP servers, and run jobs 'using simple prompts, zero code required,' directly matching natural-language operation. However, this is scoped to a specific 'skill' feature rather than a full natural-language interface across the whole product surface (CLI/SDK/API remain the primary interaction modes). Missing for 10: independent/hands-on evidence of the skill working in practice, broader coverage of natural-language control beyond the listed skill actions, and confirmation it spans all product surfaces (not just sandbox/agent/job creation).

   • [claimed-docs] “Install the Blaxel skill to give your agent the ability to deploy AI agents, create sandboxes for code execution, host MCP servers, run batc…”
   • [claimed-docs] “Install the Blaxel skill to give your agent the ability to deploy AI agents, create sandboxes for code execution, host MCP servers, run batc…”
   • [claimed-docs] “The open source Blaxel migration skill gives agents the knowledge they need to migrate sandbox code from other providers to Blaxel.”
   • [probe] “official MCP server documented at https://docs.blaxel.ai/skills-mcp”

   proof ↗⚑ flag

Api quality

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

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

   Blaxel—none0/10

   No evidence of an interactive API reference with runnable examples; the openapi probe explicitly found 404s for all candidate spec paths, indicating no discoverable OpenAPI/interactive reference. Docs describe SDK/CLI/REST usage but nothing about an explorable, runnable API console. Missing for 10: interactive API explorer UI, runnable code examples, OpenAPI spec availability.

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

   proof ↗⚑ flag

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

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

   Blaxel—none0/10

   Probe explicitly checked common OpenAPI/swagger paths and all returned 404, and no docs mention a downloadable machine-readable API spec; APIs are referenced generally but no OpenAPI file is exposed.

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

   proof ↗⚑ flag

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

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

   Blaxel✓fullclaimed8/10

   Blaxel sandboxes are ephemeral, isolated compute environments with filesystem, process, port, and network isolation (proxy domain allowlists, non-root execution, snapshots/forking) explicitly designed for safe execution separate from production, and can be created/destroyed/archived on demand without touching production data or systems. Docs also show volumes and expiration policies for controlling persistent state independently of production infra. Missing for 10: no explicit first-party statement equating sandboxes to a 'staging/test vs production' workflow, and no independent/hands-on validation of isolation guarantees.

   • [claimed-docs] “Every sandbox is exposed via an MCP server that allows agents to operate it using tool calls.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Create point-in-time snapshots of sandboxes, roll them back to a checkpoint, and fork them into new sandboxes.”
   • [claimed-docs] “Archive a sandbox to keep its filesystem while shutting it down, and unarchive it later to get it back.”
   • [claimed-docs] “Route outbound sandbox traffic through Blaxel's proxy with MITM header and body injection, inject secrets, and configure per-domain firewall…”
   • [claimed-docs] “Restrict which external domains, HTTP methods, and URL paths a Blaxel sandbox can reach using allowlists and denylists to prevent data exfil…”
   • [claimed-docs] “Attach Blaxel Volumes to sandboxes for persistent storage that survives sandbox destruction and recreation, with mount path configuration.”
   • [claimed-docs] “Scope everything a sandbox runs on your behalf to an unprivileged user while the sandbox API keeps the privileges it needs.”

   proof ↗⚑ flag

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

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

   Blaxel—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; the OpenAPI spec probe even returned 404s, and no docs mention versioning or deprecation practices. Missing for 10: versioned API scheme documentation, deprecation policy/notice process, changelog or migration guides for breaking changes.

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

   proof ↗⚑ flag

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

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

   Blaxel✓fullclaimed7/10

   Blaxel's Jobs feature explicitly supports running many AI tasks in parallel as batch processing, scaling automatically on serverless infra, and log retrieval also supports batch mode—directly matching bulk operations across many items. Missing for 10: independent/hands-on verification of batch job execution at scale and details on batch size limits or failure handling.

   • [claimed-docs] “Jobs allow you to run many AI tasks in parallel using batch processing.”
   • [claimed-docs] “Run batch processing tasks for AI workflows on Blaxel as scheduled or on-demand jobs that scale automatically and run on serverless infrastr…”
   • [claimed-docs] “Retrieve process output logs from sandboxes in batch or real-time streaming mode using the Blaxel SDK in TypeScript, Python, or Go.”

   proof ↗⚑ flag

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

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

   Blaxel~partialclaimed5/10

   Blaxel supports some automated, condition-triggered actions — cron/scheduled or delayed command execution in sandboxes (docs-26), automatic scale-to-zero after inactivity (docs-2/16), and automatic sandbox deletion on TTL/inactivity conditions (docs-25) — which qualify as rules triggering actions on events. However, there's no evidence of a general-purpose event/rule engine (e.g., custom webhook-based triggers, arbitrary event conditions tied to arbitrary actions) that an AI-native user could define beyond these built-in system behaviors. Missing for 10: a documented user-facing rule/trigger system for arbitrary events (e.g., webhooks, custom event listeners) and ability to chain arbitrary actions, independent confirmation of this working in practice.

   • [claimed-docs] “Run a command inside a Blaxel sandbox on a recurring cron schedule, a future datetime, or after a delay, with execution history per run.”
   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”
   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Blaxel✓fullclaimed8/10

   Blaxel explicitly supports running commands inside sandboxes on recurring cron schedules, future datetimes, or delays with execution history per run, and separately offers Jobs for scheduled or on-demand batch processing workflows that scale automatically. This directly covers recurring job/workflow scheduling for AI-native automation. Missing for 10: independent/hands-on corroboration beyond first-party docs, and more detail on complex multi-step workflow orchestration (vs single command/job scheduling).

   • [claimed-docs] “Run a command inside a Blaxel sandbox on a recurring cron schedule, a future datetime, or after a delay, with execution history per run.”
   • [claimed-docs] “Run batch processing tasks for AI workflows on Blaxel as scheduled or on-demand jobs that scale automatically and run on serverless infrastr…”
   • [claimed-docs] “Jobs allow you to run many AI tasks in parallel using batch processing.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Cloudflare Sandboxes~partialclaimed4/10

   Sandboxes offer git clone/branch operations for code and R2-based directory snapshot/restore, which give raw building blocks for versioning and rolling back sandbox state, but there is no dedicated 'automation' versioning, review, or rollback UI/workflow — it's up to the developer to wire this together. Missing for 10: no built-in review/diff tooling for automations, no automatic rollback trigger, no evidence of a workflow-specific version history feature, and no independent confirmation these primitives are actually used for automation rollback in practice.

   • [claimed-docs] “Clone repositories, manage branches, and automate Git operations.”
   • [claimed-docs] “Snapshot a sandbox directory to R2 and restore it later.”
   • [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

   Blaxel~partialclaimed4/10

   Blaxel documents point-in-time sandbox snapshots with rollback and forking (blaxel-docs-21), plus CI pipeline integration via a GitHub Action (blaxel-docs-13) which implies some deploy/version workflow, but there is no explicit documentation of versioning or review for agent/automation configurations themselves (only sandboxes). Missing for 10: version history for agent/automation definitions, an explicit review/approval workflow, and rollback of deployed agents/workflows (not just sandboxes).

   • [claimed-docs] “Create point-in-time snapshots of sandboxes, roll them back to a checkpoint, and fork them into new sandboxes.”
   • [claimed-docs] “The easiest way to integrate the Blaxel CLI into a CI pipeline is with the official Blaxel GitHub Action.”

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

   Blaxel—none0/10

   The evidence describes generic sandbox capabilities (processes, filesystem, MCP server, templates) but there is no vendor documentation or recipe specifically for running Claude Code, Codex, or other named coding agents inside a Blaxel sandbox.

   ⚑ flag

Workloads

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

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

   Blaxel—none0/10

   The evidence covers Blaxel sandbox capabilities extensively (filesystem, processes, ports, snapshots, templates) but never mentions headless browser support, GUI/desktop environments, or display/VNC access inside a sandbox. Missing for 10: any mention of headless browser tooling, GUI/X11/VNC support, or desktop environment images.

   • [claimed-docs] “Sandbox images allow you to create customized & reusable sandbox environments.”
   • [claimed-docs] “Execute and manage processes in your sandboxes with Blaxel SDK. Run shell commands, retrieve process information, and control process execut…”
   • [claimed-docs] “Expose specific TCP ports on a Blaxel sandbox so external clients can connect to web servers, dev servers, or other services running inside …”
   • [claimed-docs] “Create reusable sandbox images with pre-configured tools, languages, and frameworks using Dockerfiles. Deploy new sandboxes from images in s…”

   proof ↗⚑ flag

2. developerAttach GPUs to sandboxed workloads

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

   Blaxel—none0/10

   No evidence in the pack mentions GPU support, GPU instance types, or attaching GPUs to sandboxes anywhere in Blaxel's docs; sandbox docs cover CPU-based execution, filesystem, ports, snapshots, etc. but never hardware acceleration.

   ⚑ flag

Files

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly describe a filesystem interface for reading, writing, listing, and deleting files inside a sandbox via the SDK, MCP server, or REST API [blaxel-docs-18], reinforced by general sandbox MCP file-tool exposure [blaxel-docs-38]. Missing for 10: explicit mention of dedicated 'upload/download' semantics (e.g., binary/large file transfer) and independent hands-on confirmation beyond vendor docs.

   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”
   • [claimed-docs] “Every Blaxel sandbox exposes a built-in MCP server so agents can operate the sandbox using tool calls for files, processes, ports, and previ…”

   proof ↗⚑ flag

Runtimes

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly describe creating reusable sandbox images/templates via Dockerfiles, deploying new sandboxes from these custom images in seconds, and allowing pinning/customization of sandbox environments. This directly matches the story of defining custom sandbox templates or bringing a custom container image. Missing for 10: no independent/hands-on corroboration or explicit example of using a fully custom third-party base image beyond Dockerfile-based templates.

   • [claimed-docs] “Sandbox images allow you to create customized & reusable sandbox environments.”
   • [claimed-docs] “Create reusable sandbox images with pre-configured tools, languages, and frameworks using Dockerfiles. Deploy new sandboxes from images in s…”

   proof ↗⚑ flag

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

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

   Blaxel~partialclaimed6/10

   Blaxel sandboxes let you run arbitrary shell processes and build custom sandbox images (via Dockerfile) supporting any language runtime, and provide file/process/log APIs to retrieve execution output (blaxel-docs-17, blaxel-docs-32, blaxel-docs-20). However, there is no explicit documentation naming specific supported language runtimes (Python, JavaScript, etc.) or describing 'rich' structured results (e.g., images, tables, rendered output) beyond raw process logs. Missing for 10: explicit list of supported language runtimes, examples of running Python/JS code snippets, and documentation of rich/structured result formats beyond text logs.

   • [claimed-docs] “Execute and manage processes in your sandboxes with Blaxel SDK. Run shell commands, retrieve process information, and control process execut…”
   • [claimed-docs] “Create reusable sandbox images with pre-configured tools, languages, and frameworks using Dockerfiles. Deploy new sandboxes from images in s…”
   • [claimed-docs] “Retrieve process output logs from sandboxes in batch or real-time streaming mode using the Blaxel SDK in TypeScript, Python, or Go.”
   • [claimed-docs] “Sandbox images allow you to create customized & reusable sandbox environments.”

   proof ↗⚑ flag

Untrusted code

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

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

   Blaxel✓fullclaimed8/10

   Blaxel provides isolated sandboxes specifically for code execution, with scale-to-zero, non-root user scoping, outbound proxy allow/denylists to prevent exfiltration, snapshots/forking, and expiration policies—all designed to isolate untrusted execution from the developer's own infrastructure. This directly matches the story's intent of safely running AI-generated code without risking one's own systems. Missing for 10: independent/hands-on third-party validation of the isolation guarantees (all evidence is vendor docs, no external security audit or user report confirming sandbox escape resistance).

   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Scope everything a sandbox runs on your behalf to an unprivileged user while the sandbox API keeps the privileges it needs.”
   • [claimed-docs] “Restrict which external domains, HTTP methods, and URL paths a Blaxel sandbox can reach using allowlists and denylists to prevent data exfil…”
   • [claimed-docs] “Route outbound sandbox traffic through Blaxel's proxy with MITM header and body injection, inject secrets, and configure per-domain firewall…”
   • [claimed-docs] “Create point-in-time snapshots of sandboxes, roll them back to a checkpoint, and fork them into new sandboxes.”
   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”
   • [claimed-docs] “Create reusable sandbox images with pre-configured tools, languages, and frameworks using Dockerfiles. Deploy new sandboxes from images in s…”

   proof ↗⚑ flag

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly describe running shell commands and managing processes inside sandboxes via SDK, plus custom Docker images to install packages/tools/frameworks and deploy new sandboxes from them. This covers arbitrary command execution and package installation, though missing for 10: independent/hands-on verification and explicit documentation of ad-hoc package-manager usage (e.g., pip/npm install) at runtime versus only via prebuilt images.

   • [claimed-docs] “Execute and manage processes in your sandboxes with Blaxel SDK. Run shell commands, retrieve process information, and control process execut…”
   • [claimed-docs] “Create reusable sandbox images with pre-configured tools, languages, and frameworks using Dockerfiles. Deploy new sandboxes from images in s…”
   • [claimed-docs] “Sandbox images allow you to create customized & reusable sandbox environments.”
   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”

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

   Blaxel✓fullclaimed8/10

   Blaxel documents agents provisioning sandboxes via the Blaxel skill/SDK/MCP with zero-code prompts, executing code/processes, reading file/process/log output, and tearing down via expiration policies, archiving, or explicit deletion — all programmatically without human intervention. Every sandbox exposes an MCP server for tool-call-based operation, closing the loop end-to-end for an autonomous agent. Missing for 10: independent/hands-on verification of the full lifecycle (no third-party corroboration, only first-party docs).

   • [claimed-docs] “Install the Blaxel skill to give your agent the ability to deploy AI agents, create sandboxes for code execution, host MCP servers, run batc…”
   • [claimed-docs] “Every sandbox is exposed via an MCP server that allows agents to operate it using tool calls.”
   • [claimed-docs] “Execute and manage processes in your sandboxes with Blaxel SDK. Run shell commands, retrieve process information, and control process execut…”
   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”
   • [claimed-docs] “Retrieve process output logs from sandboxes in batch or real-time streaming mode using the Blaxel SDK in TypeScript, Python, or Go.”
   • [claimed-docs] “Archive a sandbox to keep its filesystem while shutting it down, and unarchive it later to get it back.”
   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”
   • [claimed-docs] “Every Blaxel sandbox exposes a built-in MCP server so agents can operate the sandbox using tool calls for files, processes, ports, and previ…”

   proof ↗⚑ flag

Isolation

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

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

   Blaxel—none0/10

   The evidence pack describes sandbox security features (non-root user scoping, outbound proxy/domain allowlists, secrets management, scoped session tokens) but never documents the underlying isolation mechanism (e.g., microVM, Firecracker, gVisor, or hypervisor-level separation) between sandboxes and host/other tenants. Without a stated hard isolation boundary technology, a platform engineer cannot verify the claim. Missing for 10: explicit architecture documentation naming a microVM or equivalent isolation technology, any independent/hands-on verification of isolation strength.

   • [claimed-docs] “Scope everything a sandbox runs on your behalf to an unprivileged user while the sandbox API keeps the privileges it needs.”
   • [claimed-docs] “Restrict which external domains, HTTP methods, and URL paths a Blaxel sandbox can reach using allowlists and denylists to prevent data exfil…”
   • [claimed-docs] “Route outbound sandbox traffic through Blaxel's proxy with MITM header and body injection, inject secrets, and configure per-domain firewall…”

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

   Blaxel✓fullclaimed7/10

   Blaxel sandboxes run as an unprivileged user while the sandbox API retains needed privileges, secrets/env vars are managed within the sandbox rather than exposing host credentials directly, and outbound traffic can be restricted via domain allow/denylists with secrets injected only at the proxy layer — together indicating the sandboxed code cannot directly reach host secrets. missing for 10: no independent security audit or pentest confirming host-credential isolation, and no explicit statement that host secrets are categorically unreachable (only inferred from architecture).

   • [claimed-docs] “Scope everything a sandbox runs on your behalf to an unprivileged user while the sandbox API keeps the privileges it needs.”
   • [claimed-docs] “Configure environment variables and secrets in Blaxel sandboxes to securely manage API keys, credentials, and runtime configuration values.”
   • [claimed-docs] “Route outbound sandbox traffic through Blaxel's proxy with MITM header and body injection, inject secrets, and configure per-domain firewall…”
   • [claimed-docs] “Restrict which external domains, HTTP methods, and URL paths a Blaxel sandbox can reach using allowlists and denylists to prevent data exfil…”
   • [claimed-docs] “When you create a private preview URL a token is required to access the URL.”

   proof ↗⚑ flag

Network policy

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

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

   Blaxel✓fullclaimed9/10

   Docs explicitly describe egress control via Blaxel's proxy with per-domain firewalls, allowlists/denylists restricting domains, HTTP methods, and URL paths to prevent data exfiltration, giving platform engineers explicit policy control over sandbox network egress. Missing for 10: independent/hands-on verification beyond vendor docs.

   • [claimed-docs] “Route outbound sandbox traffic through Blaxel's proxy with MITM header and body injection, inject secrets, and configure per-domain firewall…”
   • [claimed-docs] “Restrict which external domains, HTTP methods, and URL paths a Blaxel sandbox can reach using allowlists and denylists to prevent data exfil…”

   proof ↗⚑ flag

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

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

   Blaxel~partialprobed6/10

   Blaxel documents API keys usable across API, CLI and SDK, REST API access for sandbox filesystem operations, and a CLI/SDK that mirrors most UI capabilities (sandboxes, jobs, MCP hosting, agents). However, the OpenAPI probe returned 404 across all candidate paths, so there is no confirmed comprehensive API reference proving full UI parity. Missing for 10: a discoverable/documented full API spec (OpenAPI/swagger) confirming complete feature parity, and explicit confirmation that every UI-only action (e.g., region pinning, preview URL custom domain setup) is also API-accessible.

   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”
   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”
   • [claimed-docs] “Blaxel employs two main authentication paradigms: **short-lived tokens** (OAuth) and **long-lived tokens** (API keys).”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.blaxel.ai/openapi.json, https://docs.blaxel.ai/swagger.json, https://docs.blaxel.ai/api…”
   • [probe] “official CLI documented at https://docs.blaxel.ai/cli-reference/introduction”

   proof ↗⚑ flag

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

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

   Blaxel—none0/10

   Evidence only shows a migration skill for bringing sandbox code INTO Blaxel from other providers (docs-4), not exporting data out in open formats. No documentation of data export, backup-to-open-format, or account/data portability for leaving the platform.

   • [claimed-docs] “The open source Blaxel migration skill gives agents the knowledge they need to migrate sandbox code from other providers to Blaxel.”

   proof ↗⚑ flag

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

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

   Blaxel—none0/10

   There's a mention of an 'open source Blaxel migration skill' but no evidence that Blaxel's core product source code is available under an open license; the evidence pack contains only docs/product feature descriptions, not licensing or repository information for the product itself.

   • [claimed-docs] “The open source Blaxel migration skill gives agents the knowledge they need to migrate sandbox code from other providers to Blaxel.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   Blaxel—none0/10

   Blaxel is presented entirely as a managed serverless/cloud platform (sandboxes, MCP hosting, jobs, agent drive) with no mention of a self-hosted/on-prem deployment option, Docker Compose, Helm chart, or open-source core that a user could run themselves. Missing for 10: any documentation of self-hosting instructions, open-source repo for the core runtime, or on-prem/air-gapped deployment support.

   ⚑ flag

Latency

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly document sub-second cold start performance: resume from standby in under 25ms even after weeks of inactivity, with automatic scale-to-zero after 5s, stated consistently across overview and sandbox docs. Missing for 10: independent/hands-on benchmark corroboration beyond first-party docs, and no detail on cold start from a fully-destroyed (non-standby) state.

   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”

   proof ↗⚑ flag

Scale

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

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

   Blaxel~partialclaimed4/10

   Docs describe serverless scaling, scale-to-zero, and parallel batch job processing (blaxel-docs-2, blaxel-docs-10, blaxel-docs-35), implying support for fleets of sandboxes, but there is no documented numeric concurrency limit, quota, or rate-limit guidance for platform engineers to plan capacity around. missing for 10: explicit documented concurrency/quota limits, benchmark data on max concurrent sandboxes, guidance on scaling ceilings or throttling behavior at scale.

   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Jobs allow you to run many AI tasks in parallel using batch processing.”
   • [claimed-docs] “Run batch processing tasks for AI workflows on Blaxel as scheduled or on-demand jobs that scale automatically and run on serverless infrastr…”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”

   proof ↗⚑ flag

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

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

   Blaxel~partialclaimed6/10

   Blaxel offers several building blocks that support long-running agent work — persistent volumes that survive destruction/recreation (blaxel-docs-29), archive/unarchive to preserve state (blaxel-docs-22), snapshot/fork/rollback (blaxel-docs-21), and configurable expiration/TTL policies (blaxel-docs-25) — but the core sandbox model is scale-to-zero after only 5s of inactivity with fast (25ms) resume (blaxel-docs-2, blaxel-docs-16), meaning continuous multi-hour/day sessions aren't the default behavior, only reconstructable state. There is no explicit doc claim of a sandbox running uninterrupted for hours/days. Missing for 10: explicit documentation of maximum/extended continuous session duration, and independent evidence of a sandbox actually kept alive for hours or days during a real agent task.

   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Archive a sandbox to keep its filesystem while shutting it down, and unarchive it later to get it back.”
   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”
   • [claimed-docs] “Attach Blaxel Volumes to sandboxes for persistent storage that survives sandbox destruction and recreation, with mount path configuration.”
   • [claimed-docs] “Create point-in-time snapshots of sandboxes, roll them back to a checkpoint, and fork them into new sandboxes.”

   proof ↗⚑ flag

Pricing

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

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

   Blaxel—none0/10

   No evidence pack item mentions a free tier, free credits, pricing page, or self-serve signup without sales contact; all evidence is about product features (sandboxes, MCP, jobs, auth) rather than pricing/access model. missing for 10: any mention of free tier, trial credits, self-serve signup, or pricing page.

   ⚑ flag

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

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

   Blaxel~partialclaimed4/10

   Docs describe automatic scale-to-zero after 5s inactivity and sub-25ms resume, implying compute is only consumed while active, but there is no explicit statement of per-second billing granularity or pricing model. missing for 10: explicit per-second pricing/billing documentation, cost breakdown examples, independent confirmation of billing granularity.

   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”

   proof ↗⚑ flag

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

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

   Blaxel~partialclaimed6/10

   Blaxel docs explicitly support region selection/pinning for agents, MCP servers, and other resources via a region field in blaxel.toml, giving users some control over deployment location. However, this is framed around performance/latency choice rather than formal data residency/compliance guarantees, and there's no mention of a full list of regions, data residency certifications, or compliance framework. Missing for 10: explicit data residency/compliance guarantees, full region list, and independent confirmation that data (not just compute) stays within chosen region.

   • [claimed-docs] “you can optionally pin an agent or MCP server to a specific region by setting the region field in your blaxel.toml”
   • [claimed-docs] “When deploying a resource on Blaxel, you sometimes have the option to choose the deployment region.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

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

   Blaxel~partialclaimed5/10

   Blaxel documents sandbox-level lifecycle controls that touch retention/deletion: configurable expiration policies to auto-delete sandboxes after TTL/inactivity (blaxel-docs-25), archive/unarchive to preserve or remove filesystem data (blaxel-docs-22), and explicit file delete operations via SDK/REST/MCP (blaxel-docs-18). However there is no documentation of account-level or organization-wide data retention policies, GDPR/CCPA deletion guarantees, or data-export/erasure workflows beyond sandbox resources. Missing for 10: account-level data deletion/export controls, formal retention policy documentation, compliance certifications, independent confirmation that deletion is permanent.

   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”
   • [claimed-docs] “Archive a sandbox to keep its filesystem while shutting it down, and unarchive it later to get it back.”
   • [claimed-docs] “Read, write, list, and delete files inside a Blaxel sandbox using a simple file system interface from the SDK, MCP server, or REST API.”

   proof ↗⚑ flag

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

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

   Blaxel—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics collection, or an opt-out setting; the axis is applicable to a developer platform like Blaxel but no documentation addresses it.

   ⚑ flag

Lifecycle

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly describe automatic scale-to-zero after 5s inactivity (stopping compute billing) and configurable expiration policies to auto-delete sandboxes after inactivity or a TTL, directly matching the story's timeout/idle-shutdown need. missing for 10: no explicit statement that billing itself stops immediately on scale-to-zero (only inferred), and no independent/hands-on confirmation beyond first-party docs.

   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Configure expiration policies to automatically delete Blaxel sandboxes after inactivity, a TTL, or other conditions to control snapshot stor…”

   proof ↗⚑ flag

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly describe creating sandboxes via SDK/CLI/API with fast startup (resume from standby under 25ms, deploy from images in seconds) and scale-to-zero, matching the 'one call, live in seconds' story. Missing for 10: independent/hands-on timing benchmarks or third-party corroboration beyond first-party docs.

   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”
   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Create reusable sandbox images with pre-configured tools, languages, and frameworks using Dockerfiles. Deploy new sandboxes from images in s…”
   • [claimed-docs] “API keys can be used in the Blaxel APIs, CLI and SDK.”
   • [claimed-docs] “Sandbox images allow you to create customized & reusable sandbox environments.”

   proof ↗⚑ flag

Preview access

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

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

   Blaxel✓fullclaimed9/10

   Docs explicitly describe exposing TCP ports from a sandbox for external clients to reach services (blaxel-docs-23) and rendering apps via direct preview URLs backed by a running sandbox, with optional auth and custom domains (blaxel-docs-33, blaxel-docs-3, blaxel-docs-8). Missing for 10: independent/hands-on confirmation beyond first-party docs.

   • [claimed-docs] “Expose specific TCP ports on a Blaxel sandbox so external clients can connect to web servers, dev servers, or other services running inside …”
   • [claimed-docs] “Render an application in real-time through a direct preview URL backed by a running Blaxel sandbox, with optional auth and custom domains.”
   • [claimed-docs] “Preview URLs with your own custom domain.”
   • [claimed-docs] “When you create a private preview URL a token is required to access the URL.”

   proof ↗⚑ flag

Snapshots

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

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

   Blaxel~partialclaimed6/10

   Blaxel supports scale-to-zero with sub-25ms resume, point-in-time snapshots with rollback/fork, and archive/unarchive that preserves the filesystem while shutting down a sandbox — together these cover the core pause/resume-with-state story. However, it's unclear whether in-memory process state (not just filesystem) survives archive/scale-to-zero, and there's no independent/hands-on confirmation beyond vendor docs. missing for 10: explicit confirmation that in-memory/process state (not just filesystem) is preserved across pause/resume, independent or hands-on verification of the resume behavior.

   • [claimed-docs] “Sandboxes resume from standby in under 25 milliseconds and automatically scale to zero after a few seconds of inactivity.”
   • [claimed-docs] “Create point-in-time snapshots of sandboxes, roll them back to a checkpoint, and fork them into new sandboxes.”
   • [claimed-docs] “Archive a sandbox to keep its filesystem while shutting it down, and unarchive it later to get it back.”
   • [claimed-docs] “Automatic scale-to-zero after 5s inactivity, resume from standby under 25ms even after weeks.”

   proof ↗⚑ flag

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

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

   Blaxel✓fullclaimed8/10

   Docs explicitly state sandboxes support point-in-time snapshots, rollback to checkpoint, and forking into new sandboxes, directly matching the story. Missing for 10: independent/hands-on corroboration beyond first-party docs and detail on API/CLI usage specifics for restore workflows.

   • [claimed-docs] “Create point-in-time snapshots of sandboxes, roll them back to a checkpoint, and fork them into new sandboxes.”

   proof ↗⚑ flag