Runpod vs Vast.ai

Ide

1. developerOpen Jupyter or connect my IDE (VS Code/Cursor) to the instance in one step

   weight 1 · round to Runpod
   Runpod✓fullcommunity8/10

   Docs explicitly state Pods can be connected via SSH, JupyterLab, or VS Code/Cursor for local IDE integration, and templates pre-configure PyTorch/JupyterLab so everything is 'ready instantly' without manual setup. Community evidence corroborates ease of use (template-based one-click deploys) though notes the execution environment is 'locked down,' a minor friction point for advanced tooling. Missing for 10: independent hands-on confirmation of the actual one-step VS Code/Cursor connect experience beyond vendor docs.

   • [claimed-docs] “Once deployed, you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data scie…”
   • [claimed-docs] “you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data science workflows, …”
   • [claimed-docs] “Access your Pod via SSH, JupyterLab, or VS Code.”
   • [claimed-docs] “Instead of installing PyTorch, configuring JupyterLab, and setting up dependencies yourself, you can select a template and have everything r…”
   • [claimed-docs] “Instead of installing PyTorch, configuring JupyterLab, and setting up all dependencies yourself, you can select an official Runpod PyTorch t…”
   • [community] “Regarding Colab local runtimes: 'The above might not work with runpod, since their execution environment is locked down. However it works wi…”
   • [community] “Comparing to Azure: 'They seem more complicated to manage... With Runpod and Vast.ai, I can simply use TheBloke's templates in a few clicks.…”

   proof ↗⚑ flag

   Vast.ai~partialclaimed5/10

   Vast.ai documents secure SSH access to instances (key-based auth, run commands, transfer files) and one-click template launches that could include Jupyter environments, which together enable IDE remote-connection workflows (e.g., VS Code Remote-SSH). However, the evidence never explicitly names Jupyter notebook access or a documented one-step VS Code/Cursor connection flow. Missing for 10: explicit Jupyter launch/access docs, explicit VS Code/Cursor remote-connect guide or extension support, and any hands-on confirmation of a true 'one step' connect experience.

   • [claimed-docs] “Vast.ai instances are configured to accept keys only - Password authentication is disabled for improved security.”
   • [claimed-docs] “Log in securely, Run commands remotely, Transfer files without exposing your data”
   • [claimed-docs] “SSH (Secure Shell) is a protocol for safely connecting to remote servers. It encrypts your connection so you can: Log in securely, Run comma…”
   • [claimed-docs] “Launch prebuilt or custom templates with one click.”
   • [claimed-docs] “A template is how Vast helps you launch an instance, setting up your rented machine with whatever software and formatting you need.”
   • [claimed-docs] “Build a template - Package your environment so any GPU can run it with one click.”

   proof ↗⚑ flag

Networking

1. developerExpose ports to serve applications from my instance and connect instances over private networking

   weight 1 · round drawn
   Runpod✓fullclaimed7/10

   Runpod docs describe exposing ports via 'web proxy for exposed web services' on Pods (runpod-docs-14/45) alongside SSH/JupyterLab/VS Code access, and Instant Clusters provide 'high-performance networking for distributed workloads' enabling multi-node/private networking between instances (runpod-docs-4/17/37/48). Missing for 10: independent hands-on verification of port-exposure and inter-instance private networking, and more detail on how private networking is configured/secured beyond the Instant Clusters feature blurb.

   • [claimed-docs] “Once deployed, you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data scie…”
   • [claimed-docs] “you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data science workflows, …”
   • [claimed-docs] “Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed workloads.”
   • [claimed-docs] “Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed workloads. Deploy jobs or large-s…”
   • [claimed-docs] “Deploy jobs or large-scale without managing infrastructure, networking, or cluster configuration.”
   • [claimed-docs] “Train models too large for one GPU, or accelerate training across multiple nodes.”

   proof ↗⚑ flag

   Vast.ai✓fullclaimed7/10

   Docs explicitly describe exposing ports (search filter `direct_port_count>=1`, SSH access) and creating private overlay networks so instances on different machines can share a virtual LAN for multi-node workloads, directly matching both halves of the story. Missing for 10: independent/hands-on confirmation of port-forwarding for arbitrary web apps beyond SSH, and more detail on overlay network setup/limitations.

   • [claimed-docs] “Vast now supports creating *overlay* networks for instances, allowing client instances on different machines on the same physical LAN to sha…”
   • [claimed-docs] “Vast now supports creating overlay networks for instances, allowing client instances on different machines on the same physical LAN to share…”
   • [claimed-docs] “vastai search offers 'gpu_name=RTX_4090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'”
   • [claimed-docs] “Vast.ai instances are configured to accept keys only - Password authentication is disabled for improved security.”
   • [claimed-docs] “SSH (Secure Shell) is a protocol for safely connecting to remote servers. It encrypts your connection so you can: Log in securely, Run comma…”

   proof ↗⚑ flag

Ssh

