Blaxel vs Maritime

Agent access

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

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

   Maritime✓fullprobed9/10

   Maritime hosts a live llms.txt (confirmed by a 200 probe) plus a dedicated CLI llms.txt and an ai-agents docs page explicitly designed for agents (Claude Code, Cursor, etc.) to consume, authenticate, and act on — directly matching the story. Missing for 10: no independent third-party confirmation that agents actually navigate these docs successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”
   • [claimed-docs] “Templates are cloneable agent packages; publishers can share them via link or the public library.”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
   • [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”

   proof ↗⚑ flag

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

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

   Maritime✓fullprobed8/10

   Maritime provides a CLI with --json flag on every command, machine-readable output, stable exit codes, and env-var (non-interactive) authentication via MARITIME_TOKEN, explicitly designed for automation/CI use and control by other AI agents rather than humans, plus a RESTful API and idempotent provisioning for scripted workflows. This directly supports headless/CI operation across CLI and SDK/API paths. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions/GitLab CI snippet) or independent third-party confirmation of CI usage.

   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
   • [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
   • [claimed-docs] “Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOKEN`. Keys never expire; browser-login tokens do.”
   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
   • [probe] “official CLI documented at https://maritime.sh/docs/cli”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime is a platform for deploying and hosting agents built with frameworks (CrewAI, LangGraph, etc.), but the evidence pack shows no mention of MCP server integration or a mechanism for agents to consume external MCP tool servers. Nothing describes plugging in MCP servers to extend tool use.

   ⚑ flag

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

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

   Maritime—none0/10

   Maritime is a platform for deploying/hosting agents (not itself an agent), so an official MCP server is a fair axis to expect, but no evidence pack item mentions MCP, an MCP server, or MCP-compatible endpoints — only REST API, CLI, SDKs, and webhooks are documented.

   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “The Maritime CLI lets you deploy and manage agents from your terminal.”
   • [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

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

   Maritime✓fullprobed9/10

   Maritime ships an official npm-installable CLI explicitly designed for AI-native use: machine-readable/--json output on every command, stable exit codes, a self-describing contract, and env-var (non-interactive) authentication via MARITIME_TOKEN, all documented at /docs/cli and /docs/ai-agents. It also supports agent-driven install/auth/deploy flows via prompted assistants. Missing for 10: independent/hands-on verification beyond vendor docs.

   • [claimed-docs] “The Maritime CLI lets you deploy and manage agents from your terminal.”
   • [claimed-docs] “npm install -g maritime-cli”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
   • [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
   • [probe] “official CLI documented at https://maritime.sh/docs/cli”

   proof ↗⚑ flag

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

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

   Maritime✓fullprobed8/10

   Maritime documents a full public API (REST endpoints, TypeScript/Python SDKs, idempotent provisioning, webhooks, scoped bearer-token auth) plus a CLI explicitly built for AI agents with machine-readable JSON output and stable exit codes, directly enabling AI-native driving of the platform. missing for 10: a discoverable machine-readable spec (openapi.json/swagger.json returned 404) and independent third-party corroboration of the API's stability.

   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
   • [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
   • [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
   • [claimed-docs] “Get notified when a customer's agent changes state, instead of polling. Subscribe a URL, and Maritime POSTs a signed JSON body on every life…”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
   • [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”

   proof ↗⚑ flag

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

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

   Maritime✓fullclaimed8/10

   Maritime documents scoped API keys explicitly: every key carries scopes, users should hand subsystems the narrowest key they need, and a dedicated example shows a Computers-only key being refused on all other endpoints — a concrete least-privilege mechanism. This pairs with CLI/env-based key minting (mk_ tokens) suited to agent automation. Missing for 10: an exhaustive scope catalog/reference and independent (non-vendor) verification of scope enforcement in practice.

   • [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
   • [claimed-docs] “To hand out a key that reaches computers and nothing else, create a **Computers key** in the Computers section of Settings, API keys”
   • [claimed-docs] “Every key carries scopes. Hand a subsystem the _narrowest_ key it needs. A leaked key can then only do what its scope allows.”
   • [claimed-docs] “a key whose only scope is `computers` is refused on every other Maritime endpoint”
   • [claimed-docs] “Hand a subsystem the _narrowest_ key it needs. A leaked key can then only do what its scope allows.”
   • [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
   • [claimed-docs] “Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOKEN`. Keys never expire; browser-login tokens do.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

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

   Maritime✓fullprobed8/10

   Maritime documents official TypeScript and Python SDKs with idempotent agent provisioning, scoped authentication, webhooks, messaging, and a Files API, plus an npm-installable CLI and RESTful API, all clearly aimed at building AI-native integrations. missing for 10: no public OpenAPI/swagger spec found (404s) and no independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
   • [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
   • [claimed-docs] “Give every one of your users their own agent with the TypeScript or Python SDK.”
   • [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “The Maritime Files API: eight endpoints and both SDKs to browse, upload, download, and edit an agent's disk over HTTP, even while the agent …”
   • [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

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

   Maritime✓fullclaimed7/10

   Docs explicitly describe subscribing a URL to receive signed JSON POSTs on every agent lifecycle event, replacing polling, which directly matches the story. missing for 10: independent/hands-on confirmation of webhook delivery reliability, payload schema details, and signature verification specifics.

   • [claimed-docs] “Get notified when a customer's agent changes state, instead of polling. Subscribe a URL, and Maritime POSTs a signed JSON body on every life…”
   • [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”

   proof ↗⚑ flag

Agentic features

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

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

   Maritime✓fullclaimed8/10

   Maritime provides cron triggers with standard five-field expressions that wake agents on schedule and deliver prompts, plus agents can self-schedule their own wake triggers (e.g., 'send me a digest every weekday at 9'), and agents run persistently on always-on micro-VMs with sleep/wake economics, enabling true background autonomous automation. Missing for 10: independent/hands-on verification of trigger reliability and no mention of monitoring/alerting on automation failures.

   • [claimed-docs] “A cron trigger takes a standard five-field expression, wakes the agent on schedule, and delivers its `prompt` as a chat message on every fir…”
   • [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
   • [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
   • [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
   • [claimed-docs] “Maritime gives it what a laptop session can't: its own always-on micro-VM in the cloud, persistent storage, sleep/wake economics, and every …”

   proof ↗⚑ flag

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

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

   Maritime~partialclaimed6/10

   Maritime documents natural-language operation at the agent level (chat with agents, cron-triggered prompts set via natural language like 'send me a digest every weekday at 9') and CLI/API designed to be driven by AI agents via prompts (paste a prompt into Claude/Cursor to install and operate). However, the core Maritime platform itself (dashboard, agent management) is not shown to be operable purely via natural-language commands by the end user — the NL interface is mediated through the CLI/API being agent-friendly rather than a native NL command surface for platform operations. missing for 10: evidence of a native NL interface for platform-level operations (not just agent chat/prompts), independent/hands-on confirmation of this workflow succeeding.

   • [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
   • [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”
   • [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
   • [claimed-docs] “point Claude Code or your Maritime agent at a provider's runbook page and it can inventory the old provider with read-only credentials, recr…”

   proof ↗⚑ flag

Api quality

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

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

   Maritime—none0/10

   Docs describe a RESTful API and CLI but there's no evidence of an interactive API reference (e.g., Swagger/OpenAPI explorer) with runnable examples; probes explicitly show no openapi.json/swagger.json spec found at any candidate path. missing for 10: interactive API console/playground, OpenAPI spec, runnable code examples in docs.

   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime documents a RESTful API and CLI with --json output, but there is no evidence of a downloadable machine-readable spec (OpenAPI/Swagger); active probes for openapi.json, swagger.json, and similar paths all returned 404.

   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime's docs cover deployment, keys/scopes, templates, triggers, and agent lifecycle, but nothing describes a sandbox/staging environment isolated from production data for testing purposes. Missing for 10: any mention of a sandbox/test mode, staging environment, or data isolation guarantees between test and production agents.

   ⚑ flag

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

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

   Maritime—none0/10

   No evidence of API versioning scheme (e.g., v1/v2 paths) or any documented deprecation policy; OpenAPI spec probes all 404, and no docs mention version support windows or breaking-change policy.

   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”
   • [claimed-docs] “RESTful API for managing agents programmatically.”

   proof ↗⚑ flag

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

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

   Maritime~partialclaimed4/10

   There is explicit support for bulk import of config/env vars (maritime-docs-11) and a scriptable CLI/API with JSON output (maritime-docs-9, maritime-docs-36) that an AI-native user could loop over to perform bulk actions, but there is no documented batch/bulk endpoint for operating on many agents or resources at once. missing for 10: a dedicated bulk-operation API/CLI command (e.g. bulk create/delete/update agents), evidence of scaling to many items reliably, and independent confirmation of bulk workflows in practice.

   • [claimed-docs] “Bulk import from a .env file (or stdin), then hot-reload”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”

   proof ↗⚑ flag

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

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

   Maritime~partialclaimed6/10

   Maritime supports triggers (cron with five-field expressions, natural-language schedule setting, webhooks for lifecycle events) that wake agents and fire actions automatically, which covers rule-based automation on events. However, this is event/schedule-based triggering rather than a general-purpose conditional rules engine (e.g., no evidence of arbitrary if/then logic across multiple event types or complex conditions). missing for 10: evidence of a general conditional rules/policy engine beyond cron and webhook triggers, and independent/hands-on confirmation of trigger reliability.

   • [claimed-docs] “A cron trigger takes a standard five-field expression, wakes the agent on schedule, and delivers its `prompt` as a chat message on every fir…”
   • [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
   • [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
   • [claimed-docs] “Get notified when a customer's agent changes state, instead of polling. Subscribe a URL, and Maritime POSTs a signed JSON body on every life…”
   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Maritime✓fullclaimed8/10

   Maritime explicitly supports cron triggers with standard five-field expressions that wake agents and deliver prompts on schedule, plus a natural-language flow where an agent sets its own recurring schedule ('send me a digest every weekday at 9') that syncs into real wake triggers. This directly covers recurring job/workflow scheduling for AI-native users. Missing for 10: independent/hands-on verification beyond vendor docs, and no detail on managing/editing/cancelling existing scheduled triggers via CLI/API.

   • [claimed-docs] “A cron trigger takes a standard five-field expression, wakes the agent on schedule, and delivers its `prompt` as a chat message on every fir…”
   • [claimed-docs] “Ask the agent (OpenClaw-family and Hermes templates): tell it "send me a digest every weekday at 9" and the platform syncs the schedule it s…”
   • [claimed-docs] “tell it "send me a digest every weekday at 9" and the platform syncs the schedule it sets for itself into real wake triggers”
   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   No evidence of version history, review workflows, or rollback for automations/agent configs; docs cover deployment, triggers, builds, and CLI but nothing about versioning or reverting agent configuration/automation changes.

   ⚑ 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 Maritime
   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

   Maritime✓fullclaimed8/10

   Maritime documents dedicated template recipes for running Claude Code and Codex inside its sandboxed micro-VMs (persistent storage, sleep/wake, metered LLM access by default, chat channels), directly matching the vendor's own recipe framing for these named coding agents. missing for 10: independent/hands-on verification beyond vendor docs, and no direct evidence of a step-by-step 'follow this exact recipe' walkthrough output for a live run.

   • [claimed-docs] “Maritime gives it what a laptop session can't: its own always-on micro-VM in the cloud, persistent storage, sleep/wake economics, and every …”
   • [claimed-docs] “No key is required: the agent uses Maritime's metered LLM access by default.”
   • [claimed-docs] “Every ready-made template is a real agent framework, pre-configured and one image pull from live. Pick one, name it, deploy.”
   • [claimed-docs] “point Claude Code or your Maritime agent at a provider's runbook page and it can inventory the old provider with read-only credentials, recr…”
   • [claimed-docs] “Paste one prompt into Claude, Cursor, or any assistant and it can install the CLI, authenticate, and deploy agents for you.”

   proof ↗⚑ flag

Workloads

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

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

   Maritime✓fullclaimed7/10

   Maritime docs explicitly describe 'Computers': a persistent Linux desktop (XFCE, Chromium, LibreOffice) per user driven by a model, and the changelog confirms agents get a real Linux desktop with screenshot/mouse/keyboard control and live takeover — this covers full desktop environments including a browser (Chromium) inside the sandbox. missing for 10: no independent/hands-on corroboration of performance or headless-only browser mode, and no detail on resource limits or concurrency.

   • [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
   • [claimed-docs] “Agents are getting a real Linux desktop they can drive: screenshot, mouse, keyboard, and a live view you can take over.”
   • [claimed-docs] “To hand out a key that reaches computers and nothing else, create a **Computers key** in the Computers section of Settings, API keys”

   proof ↗⚑ flag

2. developerAttach GPUs to sandboxed workloads

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

   Maritime—none0/10

   No evidence anywhere in the pack mentions GPUs, GPU-accelerated instances, or hardware acceleration for sandboxed agent workloads; all compute descriptions reference micro-VMs, sleep/wake, and CPU-based containers only. Missing for 10: any mention of GPU attachment, GPU instance types, or hardware accelerator support.

   • [claimed-docs] “Maritime gives it what a laptop session can't: its own always-on micro-VM in the cloud, persistent storage, sleep/wake economics, and every …”
   • [claimed-docs] “Any Docker container becomes an agent: three endpoints get you sleep/wake, channels, and triggers.”

   proof ↗⚑ flag

Files

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

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

   Maritime—none0/10

   No evidence pack item mentions SDK-based file read/write/upload/download operations against a sandbox filesystem; the docs cover agent provisioning, webhooks, auth scoping, triggers, computers (desktop), CLI, and migration but nothing about filesystem file I/O via SDK. Missing for full: no filesystem API/SDK method docs, no upload/download endpoint references, no code samples showing file operations.

   ⚑ flag

Runtimes

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

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

   Maritime~partialclaimed6/10

   Docs confirm bring-your-own-image support via a documented three-endpoint contract that works with any Docker image (CrewAI, LangGraph, AutoGen, custom scripts), plus a build log and template system for packaging custom agents. However, there's no detailed spec of the contract itself, no example custom Dockerfile, and no independent/hands-on confirmation of successfully running a fully custom image end-to-end. missing for 10: full technical spec of the three-endpoint contract, a worked example of a custom image deployment, independent verification of custom image support beyond docs claims.

   • [claimed-docs] “CrewAI, LangGraph, AutoGen, your own Python script: any Docker image that speaks a three-endpoint contract gets the whole platform.”
   • [claimed-docs] “Templates are cloneable agent packages; publishers can share them via link or the public library.”
   • [claimed-docs] “The agent page streams the build log live under **Overview → Builds**.”
   • [claimed-docs] “Every ready-made template is a real agent framework, pre-configured and one image pull from live. Pick one, name it, deploy.”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime's evidence describes deploying persistent Docker-based agents (any Docker image with sleep/wake/channels/triggers), a Files API, and a Linux desktop 'Computers' feature, but nothing describes a code-execution/sandbox API that runs snippets in multiple language runtimes (Python, JS, etc.) and returns structured/rich results (e.g., stdout, images, dataframes) the way a code-interpreter tool would.

   • [claimed-docs] “Any Docker container becomes an agent: three endpoints get you sleep/wake, channels, and triggers.”
   • [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
   • [claimed-docs] “The Maritime Files API: eight endpoints and both SDKs to browse, upload, download, and edit an agent's disk over HTTP, even while the agent …”
   • [claimed-docs] “CrewAI, LangGraph, AutoGen, your own Python script: any Docker image that speaks a three-endpoint contract gets the whole platform.”

   proof ↗⚑ flag

Untrusted code

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

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

   Maritime~partialprobed5/10

   Maritime hosts agents as Docker images on 'serverless infrastructure' (maritime-docs-1, maritime-probe-1) and provides persistent isolated Linux desktops per end user (maritime-docs-5), which implies agent code runs off the developer's own machines/infra. However, there is no explicit documentation of sandboxing guarantees, resource/network isolation, or security boundaries specifically for running untrusted or AI-generated code safely. Missing for 10: explicit sandbox/isolation security model, resource-limit guarantees, and any independent verification that untrusted code cannot escape or affect other tenants/infra.

   • [claimed-docs] “CrewAI, LangGraph, AutoGen, your own Python script: any Docker image that speaks a three-endpoint contract gets the whole platform.”
   • [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime's docs describe deploying agents via Docker images, templates, and a custom framework contract, but there is no evidence of an interactive shell/terminal access or arbitrary package installation inside a running sandbox for a developer to use directly. The 'Computers' feature offers a persistent desktop for end-users, not a shell for arbitrary command execution by the developer.

   ⚑ flag

Agent lifecycle

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

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

   Maritime~partialclaimed6/10

   Maritime's CLI and SDK let an agent provision (idempotent) itself, run in a sandboxed micro-VM/container, and be managed via authenticated API/CLI calls with JSON output designed for machine consumption, and agents can be torn down/put to sleep automatically when idle. However, the evidence is docs-only with no hands-on trace of an agent actually reading back code-execution results or explicit 'delete/destroy' teardown call, and no independent verification of the full autonomous loop. missing for 10: concrete evidence of an agent reading execution output programmatically, an explicit teardown/delete API example, and independent/hands-on confirmation of the full provision→execute→read→teardown loop.

   • [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [claimed-docs] “The Maritime CLI is built to be operated by other AI agents, not just humans: machine-readable output on every command, stable exit codes, a…”
   • [claimed-docs] “Authenticate with an env var, never interactively. Mint a long-lived key (`mk_…`) with `maritime keys create` and export it as `MARITIME_TOK…”
   • [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
   • [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
   • [claimed-docs] “Any Docker container becomes an agent: three endpoints get you sleep/wake, channels, and triggers.”

   proof ↗⚑ flag

Isolation

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

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

   Maritime—none0/10

   No evidence pack item documents a specific isolation mechanism (microVM, gVisor, container hardening, VM boundary) between sandboxes and host systems; docs mention Docker images, serverless infra, and scoped API keys but not the underlying execution isolation boundary. Missing for 10: any explicit statement of sandbox isolation technology, security model documentation, or third-party audit/confirmation of hard isolation.

   ⚑ flag

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

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

   Maritime~partialclaimed6/10

   Maritime's docs describe per-agent micro-VM isolation with secrets 'injected only into that agent's VM' and encrypted at rest, plus scoped API keys so a leaked key 'can only do what its scope allows,' which together imply host-level credentials aren't reachable by agent code. However, there's no explicit documentation of sandbox mechanics like blocking cloud metadata endpoints, filesystem isolation from the host, or independent security testing confirming secrets are truly unreachable. missing for 10: explicit host-credential isolation guarantees (e.g., no metadata service access, filesystem boundary details), independent/hands-on security verification.

   • [claimed-docs] “Variables are **secret by default**: stored encrypted at rest, injected only into that agent's VM, and always masked in the UI.”
   • [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
   • [claimed-docs] “To hand out a key that reaches computers and nothing else, create a **Computers key** in the Computers section of Settings, API keys”
   • [claimed-docs] “a key whose only scope is `computers` is refused on every other Maritime endpoint”
   • [claimed-docs] “Every key carries scopes. Hand a subsystem the _narrowest_ key it needs. A leaked key can then only do what its scope allows.”

   proof ↗⚑ flag

Network policy

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

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

   Maritime—none0/10

   No evidence pack item mentions network egress controls, firewall rules, or any explicit allow/deny policy for outbound traffic from the sandbox/agent VM; the closest material covers API key scoping and secret management, not network policy.

   ⚑ flag

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

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

   Maritime~partialprobed6/10

   Docs show a broad API/SDK/CLI surface (provisioning, keys, webhooks, triggers, computers, templates, builds) and CLI --json mode implying the CLI itself is just an API wrapper, suggesting an API-first architecture. However there's no explicit statement of full UI/API parity and no discoverable OpenAPI spec (probes return 404s for all schema locations), so completeness of API coverage relative to every UI feature can't be confirmed. missing for 10: explicit parity statement, published OpenAPI/API reference, independent confirmation that every UI action has an API equivalent.

   • [claimed-docs] “Mint a personal API key with `maritime keys create` and send it as a Bearer token, the same token the CLI itself uses.”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”
   • [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
   • [claimed-docs] “Hand a subsystem the narrowest key it needs. A leaked key can then only do what its scope allows.”
   • [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
   • [claimed-docs] “The agent page streams the build log live under **Overview → Builds**.”
   • [claimed-docs] “Templates are cloneable agent packages; publishers can share them via link or the public library.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Evidence shows import/migration INTO Maritime (from AWS/Heroku/VPS, .env bulk import) and a CLI with --json output, but nothing documents exporting agent configs, data, secrets, or state OUT in open formats to leave the platform. missing for 10: an export command or documented data-portability feature, open-format export of agent state/configs, any migration-out guide.

   • [claimed-docs] “Bulk import from a .env file (or stdin), then hot-reload”
   • [claimed-docs] “Migrate from AWS, Heroku, or a VPS”
   • [claimed-docs] “Pass --json on EVERY command. Success: one JSON value on stdout, stderr empty.”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime is a closed commercial SaaS platform; there is no evidence of an open-source license or public source repository anywhere in the docs or probes. missing for 10: an open-source license, a public source code repository, any mention of licensing terms for the platform's own code.

   ⚑ flag

4. ai-native userSelf-host the core product

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

   Maritime—none0/10

   Maritime is explicitly described as a cloud platform with agents running on serverless infrastructure, and no documentation offers a self-hosted deployment option for the core platform itself (Docker images are for agent frameworks running atop Maritime's cloud, not for self-hosting Maritime).

   • [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”
   • [claimed-docs] “Migrate from AWS, Heroku, or a VPS”

   proof ↗⚑ flag

Latency

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

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

   Maritime—none0/10

   Maritime's docs describe sleep/wake behavior (e.g., 'Sleeping agents wake automatically', 'puts it to sleep when idle, and wakes it on the next visit') and an 'always-on' add-on for millisecond reaction, but no evidence anywhere documents actual cold-start latency numbers (sub-second to few-second) for waking a sandboxed agent from sleep.

   • [claimed-docs] “Send a message and wait for the reply. Sleeping agents wake automatically.”
   • [claimed-docs] “Any repo with a Dockerfile can be served on a public, no-login HTTPS URL. Maritime builds it, runs it serverlessly, puts it to sleep when id…”
   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”

   proof ↗⚑ flag

Scale

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

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

   Maritime—none0/10

   No evidence of documented concurrency limits or guidance for running large fleets of sandboxes at scale; docs cover provisioning, idempotency, and billing per-agent but never state concurrency ceilings, throughput benchmarks, or fleet-scale operational guidance.

   ⚑ flag

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

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

   Maritime~partialprobed5/10

   Maritime advertises serverless infra by default with an 'always-on' add-on for agents that must run continuously, and a persistent Linux desktop model for end users, suggesting long-lived sessions are possible but only via a paid add-on rather than a default guarantee for hours/days-long sandbox sessions. missing for 10: explicit documentation of session/session-timeout limits, confirmation that a sandbox session can run unattended for hours or days without the always-on add-on, and independent verification of long-running task stability.

   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”
   • [claimed-docs] “A persistent Linux desktop (XFCE, Chromium, LibreOffice) for each of _your_ end users, driven by _your_ model.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://maritime.sh/llms.txt # Maritime > Maritime is a cloud platform for deploying, hosting, and managing AI …”

   proof ↗⚑ flag

Pricing

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

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

   Maritime✓fullclaimed8/10

   Docs explicitly state the free plan includes 3 agents with no card required, and quickstart/CLI docs show a self-serve path (npm install, deploy in under 5 minutes) with no sales contact implied anywhere. missing for 10: independent/third-party confirmation of the free tier's real-world limits and no hands-on verification of the signup flow.

   • [claimed-docs] “the free plan includes 3 agents, no card required”
   • [claimed-docs] “Deploy your first agent and talk to it, in under 5 minutes.”
   • [claimed-docs] “npm install -g maritime-cli”
   • [claimed-docs] “One subscription, a set number of agents, flat prices for extras. No meters, no hourly rates: how much your agents run never changes the bil…”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   Maritime's own billing docs explicitly state the opposite of per-second usage billing: 'One subscription, a set number of agents, flat prices for extras. No meters, no hourly rates: how much your agents run never changes the bill' and 'Always-on is a flat add-on.' There is no evidence of any per-second or usage-metered compute pricing for sandboxes.

   • [claimed-docs] “One subscription, a set number of agents, flat prices for extras. No meters, no hourly rates: how much your agents run never changes the bil…”
   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”

   proof ↗⚑ flag

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

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

   Maritime—none0/10

   No evidence in the pack mentions data residency, region selection, or geographic storage controls anywhere in Maritime's docs or probes; nothing addresses where agent/user data is physically stored.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Blaxel—none0/10

   No evidence pack item addresses data usage for AI model training, opt-out policies, or privacy commitments regarding training data; this is an infrastructure/agent-hosting product where such a policy could exist but is undocumented here. Missing for 10: any privacy policy or ToS statement on training data usage, opt-out mechanism, or data retention controls.

   ⚑ flag

   Maritime—none0/10

   No evidence in the pack addresses data-training opt-out or AI model training policies for Maritime; the docs cover deployment, hosting, keys, CLI, etc., but nothing about preventing customer data from being used to train AI models.

   ⚑ flag

3. ai-native userControl data retention and deletion

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

   Maritime—none0/10

   No evidence describes data retention policies, deletion controls, or export/purge mechanisms for agent data, files, or session logs; docs mention encrypted-at-rest secrets and append-only session logs but nothing about user-controlled retention or deletion.

   ⚑ flag

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

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

   Maritime—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics collection, or an opt-out mechanism anywhere in Maritime's docs; the closest topics (scoped API keys, secret variables) address access control, not telemetry preferences.

   ⚑ flag

Lifecycle

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

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

   Maritime—none0/10

   The docs describe Maritime as serverless agent hosting and mention an 'always-on' paid add-on (implying default agents are not always running), but no evidence describes a developer-configurable idle timeout or automatic shutdown-to-stop-billing mechanism. Missing for 10: any documented timeout setting, idle-detection policy, or billing-pause behavior tied to inactivity.

   • [claimed-docs] “Always-on is a flat add-on for the rare agent that must react in milliseconds around the clock.”

   proof ↗⚑ flag

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

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

   Maritime✓fullprobed7/10

   Maritime's SDK exposes an idempotent `provision` call that creates/returns a live agent environment, and docs claim full agent deployment (image pull → live, chat-ready) in under 5 minutes, with CLI/API equivalents (`maritime keys create`, RESTful API). This matches the 'one call, live environment fast' story well, though the fastest documented time is minutes not literal seconds and there's no independent/hands-on latency benchmark or public OpenAPI spec confirming the exact call shape. Missing for 10: independent timing/benchmark evidence corroborating 'seconds', and a verifiable OpenAPI/API schema (probe shows openapi.json 404).

   • [claimed-docs] “Tag each agent with your own id via `externalId`. `provision` is **idempotent** on it: it returns the existing agent if there is one, else c…”
   • [claimed-docs] “provision is idempotent on it: it returns the existing agent if there is one, else creates a new one. Safe to call on every sign-in.”
   • [claimed-docs] “Deploy your first agent and talk to it, in under 5 minutes.”
   • [claimed-docs] “Every ready-made template is a real agent framework, pre-configured and one image pull from live. Pick one, name it, deploy.”
   • [claimed-docs] “RESTful API for managing agents programmatically.”
   • [claimed-docs] “The Maritime CLI lets you deploy and manage agents from your terminal.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://maritime.sh/openapi.json, https://maritime.sh/swagger.json, https://maritime.sh/api/openapi.…”

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

   Maritime~partialclaimed6/10

   Maritime's docs describe deploying any Dockerfile-based repo to a public, no-login HTTPS URL that reaches the running container's service, matching the core story of exposing an internal service via a public preview URL (maritime-docs-29, maritime-docs-47). However, the docs never explicitly describe port-selection mechanics (e.g., multiple ports, custom port binding) and all evidence is first-party with no independent/hands-on corroboration. missing for 10: explicit port-selection/multi-port docs, independent verification that the public URL reaches an arbitrary internal port.

   • [claimed-docs] “Any repo with a Dockerfile can be served on a public, no-login HTTPS URL. Maritime builds it, runs it serverlessly, puts it to sleep when id…”
   • [claimed-docs] “Any repo with a Dockerfile can be served on a public, no-login HTTPS URL.”

   proof ↗⚑ flag

Snapshots

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

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

   Maritime—none0/10

   No evidence in the pack mentions pausing/suspending a sandbox or preserving filesystem and memory state across a pause/resume cycle; docs cover provisioning, webhooks, triggers, templates, and CLI/API auth but nothing about snapshot or suspend-resume persistence.

   ⚑ flag

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

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

   Maritime—none0/10

   No evidence in the pack mentions snapshotting a sandbox/agent state or restoring/forking new instances from such a snapshot; templates (maritime-docs-7) allow cloning a pre-configured agent package but not capturing/restoring runtime state.

   ⚑ flag