Vercel Sandbox vs Blaxel

Agent access

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

   weight 2 · round to Blaxel
   Vercel Sandbox✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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 drawn
   Vercel Sandbox✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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 to Blaxel
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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 to Vercel Sandbox
   Vercel Sandbox~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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 Blaxel
   Vercel Sandbox~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullprobed7/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox~partialclaimed3/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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 drawn
   Vercel Sandbox~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox—none0/10

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

   ⚑ flag

   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 drawn
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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 to Blaxel
   Vercel Sandbox~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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 Vercel Sandbox
   Vercel Sandbox✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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
   Vercel Sandbox~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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