1. developerSSH into my GPU instance with my own keys and get root-level control of the environment

   weight 3 · round to Runpod
   Runpod✓fullcommunity7/10

   Runpod's docs explicitly describe SSH access to Pods with 'full shell capabilities' and list SSH among the standard connection methods (console, CLI, or agent-deployed Pods), matching the developer's need for root-level shell control over their GPU instance. Community commentary references SSH as a viable, sometimes primary, access method for Runpod Pods, and doesn't concretely contradict SSH working or granting shell access — it instead notes the execution environment is otherwise locked down, which is orthogonal. Missing for 10: explicit documentation excerpt describing the own-key upload/configuration step and independent hands-on confirmation of root-level privileges once inside.

   • [claimed-docs] “SSH provides secure, reliable access to your Pod for long-running processes and full shell capabilities.”
   • [claimed-docs] “Once deployed, you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data scie…”
   • [claimed-docs] “Access your Pod via SSH, JupyterLab, or VS Code.”
   • [claimed-docs] “you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data science workflows, …”
   • [community] “'Their execution environment is very locked down, which might make ssh the only option' when discussing using OpenZiti with Runpod.”

   proof ↗⚑ flag

   Vast.ai~partialclaimed6/10

   Docs confirm SSH access is key-based only (password auth disabled) and lets you log in securely, run commands remotely, and transfer files, which implies developer control of the instance. However, the evidence pack never explicitly confirms root-level privileges or documents the workflow for adding a user's own SSH key. Missing for 10: explicit documentation of root/sudo access inside instances, and details on uploading/managing your own SSH keys.

   • [claimed-docs] “Vast.ai instances are configured to accept keys only - Password authentication is disabled for improved security.”
   • [claimed-docs] “Log in securely, Run commands remotely, Transfer files without exposing your data”
   • [claimed-docs] “SSH (Secure Shell) is a protocol for safely connecting to remote servers. It encrypts your connection so you can: Log in securely, Run comma…”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   Runpod✓fullprobed9/10

   Runpod hosts a live llms.txt at docs.runpod.io/llms.txt (HTTP 200, confirmed via probe) plus agent-oriented docs like MCP server guides and an agent-skills plugin, and the docs MCP server was verified to complete a full keyless handshake, confirming agent-reachability of documentation. Missing for 10: no independent/community corroboration of llms.txt usage by real agents outside the vendor probe.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.runpod.io/llms.txt # Runpod Documentation > Developer documentation for building, deploying, and s…”
   • [claimed-docs] “Runpod provides two Model Context Protocol (MCP) servers that connect AI tools and coding agents directly to Runpod”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.runpod.io/mcp completed a FULL keyless JSON-RPC …”
   • [claimed-docs] “Once installed, you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all …”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai publishes a live llms.txt at docs.vast.ai/llms.txt (confirmed via probe returning HTTP 200 with structured doc links) and additionally ships an explicit agent-oriented guide/skill ('vastai agent skill') documenting how AI coding assistants can drive the platform directly. This directly satisfies pointing an agent at llms.txt or agent-oriented docs. Missing for 10: no independent/community corroboration of agents actually consuming llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.vast.ai/llms.txt # Vast.ai Documentation: Affordable GPU Cloud Marketplace - [Welcome](https://doc…”
   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Runpod✓fullprobed8/10

   Runpod ships both a scriptable open-source CLI (runpodctl) and a REST API explicitly positioned for 'integrating GPU infrastructure into your applications, workflows, and automation systems,' and runtime probes confirm both work keylessly/API-key-gated exactly as documented (CLI version check succeeded, REST API openapi.json served, /v1/pods correctly 401s without a key) — i.e., headless automation is real and verified, not just a claim. Missing for 10: an explicit CI pipeline example/tutorial (e.g., GitHub Actions) and independent third-party confirmation of CI usage beyond the vendor's own runtime probe.

   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine.”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [claimed-docs] “Create, start, stop, and terminate Pods using the Runpod console or CLI.”

   proof ↗⚑ flag

   Vast.ai✓fullprobed8/10

   Vast.ai offers a full CLI and REST API for scriptable, non-interactive control of the entire instance lifecycle (search, create, destroy), confirmed by both docs and hands-on runtime probes running keylessly. Scoped API keys are explicitly recommended for CI/CD and shared tooling, and the CLI was verified to run headlessly via uvx with no login. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions workflow) or third-party case study of running it in an automated CI pipeline.

   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “You can also create scoped keys with limited permissions using `vastai create api-key`, useful for CI/CD or shared tooling.”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

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

   weight 3 · round to Runpod
   Runpod✓fullprobed9/10

   Runpod documents two official MCP servers (API MCP and docs MCP) that connect AI tools/coding agents to Runpod, and runtime probes confirm both are live: the docs MCP completes a full keyless handshake, and the API MCP correctly enforces the documented OAuth flow. This is Runpod acting as a service provider exposing an MCP server, not an agent client, so the axis clearly applies and is delivered with first-party docs plus independent runtime verification. Missing for 10: no third-party/community usage reports of agents actually connecting via these MCP servers in practice.

   • [claimed-docs] “Runpod provides two Model Context Protocol (MCP) servers that connect AI tools and coding agents directly to Runpod”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “official MCP server documented at https://docs.runpod.io/get-started/mcp-servers”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted API MCP server https://mcp.getrunpod.io/ returned HTTP 4…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.runpod.io/mcp completed a FULL keyless JSON-RPC …”

   proof ↗⚑ flag

   Vast.ai—none0/10

   Vast.ai documents a CLI, REST API, Python SDK, and an 'agent skill' file for coding assistants, but no evidence anywhere describes an official MCP server or MCP integration. Since Vast.ai is a platform/service (not itself an agent), the MCP-server axis applies, and its absence from the evidence pack means the story is unmet.

   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Runpod✓fullprobed9/10

   Runpod ships an official open-source CLI (runpodctl) documented for managing pods, serverless endpoints, templates, volumes, and models, and this was independently verified working at runtime (installed via brew, ran keylessly, version and help output confirmed). This is a strong, corroborated case of an official CLI supporting agentic/AI-native workflows (e.g., 'Run Python functions on remote GPUs directly from your local terminal'). Missing for 10: no deeper hands-on exploration of advanced CLI subcommands or agent-specific CLI usage beyond the smoke test.

   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine.”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [probe] “official CLI documented at https://docs.runpod.io/runpodctl/overview”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”
   • [claimed-docs] “Run Python functions on remote GPUs directly from your local terminal.”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai ships an official CLI (pypi `vastai`) with full documentation of the entire platform surface (search, instances, templates, volumes, serverless), and runtime probes confirm it installs and works keylessly for real marketplace queries. Missing for 10: independent third-party reviews specifically praising/critiquing the CLI's UX beyond vendor docs and probes.

   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “vastai search offers 'gpu_name=RTX_4090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [probe] “official CLI documented at https://docs.vast.ai/cli/hello-world”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Runpod✓fullprobed9/10

   Runpod documents and exposes a public REST API (v1) covering pods, endpoints, templates, volumes, and registries, with a live OpenAPI spec confirmed at runtime and proper API-key gating, plus CLI, MCP servers, and S3-compatible storage API as complementary programmatic surfaces. Runtime probes independently corroborate the documented REST API and MCP endpoints are actually live and functioning as described. Missing for 10: no independent third-party review of API completeness/versioning stability beyond docs and probes.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.runpod.io/openapi.json, https://docs.runpod.io/swagger.json, https://docs.runpod.io/api…”
   • [claimed-docs] “Runpod provides an S3-protocol compatible API for direct access to your network volumes. This allows you to manage files on your network vol…”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai publishes a documented REST API (with live OpenAPI spec) and CLI/SDK built on top of it, explicitly positioned for programmatic/agentic use, including scoped API keys for automation and a dedicated 'agent skill' for AI coding assistants. Runtime probes confirm the CLI and REST endpoints work keylessly for core operations like search/create/destroy instances, corroborating the documentation with hands-on evidence. Missing for 10: independent third-party developer reports specifically about API robustness/rate limits beyond docs and probes.

   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform.”
   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “create a scoped key with only the permissions that workload needs”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

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

   weight 2 · round to Vast.ai
   Runpod—none0/10

   Runpod documents API-key and OAuth ("Sign in with Runpod") authentication for its REST API and MCP servers, but no evidence describes scoped, role-based, or least-privilege API key creation (e.g., read-only or resource-limited keys) that a user could issue specifically for an agent.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted API MCP server https://mcp.getrunpod.io/ returned HTTP 4…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”

   proof ↗⚑ flag

   Vast.ai✓fullclaimed8/10

   Docs explicitly describe creating scoped API keys with limited permissions for workloads/CI-CD/shared tooling via `vastai create api-key`, directly matching least-privilege agent credentialing, and this is reinforced by a dedicated api-keys reference page and the agent-skill docs describing agent-driven usage. Missing for 10: independent/hands-on verification of scope enforcement (e.g., testing that a scoped key actually blocks restricted actions) and detail on the granularity of available scopes.

   • [claimed-docs] “You can also create scoped keys with limited permissions using `vastai create api-key`, useful for CI/CD or shared tooling.”
   • [claimed-docs] “create a scoped key with only the permissions that workload needs”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”
   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Vast.ai
   Runpod~partialprobed5/10

   Runpod documents a REST API (runpod-docs-8/26, runpod-probe-rt-4), an open-source CLI (runpod-docs-5/16/32), and a Python-function-on-remote-GPU capability (runpod-docs-15) that implies an SDK-like interface, giving AI-native builders programmatic access. However the evidence pack never explicitly names or links a dedicated 'official SDK' page (e.g., a Python/JS client library reference) distinct from the CLI/REST API, so SDK-specific documentation depth is unverified. Missing for 10: dedicated official SDK docs/reference pages, multi-language SDK coverage, and independent developer confirmation of SDK usage.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [claimed-docs] “Run Python functions on remote GPUs directly from your local terminal.”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine.”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai documents an official Python SDK (built alongside CLI) and REST API with OpenAPI spec, a documented migration path from the legacy vastai_sdk package, and runtime-probed confirmation that the CLI/SDK surface works live against the marketplace API. Documentation explicitly frames CLI/SDK as 'same operations, different syntax' with Python usage examples for serverless workflows, satisfying an AI-native builder's need for official SDK access. Missing for 10: independent (non-vendor) hands-on reports specifically validating the Python SDK's completeness/stability beyond CLI parity.

   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [claimed-docs] “Interacting with Vast Serverless is made easy through a powerful python SDK.”
   • [github] “Migrating from vastai-sdk? The old import still works: from vastai_sdk import VastAI”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Runpod—none0/10

   No evidence of webhook subscription/event notification support anywhere in the docs pack — Runpod offers REST API, CLI, MCP servers, and SSH access, but nothing about outbound event webhooks for job/pod status changes.

   ⚑ flag

   Vast.ai—none0/10

   No evidence of a webhook subscription mechanism anywhere in the docs, CLI, API reference, or probes; Vast.ai exposes REST API, CLI, and SDK for polling/imperative control but nothing describing event-driven push notifications or webhook callbacks. missing for 10: any documentation of webhook registration/endpoints, event types, or delivery/retry semantics.

   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Vast.ai
   Runpod~partialprobed4/10

   Runpod's Serverless endpoints scale workers autonomously (scale-to-zero, pay-per-second) and the REST API/CLI/MCP servers explicitly target integration into 'applications, workflows, and automation systems,' letting a user wire up background GPU jobs. However there's no dedicated scheduler, trigger/cron mechanism, or first-party 'automation' product documented—users would need to build the automation logic themselves on top of the API/Serverless primitives. Missing for 10: a built-in scheduling/trigger system, evidence of persistent background agent workflows (not just on-demand endpoints), and any hands-on report of an autonomous automation actually running unattended.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to …”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate | Variable workloads, cost optimization”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs.”
   • [claimed-docs] “Once installed, you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all …”
   • [claimed-docs] “you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all in natural langu…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”

   proof ↗⚑ flag

   Vast.ai~partialprobed5/10

   Vast.ai exposes a CLI/SDK/REST API, scoped API keys for CI/CD, and an 'agent skill' letting AI coding assistants drive the platform (create instances, deploy endpoints, manage keys) — all usable to script automations, and Serverless endpoints let workloads run without manual GPU management. However, there is no evidence of a built-in scheduler, cron/trigger system, or persistent background job orchestration that runs autonomously without an external driver; automation depends on the user's own agent/script staying alive. Missing for 10: native scheduling/trigger mechanism, evidence of long-running autonomous background jobs, and independent confirmation of the agent-skill working unattended in production.

   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “You can also create scoped keys with limited permissions using `vastai create api-key`, useful for CI/CD or shared tooling.”
   • [claimed-docs] “create a scoped key with only the permissions that workload needs”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”
   • [claimed-docs] “Vast Serverless is an AI infrastructure platform that lets you run compute-intensive workloads without managing GPUs, paying for execution r…”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”

   proof ↗⚑ flag

2. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Runpod—none0/10

   Runpod's evidence describes MCP servers and 'agent skills' that let EXTERNAL coding agents (Claude, Cursor, etc.) control Runpod resources — the reverse of an assistant built into Runpod's own product for users to delegate tasks to. There is no mention of a native chat/assistant surface inside the Runpod console or CLI itself.

   • [claimed-docs] “Runpod provides two Model Context Protocol (MCP) servers that connect AI tools and coding agents directly to Runpod”
   • [claimed-docs] “Once installed, you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all …”
   • [claimed-docs] “you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all in natural langu…”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “official MCP server documented at https://docs.runpod.io/get-started/mcp-servers”

   proof ↗⚑ flag

   Vast.ai—none0/10

   Evidence only shows the reverse relationship: Vast.ai exposes a CLI/API/agent-skill so that external AI coding assistants (e.g., Claude, Copilot) can drive Vast.ai on the user's behalf — not that Vast.ai itself ships a built-in AI assistant a user can delegate tasks to within the product. No docs, UI, or probes mention any native chatbot/copilot embedded in the Vast.ai console.

   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”

   proof ↗⚑ flag

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

   weight 2 · round to Runpod
   Runpod✓fullprobed8/10

   Runpod ships an agent-skills plugin and MCP servers explicitly designed so users can ask their AI agent in natural language to create Pods, deploy Serverless endpoints, transfer files, or deploy code, backed by a live hosted MCP server and API confirmed via runtime probes. This is a first-party, agent-native workflow rather than just CLI/API access repurposed for agents. Missing for 10: independent (non-vendor) hands-on confirmation that the natural-language agent-skills workflow works end-to-end as described.

   • [claimed-docs] “Once installed, you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all …”
   • [claimed-docs] “you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all in natural langu…”
   • [claimed-docs] “Runpod provides two Model Context Protocol (MCP) servers that connect AI tools and coding agents directly to Runpod”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “official MCP server documented at https://docs.runpod.io/get-started/mcp-servers”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted API MCP server https://mcp.getrunpod.io/ returned HTTP 4…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.runpod.io/mcp completed a FULL keyless JSON-RPC …”

   proof ↗⚑ flag

   Vast.ai✓fullprobed7/10

   Vast.ai documents a dedicated 'vastai agent skill' explicitly designed so AI coding assistants can drive the platform on the user's behalf (create instances, deploy endpoints, manage keys, check balances) via natural-language-style interaction, backed by a full CLI/REST API surface. Missing for 10: independent or hands-on verification of the natural-language agent-skill flow itself (probes only confirm raw CLI/REST access, not NL interpretation), and no third-party account of an AI agent successfully using it end-to-end.

   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Runpod
   Runpod~partialprobed5/10

   Runpod documents a full REST API reference (runpod-docs-8, runpod-docs-26) and a probe confirms the OpenAPI spec is live and served at rest.runpod.io/v1/openapi.json (runpod-probe-rt-4), which is the backbone for an interactive reference. However, there is no direct evidence of a 'try it now' interactive console or embedded runnable code examples within the docs UI itself—only the raw spec and static markdown pages are confirmed. Missing for 10: evidence of an interactive Swagger/Redoc-style try-it-out console, runnable code snippets embedded in the docs, and confirmation that the OpenAPI spec is surfaced in the actual docs site rather than only at a separate API host.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.runpod.io/openapi.json, https://docs.runpod.io/swagger.json, https://docs.runpod.io/api…”

   proof ↗⚑ flag

   Vast.ai~partialprobed4/10

   Vast.ai publishes a machine-readable OpenAPI spec and API-reference docs, and the CLI docs include copy-pasteable, runnable example commands that were verified to work live (search offers, create instance) without auth — showing some 'runnable example' quality. However there is no evidence of an interactive API console (e.g., embedded 'try it' Swagger-UI style playground) on the docs site itself. Missing for 10: an interactive in-browser API explorer/console, explicit 'try it now' runnable request execution within the API reference pages, and independent confirmation of such interactivity.

   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Runpod✓fullprobed9/10

   Runpod documents a REST API v1 and a probe confirms the OpenAPI spec is actually served keylessly at https://rest.runpod.io/v1/openapi.json, matching the documented API. Missing for 10: no first-party download link/documentation explicitly advertising the OpenAPI spec location on the docs site itself (probe found it via the raw REST host, not linked from docs directly).

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.runpod.io/openapi.json, https://docs.runpod.io/swagger.json, https://docs.runpod.io/api…”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai publishes a live OpenAPI spec at docs.vast.ai/api/openapi.json (verified HTTP 200 with an 'openapi' key), backed by a full REST API reference and CLI/SDK built on it. Missing for 10: no independent third-party confirmation that the spec is comprehensive/kept in sync beyond the probe check.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform.”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Runpod—none0/10

   Runpod documents a versioned REST API (v1) with a live OpenAPI spec, but no evidence in the pack describes any deprecation policy, versioning changelog, or migration/support-window commitments for API versions — only a `/runpod:migrate rest` agent command is mentioned, which is a migration tool, not a policy.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [claimed-docs] “To migrate automatically, ask your coding agent to run `/runpod:migrate rest` once you've installed the Runpod skills plugin.”

   proof ↗⚑ flag

   Vast.ai—none0/10

   Evidence shows Vast.ai has a REST API, OpenAPI spec, and CLI/SDK, but there is no documentation of API versioning scheme or a deprecation policy anywhere in the pack; the only related signal is a backward-compatible import shim for the old SDK (vast-ai-gh-2), which is not a documented policy.

   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [github] “Migrating from vastai-sdk? The old import still works: from vastai_sdk import VastAI”

   proof ↗⚑ flag

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

   weight 2 · round to Vast.ai
   Runpod—none0/10

   Runpod's docs describe CLI/API/MCP access for managing individual Pods, endpoints, templates, and volumes, and a general-purpose REST API that could in principle be scripted for bulk actions, but there is no documented bulk/batch operation feature (e.g., batch-create/delete many pods or jobs in one call) or evidence of such usage in practice.

   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Create, start, stop, and terminate Pods using the Runpod console or CLI.”

   proof ↗⚑ flag

   Vast.ai~partialprobed6/10

   The CLI and REST API expose full programmatic control (search, create, destroy, manage keys) and are explicitly positioned for automation/scripting from shell or Python, which lets an AI-native user loop over many offers/instances (e.g., filtered searches returning many GPU offers at once). However, there is no documented native batch/bulk endpoint (e.g., one call to create or destroy N instances simultaneously) — only single-item CRUD operations that must be scripted in a loop. Missing for 10: explicit bulk/batch API endpoints or CLI flags for multi-item operations, and community/hands-on confirmation of bulk usage at scale.

   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [github] “vast.search_offers(query='gpu_name=RTX_4090 num_gpus>=4')”
   • [claimed-docs] “vastai search offers 'gpu_name=RTX_4090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”

   proof ↗⚑ flag

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

   weight 3 · round to Vast.ai
   Runpod—none0/10

   Evidence shows only a single fixed automatic behavior (auto-pay reloading balance below a threshold) and autoscaling to zero, neither of which constitutes a user-definable rules/event-trigger system. No documentation shows webhooks, event subscriptions, or a general 'if X then Y' automation engine for Runpod resources.

   • [claimed-docs] “Auto-pay automatically reloads your account balance when it falls below a threshold, helping you avoid service interruptions from low funds.”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate | Variable workloads, cost optimization”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate”

   proof ↗⚑ flag

   Vast.ai~partialclaimed4/10

   Vast.ai documents 'autobilling', an explicit event-triggered rule (balance drops low → auto top-up from saved card), which is genuine automation-on-event. Beyond that, evidence only shows generic CLI/SDK/API scripting and agent-skill hooks for manual automation, not a broader rules/trigger engine (no webhooks, alerts, or conditional actions for instance events like preemption, cost thresholds, or health failures). Missing for 10: a general-purpose event/trigger system (webhooks, alerting, conditional rules) beyond the single billing use case, and independent confirmation of its reliability.

   • [claimed-docs] “Use the autobilling feature to have the system automatically top up your account using a saved credit card when it runs low.”
   • [claimed-docs] “Autobilling keeps your balance positive to protect your instances from interruption or deletion.”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Runpod—none0/10

   The evidence pack documents Pods, Serverless endpoints, Instant Clusters, CLI, API, and MCP servers, but nowhere describes a scheduler, cron-like recurring job feature, or workflow orchestration capability for automatically re-running jobs on a schedule. Users could manually trigger jobs via API/CLI, but no evidence shows a built-in recurring/scheduled job mechanism.

   ⚑ flag

   Vast.ai—none0/10

   Vast.ai's evidence covers CLI/API/SDK for instance and serverless management but contains no mention of a built-in scheduler, cron-like recurring job feature, or workflow orchestration; users would have to bring their own external scheduler to hit the API/CLI repeatedly, which isn't documented as a first-party capability.

   ⚑ flag

Availability

1. ml engineerSee real-time GPU availability by type and region before I try to provision, instead of discovering stockouts by failure

   weight 2 · round to Vast.ai
   Runpod—none0/10

   No evidence pack item describes a real-time GPU-availability-by-region/type dashboard or API that lets an ML engineer check stock before provisioning. The only related community evidence (runpod-comm-4) describes the opposite: users only learn of 'low availability' via failed/incomplete deploys, i.e. discovering stockouts by failure rather than checking ahead of time.

   • [community] “"Runpod used to have high availability of 4090 GPUs just about a month ago, but it seems like something has happened that has made almost al…”
   • [claimed-docs] “Thousands of GPUs across 30+ regions. Simple pricing plans for teams of all sizes, designed to scale with you.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions.”

   proof ↗⚑ flag

   Vast.ai✓fullprobed8/10

   Vast.ai's search/offers API and CLI let engineers query live marketplace inventory (GPU type, count, verified status, price) before renting, and this was independently confirmed via a keyless live probe against both the CLI and the public REST bundles endpoint returning real-time offers with reliability data. This directly satisfies seeing availability before provisioning rather than hitting a stockout on create. missing for 10: explicit region/geolocation filter documentation and evidence of real-time refresh/alerting for capacity changes.

   • [claimed-docs] “vastai search offers 'gpu_name=RTX_4090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'”
   • [claimed-docs] “The search page is the main portal for finding good machines and creating instances on them.”
   • [github] “vast.search_offers(query='gpu_name=RTX_4090 num_gpus>=4')”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

Hardware

1. ml engineerChoose from current-generation datacenter GPUs (H100/H200/B200 class) as well as cheaper previous-generation options

   weight 2 · round to Vast.ai
   Runpod~partialcommunity4/10

   Evidence confirms Runpod offers current-gen H100 GPUs and previous-gen (4090) GPUs via community reports, and docs claim 'thousands of GPUs across 30+ regions,' but there is no docs page or listing enumerating the specific GPU classes (H100/H200/B200) or older-gen tiers, and one report notes a period of 4090 unavailability. missing for 10: an explicit GPU catalog/pricing page listing H100/H200/B200 vs older-gen options, docs confirming H200/B200 support, and evidence of consistent availability across tiers.

   • [community] “On Colab vs Moonglow: 'even Colab Pro doesn't offer H100s, whereas you can get that pretty easily on Runpod.'”
   • [community] “"Runpod used to have high availability of 4090 GPUs just about a month ago, but it seems like something has happened that has made almost al…”
   • [claimed-docs] “Thousands of GPUs across 30+ regions. Simple pricing plans for teams of all sizes, designed to scale with you.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions.”

   proof ↗⚑ flag

   Vast.ai~partialprobed5/10

   Vast.ai's docs and CLI clearly support searching/filtering the marketplace by GPU model (e.g., `gpu_name=RTX_4090`) and offer tiered pricing (on-demand, reserved, interruptible) that would let an ML engineer pick pricier or cheaper GPU options, and 'Secure Cloud (Datacenter)' verification implies access to datacenter-grade hardware. However, none of the evidence explicitly confirms availability of current-generation H100/H200/B200-class GPUs alongside older cards — all concrete examples in the pack use RTX_4090 (a consumer card), not datacenter-tier flagship GPUs. Missing for 10: explicit documentation or listing showing H100/H200/B200 GPUs are actually rentable on the platform alongside cheaper previous-gen options.

   • [github] “vast.search_offers(query='gpu_name=RTX_4090 num_gpus>=4')”
   • [claimed-docs] “vastai search offers 'gpu_name=RTX_4090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'”
   • [claimed-docs] “Secure Cloud (Datacenter): These machines are verified and confirmed to be in a certified datacenter that meets our datacenter criteria.”
   • [claimed-docs] “Vast verifies that these machines are in a datacenter with a TIER 2/3 rating or ISO 27001. These offer cards have a blue label and are recom…”
   • [claimed-docs] “Reserved instances allow you to get significant discounts (up to 50%) by pre-paying for GPU time. You can convert any on-demand instance to …”
   • [claimed-docs] “Interruptible instances use a bidding system: **Lowest cost** (often 50%+ cheaper than on-demand)”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”

   proof ↗⚑ flag

Quotas

1. platform engineerSee documented quotas and instance limits and raise them through a defined process

   weight 2 · round drawn
   Runpod—none0/10

   There is community evidence of GPU availability constraints (low availability messages for 4090s) but no documented quota/limit structure or a defined process to request quota increases anywhere in the docs pack. Absence of evidence for an applicable capability (documented limits and escalation process) means this axis is unmet.

   • [community] “"Runpod used to have high availability of 4090 GPUs just about a month ago, but it seems like something has happened that has made almost al…”

   proof ↗⚑ flag

   Vast.ai—none0/10

   The evidence pack covers billing, autobilling, reserved/interruptible instance pricing, API keys, and CLI/SDK usage, but contains no documentation of account quotas, per-user instance limits, or a defined process to request limit increases. This axis is applicable to any capacity-oriented GPU marketplace, so absence of evidence yields 'none'. Missing for 10: documented quota/limit tables, a support/ticket process for raising limits, any mention of default instance caps or how to request more capacity.

   ⚑ flag

Clusters

1. ml engineerProvision a multi-node GPU cluster with fast interconnect for distributed training without a sales cycle

   weight 3 · round to Runpod
   Runpod✓fullclaimed7/10

   Runpod documents Instant Clusters as fully managed multi-node compute with high-performance networking for distributed training, deployable without managing infrastructure/networking/cluster configuration, and explicitly targets training models too large for one GPU or accelerating training across multiple nodes — all self-service via console/API/CLI without a sales process. Missing for 10: no independent/hands-on benchmark of actual interconnect performance (e.g., InfiniBand/NVLink specifics or bandwidth numbers) and no community corroboration of successfully running a multi-node cluster end-to-end.

   • [claimed-docs] “Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed workloads.”
   • [claimed-docs] “Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed workloads. Deploy jobs or large-s…”
   • [claimed-docs] “Deploy jobs or large-scale without managing infrastructure, networking, or cluster configuration.”
   • [claimed-docs] “Train models too large for one GPU, or accelerate training across multiple nodes.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions. Simple pricing plans for teams of all sizes, designed to scale with you.”

   proof ↗⚑ flag

   Vast.ai!disputedcontradicted5/10

   Docs describe self-service, no-sales-cycle provisioning (CLI/API/search offers for multi-GPU nodes) and an overlay-network feature specifically for multi-node NCCL/PyTorch training, which addresses the 'no sales cycle' and 'multi-node' parts of the story. However, independent hands-on reports describe bandwidth as 'lousy' and 'all over the place compared to what's listed in the console,' directly undercutting the 'fast interconnect' claim needed for distributed training performance. Missing for 10: documented interconnect specs (e.g. InfiniBand/NVLink bandwidth guarantees), benchmarked multi-node throughput, and independent confirmation that overlay networking delivers low-latency performance at scale.

   • [claimed-docs] “Vast now supports creating *overlay* networks for instances, allowing client instances on different machines on the same physical LAN to sha…”
   • [claimed-docs] “Vast now supports creating overlay networks for instances, allowing client instances on different machines on the same physical LAN to share…”
   • [github] “vast.search_offers(query='gpu_name=RTX_4090 num_gpus>=4')”
   • [claimed-docs] “search for a GPU, rent it, wait for it to boot, connect to it, copy data, and clean up”
   • [community] “Prices for compute were competitive, but most instances had lousy bandwidth. You don't need bandwidth to run bitcoin miners, apparently. The…”
   • [community] “As a client (renting GPUs) I've found it to be pretty unreliable. I've tried renting GPUs a handful of times and hosts, bandwidth, and perfo…”

   proof ↗⚑ flag

Orchestration

1. platform engineerSchedule jobs on managed Slurm or Kubernetes instead of building my own scheduler on raw nodes

   weight 2 · round drawn
   Runpod—none0/10

   Runpod's Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed training, but no evidence indicates these clusters are backed by Slurm or Kubernetes scheduling — the docs describe raw multi-node GPU networking, not a managed job scheduler. This is a fair axis for a clusters/scale-focused GPU platform, but the evidence pack never mentions Slurm or K8s support, workload orchestration primitives, or job queueing semantics.

   • [claimed-docs] “Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed workloads.”
   • [claimed-docs] “Instant Clusters provide fully managed multi-node compute with high-performance networking for distributed workloads. Deploy jobs or large-s…”
   • [claimed-docs] “Deploy jobs or large-scale without managing infrastructure, networking, or cluster configuration.”
   • [claimed-docs] “Train models too large for one GPU, or accelerate training across multiple nodes.”

   proof ↗⚑ flag

   Vast.ai—none0/10

   Evidence shows Vast.ai provides raw GPU instance rental, templates, overlay networking for multi-node training, and CLI/API automation, but nothing about a managed Slurm or Kubernetes scheduling service — users would need to build their own scheduler on top of raw nodes. missing for 10: managed Slurm service, managed Kubernetes service, any orchestration layer beyond raw instance provisioning.

   • [claimed-docs] “Vast now supports creating *overlay* networks for instances, allowing client instances on different machines on the same physical LAN to sha…”
   • [claimed-docs] “Vast now supports creating overlay networks for instances, allowing client instances on different machines on the same physical LAN to share…”
   • [claimed-docs] “A template is how Vast helps you launch an instance, setting up your rented machine with whatever software and formatting you need.”
   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”

   proof ↗⚑ flag

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

   weight 2 · round to Vast.ai
   Runpod~partialprobed7/10

   Runpod's REST API is documented as providing programmatic access to 'all Runpod compute resources' (docs-8, docs-26) and is confirmed live via runtime probe with OpenAPI spec (runpod-probe-rt-4); the CLI/runpodctl and MCP servers also expose pod, serverless, template, network-volume, and registry management matching UI capabilities (docs-16, docs-32, docs-36, runpod-probe-rt-1/2/3). This gives strong evidence of broad UI/API parity for compute-resource management, but there is no explicit confirmation that account/billing settings (e.g., auto-pay, org/team management) or Secure Cloud vetting features are exposed via API/CLI, and community notes describe the execution environment as 'very locked down' for certain use cases (runpod-comm-2, runpod-comm-3). Missing for 10: explicit API coverage of billing/account/org settings, and independent confirmation that literally every UI action (not just compute-resource ones) has an API equivalent.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted API MCP server https://mcp.getrunpod.io/ returned HTTP 4…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.runpod.io/mcp completed a FULL keyless JSON-RPC …”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [community] “Regarding Colab local runtimes: 'The above might not work with runpod, since their execution environment is locked down. However it works wi…”
   • [community] “'Their execution environment is very locked down, which might make ssh the only option' when discussing using OpenZiti with Runpod.”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai's REST API is explicitly documented as the foundation underlying both the CLI and SDK, giving full programmatic control over the entire platform (search, instance lifecycle, templates, volumes, serverless endpoints), and this is corroborated by a live OpenAPI spec and runtime probes showing the CLI/API perform the same search/rent/manage operations available in the UI, including a dedicated agent skill for AI assistants to drive the platform. Minor gap: no explicit UI-vs-API feature parity audit exists confirming literally every UI-only setting (e.g., some billing/account UI screens) has an API equivalent. Missing for 10: an explicit parity matrix or independent confirmation that 100% of UI actions (not just core lifecycle) are API-exposed.

   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform.”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

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

   weight 3 · round to Runpod
   Runpod~partialclaimed5/10

   Runpod provides an S3-protocol-compatible API and CLI for transferring files off network volumes, and a REST API for programmatic access to resources — all standard/open interfaces that let a user pull data out without vendor lock-in. However, there is no explicit documentation of a full account data export, model/metadata export, or an account-closure/data-deletion workflow tying it all together into a genuine 'export everything and leave' capability. Missing for 10: comprehensive account/data export tooling, explicit data portability/GDPR-style export documentation, account closure and full data takeout confirmation.

   • [claimed-docs] “Runpod provides an S3-protocol compatible API for direct access to your network volumes. This allows you to manage files on your network vol…”
   • [claimed-docs] “This allows you to manage files on your network volumes without launching a Pod, reducing cost and operational friction.”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [claimed-docs] “Network volumes provide persistent storage that exists independently of your compute resources. Data is retained when terminate or scale to …”

   proof ↗⚑ flag

   Vast.ai~partialclaimed3/10

   Vast.ai instances run standard Linux with SSH access explicitly described as supporting file transfer ('Transfer files without exposing your data') and volumes are persistent, detachable storage, implying no proprietary lock-in on user data — but there is no explicit documentation of a bulk data-export feature, open-format guarantee, or account-closure data portability process. missing for 10: explicit data-export/portability documentation, statement on open formats, and evidence of full account data extraction on leaving.

   • [claimed-docs] “Log in securely, Run commands remotely, Transfer files without exposing your data”
   • [claimed-docs] “SSH (Secure Shell) is a protocol for safely connecting to remote servers. It encrypts your connection so you can: Log in securely, Run comma…”
   • [claimed-docs] “Volumes provide persistent storage that survives instance destruction and can be reattached to new instances.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Runpod—none0/10

   Runpod is a closed-source GPU cloud platform; only its CLI (runpodctl) is described as open source, but no evidence indicates the core Runpod platform/service source is available under an open license. The story asks about reading the product's source under an open license, which applies to any product but here evidence shows only a peripheral CLI tool is open, not the product itself.

   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine.”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”

   proof ↗⚑ flag

   Vast.ai—none0/10

   Vast.ai is a GPU marketplace platform whose core service (the marketplace, matching engine, billing) is closed; while its CLI is on GitHub, there is no evidence of an open-source license covering the platform's source code, and no license is mentioned anywhere in the pack. missing for 10: N/A (verdict is none) — need explicit license file/OSI license reference for the platform or CLI repo, and any statement of open-licensing of the core product.

   • [github] “vast.search_offers(query='gpu_name=RTX_4090 num_gpus>=4')”
   • [github] “Migrating from vastai-sdk? The old import still works: from vastai_sdk import VastAI”

   proof ↗⚑ flag

Billing

1. platform engineerPull usage and billing breakdowns programmatically to attribute GPU spend by team or workload

   weight 2 · round to Vast.ai
   Runpod—none0/10

   Evidence covers Pods/Serverless pricing, auto-pay, and a general REST API for provisioning compute resources, but nothing documents a billing/usage endpoint, cost-export, or per-team/per-workload spend attribution mechanism. The CLI's 'view account information' (runpod-docs-32) is the closest hint but is not shown to expose granular usage/billing data programmatically.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Auto-pay automatically reloads your account balance when it falls below a threshold, helping you avoid service interruptions from low funds.”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to …”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”

   proof ↗⚑ flag

   Vast.ai~partialclaimed4/10

   Vast.ai's REST API and CLI provide general programmatic access to the platform, including account balance checks and billing pages (autobilling, credit top-up), and scoped API keys can be created per workload/team for CI/CD use, which could support some cost attribution. However there is no explicit evidence of a dedicated usage/billing breakdown endpoint, cost tagging, or per-team/workload spend reporting API. missing for 10: dedicated billing/usage export API, cost tagging or labels for spend attribution, documented reports/analytics endpoint for team-level breakdowns.

   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “Use the autobilling feature to have the system automatically top up your account using a saved credit card when it runs low.”
   • [claimed-docs] “create a scoped key with only the permissions that workload needs”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”
   • [claimed-docs] “Autobilling keeps your balance positive to protect your instances from interruption or deletion.”

   proof ↗⚑ flag

2. ml engineerI am billed at per-second or per-minute granularity and only while my instance is actually running

   weight 3 · round to Runpod
   Runpod✓fullclaimed9/10

   Runpod docs explicitly state Pods are billed by the second with no ingress/egress fees, and Serverless is pay-per-second with billing running from worker start until fully stopped, rounded to the nearest second — directly matching the story of per-second billing only while running. Multiple docs corroborate scale-to-zero behavior for flex workers, meaning no charges when idle. Missing for 10: independent third-party billing audit or user account confirming exact second-level charges in practice.

   • [claimed-docs] “Pods are billed by the second for compute and storage, with no fees for data ingress or egress.”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to …”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs.”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate | Variable workloads, cost optimization”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate”

   proof ↗⚑ flag

   Vast.ai—none0/10

   Evidence shows Vast.ai quotes prices as hourly rates (dph/dph_total) and discusses reserved/interruptible pricing models and autobilling, but nowhere does the evidence pack confirm sub-hour (per-second or per-minute) billing granularity or explicitly state billing stops precisely when an instance is not running.

   ⚑ flag

Discovery

1. ai agentQuery the GPU catalog with live pricing and availability from a public or documented endpoint before committing any spend

   weight 2 · round to Vast.ai
   Runpod~partialprobed4/10

   Runpod's REST API is documented and its OpenAPI spec is publicly fetchable without auth, and pricing pages describe per-second GPU pricing across regions/plans, so an agent can discover pricing structure before spending. However, the evidence never shows a specific GPU catalog/availability endpoint that returns live pricing/availability, and the actual data-returning REST endpoints (e.g. /v1/pods) require an API key (401 without one), so live catalog querying isn't fully public. Missing for 10: a documented GPU types/availability endpoint, confirmation that pricing/availability data is queryable without an account/API key, and independent verification of live pricing accuracy via the API.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions. Simple pricing plans for teams of all sizes, designed to scale with you.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”

   proof ↗⚑ flag

   Vast.ai✓fullprobed9/10

   Vast.ai provides both a documented public REST endpoint (bundles/offers) and CLI (`vastai search offers`) that return live GPU pricing, specs, and availability without requiring an account or API key, verified via runtime probes. This directly matches the story of an agent querying the catalog before committing spend; missing for 10: independent third-party corroboration beyond vendor docs/probes and no explicit rate-limit/auth-tier documentation for heavy automated querying.

   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”
   • [claimed-docs] “vastai search offers 'gpu_name=RTX_4090 num_gpus=1 verified=true direct_port_count>=1 rentable=true' -o 'dlperf_usd-'”
   • [github] “vast.search_offers(query='gpu_name=RTX_4090 num_gpus>=4')”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

Pricing

1. platform engineerLock in reserved or committed-use discounts for sustained GPU capacity

   weight 1 · round to Vast.ai
   Runpod~partialclaimed6/10

   Runpod docs explicitly mention committing to 3- or 6-month terms upfront for significant discounts on compute costs, which directly addresses reserved/committed-use pricing for sustained GPU capacity. However, the evidence is a single brief doc line with no detail on discount percentages, capacity guarantees, contract terms, or enterprise commitment programs, and no independent/community corroboration of how this works in practice. Missing for 10: detailed terms of committed-use contracts, discount tiers, capacity guarantee mechanics, and hands-on/community confirmation of the reserved pricing program.

   • [claimed-docs] “Commit to a 3-month or 6-month term upfront for significant discounts on compute costs.”

   proof ↗⚑ flag

   Vast.ai✓fullclaimed7/10

   Vast.ai documents Reserved Instances that let users pre-pay for GPU time to lock in up to 50% discounts, convertible from any on-demand instance at any time, directly matching the committed-use discount story. Missing for 10: no independent/community corroboration of reserved-instance pricing behavior, no detail on commitment duration/terms flexibility, and no evidence of longer-term (e.g. multi-month/annual) contractual reserved capacity beyond simple pre-payment conversion.

   • [claimed-docs] “Reserved instances allow you to get significant discounts (up to 50%) by pre-paying for GPU time. You can convert any on-demand instance to …”
   • [claimed-docs] “You can convert any on-demand instance to a reserved instance at any time.”
   • [claimed-docs] “You can convert an on-demand instance into a reserved instance with a lower hourly rate by pre-paying.”
   • [claimed-docs] “Reserved instances allow you to get significant discounts (up to 50%) by pre-paying for GPU time.”

   proof ↗⚑ flag

2. ml engineerSee the published per-GPU-hour price for every GPU type on a public pricing page without talking to sales

   weight 3 · round to Vast.ai
   Runpod~partialclaimed5/10

   Runpod's public pricing page is referenced (www.runpod.io/pricing) and docs confirm per-second billing for Pods/Serverless without needing sales contact, but the evidence pack never shows an actual itemized per-GPU-hour price table for each GPU type. missing for 10: explicit citation of the per-GPU-hour rate listing (e.g. A100 $x/hr, H100 $y/hr) on the public page, confirmation that all GPU types are listed with prices, independent corroboration that the page requires no sales contact.

   • [claimed-docs] “Thousands of GPUs across 30+ regions. Simple pricing plans for teams of all sizes, designed to scale with you.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions.”
   • [claimed-docs] “Commit to a 3-month or 6-month term upfront for significant discounts on compute costs.”
   • [claimed-docs] “Pods are billed by the second for compute and storage, with no fees for data ingress or egress.”

   proof ↗⚑ flag

   Vast.ai~partialprobed7/10

   The marketplace search page and public REST/CLI endpoints let anyone see live per-GPU-hour prices without an account or contacting sales (vast-ai-docs-41, vast-ai-probe-rt-2, vast-ai-probe-rt-3), which covers the core of the story. However, there's no dedicated static 'pricing page' listing every GPU type's rate at a glance—pricing is discovered via a dynamic search/filter interface, and a community user explicitly complained about the number of clicks needed to find even an approximate price (vast-ai-comm-3). Missing for 10: a single canonical pricing table/page enumerating all GPU types' rates, and stronger independent corroboration that pricing is easy to find without friction.

   • [claimed-docs] “The search page is the main portal for finding good machines and creating instances on them.”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”
   • [community] “As a potential user, I'm disliking how many clicks it takes to find even an approximate price. Prices should be easiest to find.”
   • [claimed-docs] “Vast typically delivers more competitive pricing than traditional cloud providers. The marketplace model creates natural price competition”

   proof ↗⚑ flag

Spot

1. ml engineerRent spot or interruptible GPU capacity at a deep discount with clearly documented preemption semantics

   weight 3 · round to Vast.ai
   Runpod—none0/10

   The evidence pack covers Runpod's on-demand Pods, Serverless per-second pricing, Community/Secure Cloud tiers, and long-term commitment discounts, but nowhere documents a spot/interruptible/preemptible GPU tier or any preemption semantics (e.g., notice period, reclaim behavior, discount percentage). Community notes about 'low availability' (runpod-comm-4) reflect capacity issues, not a documented spot-pricing product.

   • [claimed-docs] “Commit to a 3-month or 6-month term upfront for significant discounts on compute costs.”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to …”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate | Variable workloads, cost optimization”
   • [claimed-docs] “Secure Cloud: Operates in T3/T4 data centers, providing high reliability and security for enterprise and production workloads. Community Clo…”
   • [community] “"Runpod used to have high availability of 4090 GPUs just about a month ago, but it seems like something has happened that has made almost al…”

   proof ↗⚑ flag

   Vast.ai~partialcommunity6/10

   Vast.ai clearly documents an interruptible/bidding instance type offering 50%+ discounts vs on-demand (vast-ai-docs-7/17/22/35/44), which satisfies the 'deep discount' part of the story. However, the evidence pack gives only the pricing angle and doesn't detail concrete preemption mechanics (notice period, how bidding/eviction actually triggers, restart behavior) — missing for 10: explicit preemption trigger/notice documentation, and independent confirmation that discount/preemption behavior matches docs (community notes reliability variance, e.g. vast-ai-comm-6, but this isn't a concrete dispute of interruptible semantics specifically).

   • [claimed-docs] “Interruptible instances use a bidding system: **Lowest cost** (often 50%+ cheaper than on-demand)”
   • [claimed-docs] “Lowest cost (often 50%+ cheaper than on-demand)”
   • [claimed-docs] “Interruptible instances use a bidding system: Lowest cost (often 50%+ cheaper than on-demand)”
   • [claimed-docs] “Interruptible instances use a bidding system... Lowest cost (often 50%+ cheaper than on-demand)”
   • [claimed-docs] “Vast.ai offers three instance types with different priority levels and pricing models to match your workload requirements and budget.”
   • [community] “As a client (renting GPUs) I've found it to be pretty unreliable. I've tried renting GPUs a handful of times and hosts, bandwidth, and perfo…”

   proof ↗⚑ flag

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

   weight 2 · round to Runpod
   Runpod~partialclaimed3/10

   Runpod advertises GPUs across '30+ regions' and distinguishes Secure Cloud (T3/T4 data centers) vs Community Cloud, implying some ability to pick a compute location, but there is no explicit documentation of selecting a specific region/data-residency guarantee for storage or network volumes. missing for 10: explicit region-selection UI/API for deployments, documented data-residency/compliance controls for stored data, independent confirmation that chosen region persists for storage.

   • [claimed-docs] “Thousands of GPUs across 30+ regions. Simple pricing plans for teams of all sizes, designed to scale with you.”
   • [claimed-docs] “Thousands of GPUs across 30+ regions.”
   • [claimed-docs] “Secure Cloud: Operates in T3/T4 data centers, providing high reliability and security for enterprise and production workloads. Community Clo…”
   • [claimed-docs] “Secure Cloud provides vetted infrastructure partners who meet enterprise security standards including SOC 2, ISO 27001, and PCI DSS certific…”

   proof ↗⚑ flag

   Vast.ai—none0/10

   The evidence pack shows Vast.ai lets users search/filter GPU offers by attributes like GPU model and reliability, and it distinguishes 'Secure Cloud' verified datacenters, but nowhere documents an explicit region/country selection or data-residency guarantee for where data is stored. A community report even flags a case where a host's advertised location (US) was misrepresented (actually China), undermining confidence that location can be reliably chosen or verified.

   • [claimed-docs] “Secure Cloud (Datacenter): These machines are verified and confirmed to be in a certified datacenter that meets our datacenter criteria.”
   • [claimed-docs] “Vast verifies that these machines are in a datacenter with a TIER 2/3 rating or ISO 27001. These offer cards have a blue label and are recom…”
   • [community] “Discussion flagged a Chinese host on vast.ai masquerading as a US host, raising concerns about where rented GPU compute is actually located.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Vast.ai
   Runpod—none0/10

   The evidence pack covers persistent storage (network volumes retaining data across terminations) and general compliance certifications (SOC 2, ISO 27001, PCI DSS) but contains no documentation of user-controlled data retention policies, deletion mechanisms, account/data purge options, or GDPR-style controls that would let an AI-native user manage retention and deletion of their data.

   • [claimed-docs] “Network volumes provide persistent storage that exists independently of your compute resources. Data is retained when terminate or scale to …”
   • [claimed-docs] “Secure Cloud provides vetted infrastructure partners who meet enterprise security standards including SOC 2, ISO 27001, and PCI DSS certific…”

   proof ↗⚑ flag

   Vast.ai~partialprobed3/10

   Evidence shows users can destroy instances and volumes (which otherwise persist across instance destruction) via CLI/API, giving basic control over deletion of compute resources and data, but there is no explicit documentation of data retention policies, data-deletion guarantees, or privacy controls beyond simply terminating instances/volumes. missing for 10: explicit data retention/deletion policy docs, guarantees on backend data purge after deletion, account-level data deletion controls, independent verification of deletion behavior.

   • [claimed-docs] “Volumes provide persistent storage that survives instance destruction and can be reattached to new instances.”
   • [claimed-docs] “search for a GPU, rent it, wait for it to boot, connect to it, copy data, and clean up”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Runpod—none0/10

   No evidence in the pack addresses telemetry, usage-tracking, or an opt-out mechanism for Runpod; the docs cover compute, storage, CLI, and API features but never mention privacy settings or telemetry controls.

   ⚑ flag

   Vast.ai—none0/10

   No evidence in the pack mentions telemetry, usage tracking, analytics opt-out, or privacy settings for Vast.ai's own platform/CLI; the docs focus on billing, instances, SSH, and API/CLI usage. missing for 10: any documentation of telemetry collection, an opt-out mechanism, or a privacy policy addressing usage tracking.

   ⚑ flag

Agent ops

1. ai agentProvision a GPU, monitor it, run a workload, and tear it down end to end through documented APIs, CLI, or MCP without a human in the console

   weight 3 · round drawn
   Runpod✓fullprobed8/10

   Runpod documents and runtime-probes confirm a REST API (live, API-key-gated) for provisioning/monitoring/terminating Pods, a CLI (runpodctl, verified running keylessly with pod/serverless/template management), and official MCP servers (one OAuth-gated for actual resource management, one no-auth for docs) enabling agent-driven end-to-end lifecycle without console use. Community evidence corroborates real-world CLI/template usage but also notes a locked-down execution environment and occasional GPU availability issues. missing for 10: independent hands-on verification of a full agent-driven create→monitor→teardown cycle via MCP specifically (only docs MCP fully probed keylessly; API MCP only auth-checked), and no third-party report confirming reliability of automated teardown at scale.

   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources.”
   • [claimed-docs] “runpodctl pod create --name NAME --gpu-id "GPU" --image "IMAGE"”
   • [claimed-docs] “Create, start, stop, and terminate Pods using the Runpod console or CLI.”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [claimed-docs] “Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a Runpod AP…”
   • [probe] “official MCP server documented at https://docs.runpod.io/get-started/mcp-servers”
   • [probe] “official CLI documented at https://docs.runpod.io/runpodctl/overview”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted API MCP server https://mcp.getrunpod.io/ returned HTTP 4…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.runpod.io/mcp completed a FULL keyless JSON-RPC …”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [community] “Regarding Colab local runtimes: 'The above might not work with runpod, since their execution environment is locked down. However it works wi…”
   • [community] “"Runpod used to have high availability of 4090 GPUs just about a month ago, but it seems like something has happened that has made almost al…”

   proof ↗⚑ flag

   Vast.ai✓fullprobed8/10

   Vast.ai documents a full REST API, CLI, and Python SDK covering the entire instance lifecycle (search offers, create/rent, connect, destroy), confirmed by runtime probes showing the CLI and API working keylessly for search and an OpenAPI spec being live. It also ships a dedicated 'vastai agent skill' explicitly for AI coding assistants to create instances, deploy endpoints, and manage keys without human console interaction, plus scoped API keys for automation/CI. Missing for 10: no independent hands-on evidence of a full agent-driven create→monitor→run→teardown cycle end-to-end (only search was probed live), and no first-party MCP server confirmed beyond the 'agent skill' framing.

   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”
   • [claimed-docs] “search for a GPU, rent it, wait for it to boot, connect to it, copy data, and clean up”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.vast.ai/api/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”

   proof ↗⚑ flag

Manage

1. ml engineerSet auto-shutdown timers or spend limits so a forgotten instance can't silently run up a huge bill

   weight 2 · round drawn
   Runpod—none0/10

   The evidence pack shows Runpod billing is pay-per-second and includes an 'auto-pay' feature that reloads balance when low (the opposite of a spend cap), but there is no mention anywhere of auto-shutdown timers, idle-timeout limits, max-runtime settings, or spend/budget caps that would stop a forgotten Pod from accumulating charges. This is a fair and plausible axis for a GPU cloud provider, so absence of evidence means 'none' rather than 'na'.

   • [claimed-docs] “Auto-pay automatically reloads your account balance when it falls below a threshold, helping you avoid service interruptions from low funds.”
   • [claimed-docs] “Pods are billed by the second for compute and storage, with no fees for data ingress or egress.”

   proof ↗⚑ flag

   Vast.ai—none0/10

   The evidence pack documents autobilling (auto top-up to keep instances running), reserved/interruptible instance pricing, and scoped API keys, but none of these are auto-shutdown timers or spend caps — autobilling in fact works against this story by automatically refilling balance to prevent instance interruption rather than capping spend. No mention of idle-timeout, max-runtime, or budget-limit features exists anywhere in the pack.

   • [claimed-docs] “Use the autobilling feature to have the system automatically top up your account using a saved credit card when it runs low.”
   • [claimed-docs] “Autobilling keeps your balance positive to protect your instances from interruption or deletion.”
   • [claimed-docs] “Reserved instances allow you to get significant discounts (up to 50%) by pre-paying for GPU time. You can convert any on-demand instance to …”
   • [claimed-docs] “create a scoped key with only the permissions that workload needs”

   proof ↗⚑ flag

2. developerStart, stop, restart, and terminate instances programmatically and keep paying only for what is running

   weight 2 · round to Runpod
   Runpod✓fullprobed9/10

   Runpod docs and CLI explicitly support create/start/stop/terminate pods via console, CLI (`runpodctl pod create`), and REST API, with per-second billing so users only pay for running compute, plus Serverless auto-scale-to-zero for idle cost avoidance. Runtime probes confirm the REST API and CLI are live and functional as documented. Missing for 10: independent third-party confirmation of full lifecycle (start/stop/restart) beyond docs, and no hands-on community report specifically testing restart/stop behavior.

   • [claimed-docs] “Create, start, stop, and terminate Pods using the Runpod console or CLI.”
   • [claimed-docs] “runpodctl pod create --name NAME --gpu-id "GPU" --image "IMAGE"”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Pods are billed by the second for compute and storage, with no fees for data ingress or egress.”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to …”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate | Variable workloads, cost optimization”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”

   proof ↗⚑ flag

   Vast.ai✓fullprobed8/10

   Vast.ai's CLI and REST API provide documented commands/endpoints for the full instance lifecycle (search, create, destroy) confirmed by runtime probes, plus billing docs (autobilling, per-hour pricing, reserved/interruptible discounts) demonstrate pay-only-for-what-runs. Community feedback corroborates cost savings but also notes reliability variance, which is a secondary concern rather than a lifecycle-control failure. Missing for 10: explicit documented 'stop'/'restart' CLI subcommands beyond create/destroy in the evidence, and independent hands-on confirmation of stop/restart specifically (only create/destroy verified at runtime).

   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”
   • [claimed-docs] “Use the autobilling feature to have the system automatically top up your account using a saved credit card when it runs low.”
   • [claimed-docs] “Autobilling keeps your balance positive to protect your instances from interruption or deletion.”
   • [claimed-docs] “Reserved instances allow you to get significant discounts (up to 50%) by pre-paying for GPU time. You can convert any on-demand instance to …”
   • [claimed-docs] “Interruptible instances use a bidding system: **Lowest cost** (often 50%+ cheaper than on-demand)”
   • [community] “Absolutely incredible how cheap the compute power is on this platform. Vast has saved me tens of thousands of dollars running ML experiments…”

   proof ↗⚑ flag

Provision

1. developerProvision an on-demand GPU instance from the console or API and be running code on it within minutes

   weight 3 · round to Runpod
   Runpod✓fullprobed8/10

   Runpod's docs and live runtime probes confirm the full provisioning path: create a Pod via console, CLI (`runpodctl pod create`), or REST API (verified live and key-gated at rest.runpod.io/v1/pods), select a pre-built template (PyTorch/JupyterLab ready instantly), and immediately access it via SSH, JupyterLab, or VS Code — matching the 'minutes to running code' story. Community posts corroborate ease of use ('few clicks' vs Azure, H100 access easier than Colab) though also note occasional GPU availability/boot issues that can delay provisioning. Missing for 10: independent hands-on timing benchmark of the full provision-to-code-execution flow, and resolution of the community-reported low-availability/boot failures.

   • [claimed-docs] “Follow this guide to learn how to create an account, deploy your first GPU, and use it to execute code remotely.”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “Once deployed, you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data scie…”
   • [claimed-docs] “Instead of installing PyTorch, configuring JupyterLab, and setting up all dependencies yourself, you can select an official Runpod PyTorch t…”
   • [claimed-docs] “runpodctl pod create --name NAME --gpu-id "GPU" --image "IMAGE"”
   • [claimed-docs] “Create, start, stop, and terminate Pods using the Runpod console or CLI.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Runpod CLI installed via `brew install runpod/runpodctl/runpodctl` and ran keylessly — `ru…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://rest.runpod.io/v1/openapi.json serves the REST API's OpenAPI spec keylessly, and a bare GET to …”
   • [community] “On Colab vs Moonglow: 'even Colab Pro doesn't offer H100s, whereas you can get that pretty easily on Runpod.'”
   • [community] “Comparing to Azure: 'They seem more complicated to manage... With Runpod and Vast.ai, I can simply use TheBloke's templates in a few clicks.…”
   • [community] “"Runpod used to have high availability of 4090 GPUs just about a month ago, but it seems like something has happened that has made almost al…”

   proof ↗⚑ flag

   Vast.ai✓fullprobed7/10

   Docs and runtime probes show the full quickstart flow — search offers via CLI/API keylessly, one-click templates, instance creation, SSH access with password auth disabled, and REST/CLI parity for automation — matching the 'search, rent, boot, connect' workflow described in vast-ai-docs-34. Community reviews largely corroborate ease and cost savings, though some flag friction/hoops versus AWS/GCP and inconsistent reliability, which tempers but doesn't contradict the core provisioning claim. Missing for 10: an independent hands-on timing test confirming actual boot-to-running-code within minutes, and resolution of community complaints about setup friction/reliability variance.

   • [claimed-docs] “This Quickstart will guide you through setting up your Vast.ai account and running your first instance in just a few steps.”
   • [claimed-docs] “search for a GPU, rent it, wait for it to boot, connect to it, copy data, and clean up”
   • [claimed-docs] “The search page is the main portal for finding good machines and creating instances on them.”
   • [claimed-docs] “Launch prebuilt or custom templates with one click.”
   • [claimed-docs] “The Vast.ai CLI gives you command-line access to the entire platform, authentication, GPU search, instance lifecycle, templates, volumes, se…”
   • [claimed-docs] “The Vast.ai REST API gives you programmatic control over the entire platform. It's the foundation that the CLI and SDK are built on.”
   • [claimed-docs] “SSH (Secure Shell) is a protocol for safely connecting to remote servers. It encrypts your connection so you can: Log in securely, Run comma…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Vast.ai CLI (pypi `vastai`) installed via uvx and ran keylessly — `vastai --help` prints t…”
   • [probe] “PROBE runtime (recorded 2026-09-05): `vastai search offers 'gpu_name=RTX_4090 num_gpus=1' -o dph` searched the LIVE GPU marketplace with NO …”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare keyless GET to https://console.vast.ai/api/v0/bundles/ returned live marketplace offers as JSON …”
   • [community] “Absolutely incredible how cheap the compute power is on this platform. Vast has saved me tens of thousands of dollars running ML experiments…”
   • [community] “While they've done a pretty good job considering with their software stack it's still kind of a pain to use with significant limitations and…”

   proof ↗⚑ flag

Serverless

1. developerDeploy code to autoscaling serverless GPU workers that scale to zero, instead of managing always-on instances

   weight 2 · round to Runpod
   Runpod✓fullclaimed8/10

   Runpod Serverless explicitly documents autoscaling GPU workers with 'Flex workers | Scale to zero when idle' and pay-per-second billing only while workers run, directly matching the story. Deployment is supported via CLI, REST API, or console, with FlashBoot/model caching to reduce cold-start costs. Missing for 10: independent hands-on benchmarks of scale-to-zero latency/cold-start behavior and third-party confirmation of autoscaling reliability under load.

   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate | Variable workloads, cost optimization”
   • [claimed-docs] “Flex workers | Scale to zero when idle | Standard per-second rate”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs. You're billed from when a worker starts until it fully stops, rounded up to …”
   • [claimed-docs] “Serverless offers pay-per-second pricing with no upfront costs.”
   • [claimed-docs] “Minimize with FlashBoot or model caching.”
   • [claimed-docs] “The Runpod REST API v1 provides programmatic access to all Runpod compute resources. Integrate GPU infrastructure into your applications, wo…”
   • [claimed-docs] “you can ask your agent to create Pods, deploy Serverless endpoints, transfer files, or deploy your own code with Flash, all in natural langu…”

   proof ↗⚑ flag

   Vast.ai~partialclaimed6/10

   Vast.ai explicitly ships 'Vast Serverless', described as letting users run compute-intensive workloads 'without managing GPUs, paying for execution rather than GPU rental time,' with a Python SDK and CLI support for deploying endpoints — matching the pay-per-execution serverless model a developer would want instead of always-on instances. However, the evidence never explicitly confirms autoscaling behavior or scale-to-zero semantics, nor gives hands-on/independent corroboration of how workers scale under load. Missing for 10: explicit autoscaling/scale-to-zero documentation, independent or hands-on validation of serverless endpoint behavior, and details on cold-start/latency tradeoffs.

   • [claimed-docs] “Vast Serverless is an AI infrastructure platform that lets you run compute-intensive workloads without managing GPUs, paying for execution r…”
   • [claimed-docs] “Interacting with Vast Serverless is made easy through a powerful python SDK.”
   • [claimed-docs] “The vastai agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check b…”
   • [claimed-docs] “The `vastai` agent skill lets AI coding assistants drive Vast.ai on your behalf — create instances, deploy endpoints, manage SSH keys, check…”

   proof ↗⚑ flag

Data movement

1. developerMove data in and out efficiently — S3-compatible endpoints, cloud-storage sync, or documented transfer tooling

   weight 2 · round to Runpod
   Runpod✓fullclaimed8/10

   Runpod documents an S3-compatible API for direct file management on network volumes, plus CLI (runpodctl) file transfer between local system and Runpod, SSH access, and no ingress/egress fees for Pods — covering multiple documented transfer paths. Missing for 10: independent hands-on verification of the S3 API's throughput/compatibility and broader cloud-storage sync (e.g., rclone/GDrive) integration beyond docs claims.

   • [claimed-docs] “This allows you to manage files on your network volumes without launching a Pod, reducing cost and operational friction.”
   • [claimed-docs] “Runpod provides an S3-protocol compatible API for direct access to your network volumes. This allows you to manage files on your network vol…”
   • [claimed-docs] “You can manage Pods, Serverless endpoints, templates, network volumes, and models, transfer files between your system and Runpod, diagnose i…”
   • [claimed-docs] “Runpod CLI is an open source command-line tool for managing your Runpod resources from your local machine. You can manage Pods, Serverless e…”
   • [claimed-docs] “Pods are billed by the second for compute and storage, with no fees for data ingress or egress.”
   • [claimed-docs] “Network volumes provide persistent storage that exists independently of your compute resources. Data is retained when terminate or scale to …”

   proof ↗⚑ flag

   Vast.ai~partialcommunity5/10

   Vast.ai documents SSH-based secure file transfer to/from instances and a CLI workflow that includes 'copy data' as a step, plus persistent Volumes for data that survives instance destruction. However there is no evidence of S3-compatible endpoints or native cloud-storage (S3/GCS/Azure Blob) sync tooling, and a community comment notes persistent-disk workflows are still cumbersome over time. Missing for 10: S3-compatible storage endpoint, built-in cloud-storage sync/mirroring tooling, independent hands-on validation of transfer throughput/performance.

   • [claimed-docs] “Log in securely, Run commands remotely, Transfer files without exposing your data”
   • [claimed-docs] “SSH (Secure Shell) is a protocol for safely connecting to remote servers. It encrypts your connection so you can: Log in securely, Run comma…”
   • [claimed-docs] “search for a GPU, rent it, wait for it to boot, connect to it, copy data, and clean up”
   • [claimed-docs] “Volumes provide persistent storage that survives instance destruction and can be reattached to new instances.”
   • [community] “Love vast.ai. Only wish is for it to be easier to work with persistent disks over time. I only use it for one off expensive jobs now.”

   proof ↗⚑ flag

Storage

1. developerAttach persistent network storage that survives instance teardown, so datasets and checkpoints outlive any single GPU rental

   weight 3 · round to Runpod
   Runpod✓fullclaimed8/10

   Runpod's docs explicitly describe network volumes as persistent storage that exists independently of compute and is retained on termination or scale-to-zero, shareable across machines/products, plus an S3-compatible API to manage files without launching a Pod. This directly matches the story of datasets/checkpoints outliving GPU rentals. Missing for 10: independent hands-on confirmation of durability across teardown and details on volume size/performance limits or region constraints.

   • [claimed-docs] “Network volumes provide persistent storage that exists independently of your compute resources. Data is retained when terminate or scale to …”
   • [claimed-docs] “Runpod provides an S3-protocol compatible API for direct access to your network volumes. This allows you to manage files on your network vol…”
   • [claimed-docs] “Use them to share data across multiple machines and Runpod products.”
   • [claimed-docs] “This allows you to manage files on your network volumes without launching a Pod, reducing cost and operational friction.”

   proof ↗⚑ flag

   Vast.ai~partialcommunity6/10

   Vast.ai docs explicitly describe 'Volumes' as persistent storage that survives instance destruction and can be reattached to new instances, directly matching the story. However, a community user notes wishing it were 'easier to work with persistent disks over time' and now avoids it for anything but one-off jobs, indicating real friction in practice. Missing for 10: independent hands-on verification of volume reattachment reliability, docs detailing size/performance limits, and broader community corroboration beyond a single anecdotal complaint.

   • [claimed-docs] “Volumes provide persistent storage that survives instance destruction and can be reattached to new instances.”
   • [community] “Love vast.ai. Only wish is for it to be easier to work with persistent disks over time. I only use it for one off expensive jobs now.”

   proof ↗⚑ flag

Images

1. developerRun my own Docker image or custom machine template with my exact environment

   weight 2 · round drawn
   Runpod✓fullcommunity8/10

   Runpod Pods explicitly support pulling custom containers from any compatible registry (Docker Hub, GHCR, ECR) or selecting official templates, with full SSH/JupyterLab/VS Code access to the running environment, and CLI/API/console management of templates and pods. missing for 10: independent hands-on verification of deploying a fully custom Docker image end-to-end (only docs/probe evidence, plus community notes that the execution environment is somewhat locked down for advanced networking use cases).

   • [claimed-docs] “Custom containers: Pull from any compatible container registry such as Docker Hub, GitHub Container Registry, or Amazon ECR.”
   • [claimed-docs] “Pull from any compatible container registry such as Docker Hub, GitHub Container Registry, or Amazon ECR.”
   • [claimed-docs] “Once deployed, you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data scie…”
   • [claimed-docs] “you can connect to your Pod through SSH for command-line access, web proxy for exposed web services, JupyterLab for data science workflows, …”
   • [claimed-docs] “Instead of installing PyTorch, configuring JupyterLab, and setting up dependencies yourself, you can select a template and have everything r…”
   • [claimed-docs] “runpodctl pod create --name NAME --gpu-id "GPU" --image "IMAGE"”
   • [claimed-docs] “Create, start, stop, and terminate Pods using the Runpod console or CLI.”
   • [community] “Regarding Colab local runtimes: 'The above might not work with runpod, since their execution environment is locked down. However it works wi…”
   • [community] “'Their execution environment is very locked down, which might make ssh the only option' when discussing using OpenZiti with Runpod.”

   proof ↗⚑ flag

   Vast.ai✓fullclaimed8/10

   Vast.ai's template system explicitly lets developers package their own Docker environment ('Package your environment so any GPU can run it with one click') and launch prebuilt or custom templates with one click, backed by CLI/API/SDK automation for creating and managing instances from these templates. Documentation confirms templates configure the rented machine with whatever software/formatting is needed, directly matching the story. missing for 10: no independent/hands-on confirmation of building and running a fully custom Docker image end-to-end (community evidence focuses on pricing/reliability, not template customization).

   • [claimed-docs] “Build a template - Package your environment so any GPU can run it with one click.”
   • [claimed-docs] “A template is how Vast helps you launch an instance, setting up your rented machine with whatever software and formatting you need.”
   • [claimed-docs] “Launch prebuilt or custom templates with one click.”
   • [claimed-docs] “PyTorch, vLLM, ComfyUI, agents, and more. Real deployments you can copy.”
   • [claimed-docs] “Automate with the CLI or SDK ... `vastai` from the shell or Python. Same operations, different syntax.”

   proof ↗⚑ flag

Templates

1. developerLaunch from pre-built ML templates (PyTorch, CUDA, vLLM, ComfyUI) instead of assembling an environment from scratch

   weight 2 · round to Runpod
   Runpod✓fullcommunity9/10

   Docs explicitly describe selecting official PyTorch/CUDA templates to skip manual environment setup, and community evidence corroborates one-click template usage (TheBloke templates in a few clicks) as a differentiator vs cloud giants like Azure. Coverage of specific named templates like vLLM/ComfyUI isn't directly evidenced, though template overview docs generalize the mechanism. missing for 10: explicit named vLLM/ComfyUI template listing, independent hands-on confirmation of template launch speed/completeness.

   • [claimed-docs] “Instead of installing PyTorch, configuring JupyterLab, and setting up dependencies yourself, you can select a template and have everything r…”
   • [claimed-docs] “Instead of installing PyTorch, configuring JupyterLab, and setting up all dependencies yourself, you can select an official Runpod PyTorch t…”
   • [claimed-docs] “you can select an official Runpod PyTorch template and have everything ready to go instantly”
   • [claimed-docs] “you can select a template and have everything ready instantly.”
   • [claimed-docs] “you can select a template and have everything ready instantly”
   • [community] “Comparing to Azure: 'They seem more complicated to manage... With Runpod and Vast.ai, I can simply use TheBloke's templates in a few clicks.…”

   proof ↗⚑ flag

   Vast.ai✓fullclaimed8/10

   Vast.ai's docs explicitly describe templates as a first-class launch mechanism ('Launch prebuilt or custom templates with one click', 'A template is how Vast helps you launch an instance') and directly name PyTorch, vLLM, and ComfyUI as available prebuilt templates ('PyTorch, vLLM, ComfyUI, agents, and more. Real deployments you can copy'). CUDA support is implied through GPU offer filtering and template packaging but not explicitly named as its own template. missing for 10: independent/hands-on confirmation of launching a specific named template (e.g., a community post describing a ComfyUI or vLLM template launch), and explicit CUDA-template documentation rather than inferred CUDA support.

   • [claimed-docs] “Launch prebuilt or custom templates with one click.”
   • [claimed-docs] “PyTorch, vLLM, ComfyUI, agents, and more. Real deployments you can copy.”
   • [claimed-docs] “A template is how Vast helps you launch an instance, setting up your rented machine with whatever software and formatting you need.”
   • [claimed-docs] “Build a template - Package your environment so any GPU can run it with one click.”

   proof ↗⚑ flag

Compliance

1. platform engineerVerify the provider's security and compliance posture (SOC 2, data handling, datacenter tiers) before putting proprietary models on it

   weight 2 · round to Runpod
   Runpod~partialcommunity5/10

   Runpod docs directly address SOC 2, ISO 27001, PCI DSS certifications and T3/T4 datacenter tiers for its Secure Cloud offering, giving a platform engineer concrete compliance signals to evaluate before deployment. However, this is limited to a single compliance page with no mention of audit reports/trust portal, data handling/residency details, encryption-at-rest specifics, or independent third-party verification, and community comments note the execution environment is 'locked down' without elaborating on security architecture. Missing for 10: downloadable SOC 2 report or trust center, detailed data handling/privacy policy, independent audit corroboration, and clarity on Community Cloud (non-Secure-Cloud) compliance gaps.

   • [claimed-docs] “Secure Cloud provides vetted infrastructure partners who meet enterprise security standards including SOC 2, ISO 27001, and PCI DSS certific…”
   • [claimed-docs] “Secure Cloud: Operates in T3/T4 data centers, providing high reliability and security for enterprise and production workloads. Community Clo…”
   • [community] “Regarding Colab local runtimes: 'The above might not work with runpod, since their execution environment is locked down. However it works wi…”
   • [community] “'Their execution environment is very locked down, which might make ssh the only option' when discussing using OpenZiti with Runpod.”

   proof ↗⚑ flag

   Vast.ai!disputedcontradicted4/10

   Vast.ai docs claim some infrastructure verification — 'Secure Cloud' machines are checked for TIER 2/3 datacenter rating or ISO 27001 certification (vast-ai-docs-14, vast-ai-docs-28) — but there is no mention of SOC 2 attestation, data-handling/privacy policies, or compliance documentation anywhere in the pack. Community evidence directly undercuts trust in these verifications: a host was found masquerading as US-based while actually located in China (vast-ai-comm-10), and another thread questions whether running consumer GPUs at scale even complies with Nvidia's own terms (vast-ai-comm-9) — concrete contradictions of the 'verified' security posture platform engineers would need to rely on. Missing for 10: SOC 2 or equivalent third-party compliance attestation, explicit data-handling/retention policy, and independent audit corroborating the datacenter tier claims.

   • [claimed-docs] “Secure Cloud (Datacenter): These machines are verified and confirmed to be in a certified datacenter that meets our datacenter criteria.”
   • [claimed-docs] “Vast verifies that these machines are in a datacenter with a TIER 2/3 rating or ISO 27001. These offer cards have a blue label and are recom…”
   • [community] “Running a fleet of RTX3090's on demand does not sound at all compliant with what little I know of NVidia's terms of use. There's surprisingl…”
   • [community] “Discussion flagged a Chinese host on vast.ai masquerading as a US host, raising concerns about where rented GPU compute is actually located.”

   proof ↗⚑ flag

Governance

1. platform engineerManage team members with roles and scoped API keys so credentials and spend stay controlled

   weight 1 · round to Vast.ai
   Runpod—none0/10

   The evidence pack covers Runpod's compute, storage, CLI, MCP, and API capabilities but contains no mention of team member management, role-based access control, or scoped/restricted API keys for governance purposes. This is a fair axis for a cloud infrastructure platform serving teams, but no documentation or probe evidence demonstrates it.

   ⚑ flag

   Vast.ai~partialclaimed4/10

   Vast.ai documents scoped API keys with limited permissions for CI/CD and shared tooling use cases (create api-key, per-workload scoping), which addresses the credential-control half of the story. However, there is no evidence of team/organization member management, role assignment, or multi-user account governance — the evidence pack only covers individual scoped keys, not team-based RBAC. Missing for 10: team member invitation/management, role definitions (admin/viewer/etc.), org-level spend controls tied to roles, and any audit trail for team activity.

   • [claimed-docs] “You can also create scoped keys with limited permissions using `vastai create api-key`, useful for CI/CD or shared tooling.”
   • [claimed-docs] “create a scoped key with only the permissions that workload needs”
   • [claimed-docs] “For shared tooling, CI/CD, or automation, create a scoped key with only the permissions that workload needs.”

   proof ↗⚑ flag