Runpod vs Lambda

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

   Lambda~partialclaimed6/10

   Lambda instances ship with a preinstalled JupyterLab server and SSH access out of the box, letting a developer open Jupyter or SSH in with no extra setup (docs-3, docs-7). However, there's no explicit documentation of a one-step VS Code/Cursor Remote-SSH or dev-container integration — only generic SSH connectivity is mentioned, requiring the developer to manually configure their IDE's remote connection. Missing for 10: explicit VS Code/Cursor connection docs or one-click IDE integration, independent confirmation that IDE remote-attach works smoothly.

   • [claimed-docs] “each ODC instance provides a JupyterLab installation for creating and managing Jupyter notebooks”
   • [claimed-docs] “You can connect to your On-Demand Cloud (ODC) instances directly through SSH or by using the preinstalled JupyterLab server.”
   • [claimed-docs] “On-Demand Cloud (ODC) provides on-demand access to Linux-based, GPU-backed virtual machine instances.”

   proof ↗⚑ flag

Networking

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

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

   Lambda~partialclaimed5/10

   Lambda's docs show port-level control via Firewall rules restricting incoming traffic (docs-11/18) and SSH/JupyterLab access (docs-7), and high-performance private networking (GPUDirect RDMA) exists within 1-Click Clusters and Managed Kubernetes for GPU node interconnect (docs-36, docs-12/33). However, there's no explicit documentation of a general-purpose private networking/VPC feature connecting arbitrary On-Demand instances, nor clear guidance on opening/exposing custom application ports beyond firewall restriction rules. Missing for 10: explicit port-exposure/ingress configuration for serving apps, dedicated private networking (VPC/VLAN) between standard instances outside of 1CC/K8s clusters, and independent confirmation of these networking features working in practice.

   • [claimed-docs] “You can restrict incoming traffic to the instances in a workspace... by creating firewall rules on the Firewall page”
   • [claimed-docs] “You can restrict incoming traffic to the instances in a workspace...by creating firewall rules on the [Firewall page]”
   • [claimed-docs] “You can connect to your On-Demand Cloud (ODC) instances directly through SSH or by using the preinstalled JupyterLab server.”
   • [claimed-docs] “1-Click Clusters (1CC) are high-performance clusters composed of both GPU and CPU nodes, featuring 16 to 512 NVIDIA H100 or B200 SXM Tensor …”
   • [claimed-docs] “MK8s provides a Kubernetes environment with GPU and InfiniBand (RDMA) support, and shared persistent storage across all nodes in a 1CC.”
   • [claimed-docs] “MK8s provides a Kubernetes environment with GPU and InfiniBand (RDMA) support, and shared persistent storage across all nodes in a 1CC. Clus…”

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

   Lambda✓fullcommunity8/10

   Docs confirm direct SSH access to GPU instances with user-controlled base images (GPU Base minimal Ubuntu image for high control), cloud-init customization, and API/CLI provisioning, implying standard root SSH access typical of cloud VM instances. Community evidence (unofficial CLI/MCP tool) corroborates real-world SSH-based workflows for launching and connecting to instances. Missing for 10: explicit first-party documentation confirming root/sudo privileges once SSH'd in, and independent hands-on confirmation of key management specifics.

   • [claimed-docs] “You can connect to your On-Demand Cloud (ODC) instances directly through SSH or by using the preinstalled JupyterLab server.”
   • [claimed-docs] “GPU Base: An image based on Ubuntu Server that includes a minimal set of key AI/ML tools and drivers... Use if: You want a minimal working s…”
   • [claimed-docs] “you can add launch-time configuration instructions using [cloud-init]”
   • [claimed-docs] “the API allows you to use a different base image for your instance”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

Agent access

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

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

   Lambda—none0/10

   A direct probe of https://docs.lambda.ai/llms.txt returned HTTP 404, and there is no other evidence of an llms.txt file or agent-oriented documentation format anywhere in the pack; the OpenAPI spec is a REST API description, not agent-native docs guidance.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.lambda.ai/llms.txt”

   proof ↗⚑ flag

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

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

   Lambda✓fullprobed7/10

   Lambda's On-Demand Cloud exposes a full REST API for programmatically launching/terminating GPU instances, with cloud-init for launch-time automation, confirmed live and key-gated by a runtime probe — enabling headless/CI-driven provisioning of GPU workloads without any UI interaction. Missing for 10: an official first-party CLI/SDK or CI/CD templates (only an unofficial community-built CLI/MCP server exists) and documented CI examples (e.g., GitHub Actions) from Lambda itself.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API. For details, see Launch instances”
   • [claimed-docs] “If you're launching your instance with the Lambda Cloud API, you can add launch-time configuration instructions using cloud-init”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   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

   Lambda—none0/10

   Only an unofficial, community-built CLI/MCP server for Lambda GPU instances is documented; there is no evidence of an official first-party MCP server from Lambda itself.

   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Lambda—none0/10

   Evidence shows only a REST API (openapi.json) and cloud-init/SSH access, with no first-party CLI tool documented; the only CLI mentioned is an unofficial third-party CLI/MCP server built by a community developer for AI agents, not an official Lambda offering.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   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

   Lambda✓fullprobed9/10

   Lambda publishes a documented public REST API (Lambda Cloud API) with a live OpenAPI 3.1 spec covering instance provisioning, cluster launch, filesystems, and firewall management, confirmed both in docs and via runtime probe returning the full spec and a key-gated endpoint. Community evidence further shows a third-party built a CLI/MCP server on top of this API enabling AI agents to launch/terminate GPU instances programmatically, corroborating real-world agentic usability. Missing for 10: an official first-party SDK/MCP server and an llms.txt (probe found 404), so slight extra integration work is needed.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API. For details, see Launch instances”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

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

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

   Lambda—none0/10

   Lambda's Cloud API is key-gated (docs-31/39, probe-rt-1 confirms 401 without a key), but there is no evidence of scoped/least-privilege credential issuance (e.g., role-based permissions, read-only vs. write scopes, or per-agent restricted keys) — only that a single API key exists to access all account resources.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Lambda~partialprobed3/10

   Lambda documents a public, key-gated REST/Cloud API with a full OpenAPI 3.1 spec that could underlie SDK development, but no official first-party SDK client libraries (Python/JS/etc.) are evidenced — only an unofficial third-party CLI/MCP server exists. Missing for 10: official SDK packages/libraries, first-party language bindings, docs referencing an 'SDK' rather than raw REST endpoints.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Lambda~partialclaimed3/10

   Lambda's API docs mention webhook notifications only for support ticket events ('Lambda can send webhook notifications to your URL when support ticket events occur'), not for core compute/instance lifecycle events that an AI-native/agentic user would most want to subscribe to. missing for 10: webhook support for instance state changes or job/cluster events, first-party docs on webhook setup/payload schema, and independent confirmation of use in agentic workflows.

   • [claimed-docs] “Lambda can send webhook notifications to your URL when support ticket events occur,\nenabling near real-time integration with your systems.”

   proof ↗⚑ flag

Agentic features

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

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

   Lambda—none0/10

   Lambda is GPU IaaS with an API, cloud-init for launch-time config, and webhooks for support tickets, but there is no native scheduler/automation service that runs workflows autonomously in the background; the only agentic automation (CLI/MCP server to launch/terminate instances via AI agents) is an unofficial third-party project, not a Lambda-native feature.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “Lambda can send webhook notifications to your URL when support ticket events occur,\nenabling near real-time integration with your systems.”
   • [claimed-docs] “If you're launching your instance with the Lambda Cloud API, you can add launch-time configuration instructions using cloud-init”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

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

   Lambda~partialprobed3/10

   Lambda itself only exposes a REST API (docs-1..41) with no first-party natural-language or agent interface; the only NL-command capability comes from a third-party developer's unofficial CLI/MCP server that lets AI agents launch/terminate instances via commands like 'launch an H100' (lambda-labs-comm-3). This is an extra, unofficial tool rather than a supported product feature. missing for 10: first-party NL/agent interface, official MCP server or chat-based control, documentation of natural-language command support.

   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   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

   Lambda—none0/10

   Lambda exposes a raw OpenAPI 3.1 spec (cloud.lambda.ai/api/v1/openapi.json) and documents REST endpoints, but there is no evidence of an interactive, browsable API reference (e.g., Swagger UI, 'try it out' console) with runnable examples — probes for docs.lambda.ai/openapi.json, swagger.json, and llms.txt all 404.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.lambda.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lambda.ai/openapi.json, https://docs.lambda.ai/swagger.json, https://docs.lambda.ai/api…”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   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

   Lambda✓fullprobed9/10

   Lambda publishes a live, machine-readable OpenAPI 3.1 spec for its Cloud API at https://cloud.lambda.ai/api/v1/openapi.json, confirmed both by docs references and a runtime probe that fetched the full spec keylessly. Minor gap: the probe found the docs.lambda.ai domain itself doesn't serve openapi.json at the expected conventional path (404s), requiring the correct subdomain. missing for 10: independent third-party confirmation of spec completeness/versioning beyond the runtime probe.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.lambda.ai/openapi.json, https://docs.lambda.ai/swagger.json, https://docs.lambda.ai/api…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Runpod—none0/10

   Runpod's docs describe deploying Pods, Serverless endpoints, and Instant Clusters, but nothing in the evidence describes a dedicated sandbox/staging mode that isolates test workloads from 'production' data or endpoints — no environment-separation, test-vs-prod flagging, or data-isolation guarantee is documented. missing for 10: any documented sandbox/staging environment concept, production-data isolation guarantees, or environment-promotion workflow.

   ⚑ flag

   Lambda—none0/10

   Lambda's docs describe launching isolated GPU instances, firewalls, and filesystems, but there is no documented sandbox/production separation concept, test-mode, or data-isolation feature aimed at safely testing without touching production data — users would have to build this themselves by manually spinning up separate instances. missing for 10: explicit sandbox/staging environment feature, guidance on isolating test data from production, any mention of a 'sandbox mode' or non-production testing workflow.

   • [claimed-docs] “On-Demand Cloud (ODC) provides on-demand access to Linux-based, GPU-backed virtual machine instances.”
   • [claimed-docs] “You can restrict incoming traffic to the instances in a workspace... by creating firewall rules on the Firewall page”
   • [claimed-docs] “A filesystem is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”

   proof ↗⚑ flag

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

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

   Lambda~partialprobed3/10

   The Lambda Cloud API is clearly versioned (path-based v1, documented via a live OpenAPI 3.1 spec with rate limits), satisfying the 'versioned APIs' half of the story, but no evidence anywhere in the pack mentions a deprecation policy, versioning changelog, or sunset process for older API versions. Missing for 10: documented deprecation/versioning policy, changelog of breaking changes, migration guidance between API versions, independent confirmation of stability guarantees.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   proof ↗⚑ flag

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

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

   Lambda~partialprobed5/10

   Lambda supports large-scale provisioning (1-Click Clusters of 16–512+ GPUs, Slurm-based multi-node job scheduling) and a REST API for programmatic instance management, which lets an AI-native user manage many GPU resources at once. However, the documented API is rate-limited to 1 req/s (and launches limited per 12s), with no evidence of true bulk/batch endpoints for creating, updating, or deleting many items in a single call. Missing for 10: explicit bulk-create/bulk-delete API operations, batch job submission tooling beyond Slurm's node scheduling, and evidence of high-throughput automation without rate-limit friction.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “1-Click Clusters (1CC) are high-performance clusters composed of both GPU and CPU nodes, featuring 16 to 512 NVIDIA H100 or B200 SXM Tensor …”
   • [claimed-docs] “Production-ready clusters from 16 to 2,000+ NVIDIA B200 or H100 GPUs.”
   • [claimed-docs] “Slurm automatically schedules workloads, maximizing cluster utilization while preventing resource contention.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   proof ↗⚑ flag

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

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

   Lambda—none0/10

   Lambda is a GPU IaaS provider; the only event-triggered mechanism found is webhook notifications for support-ticket events (docs-40) and cloud-init instructions applied only at launch time (docs-6, docs-24, docs-32) — neither constitutes a general rules/automation engine letting users define arbitrary triggers-to-actions. No autoscaling policies, alert-based actions, or rule-definition UI/API are documented. missing for 10: a general event-rule engine (define trigger conditions + arbitrary actions), autoscaling/alerting automation, and any first-party support beyond narrow support-ticket webhooks.

   • [claimed-docs] “Lambda can send webhook notifications to your URL when support ticket events occur,\nenabling near real-time integration with your systems.”
   • [claimed-docs] “you can add launch-time configuration instructions using [cloud-init]”
   • [claimed-docs] “If you're launching your instance with the Lambda Cloud API, you can add launch-time configuration instructions using cloud-init”

   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

   Lambda—none0/10

   Lambda offers Slurm-based job scheduling for HPC workloads and a REST API with cloud-init for launch-time configuration, but none of the evidence describes a mechanism for scheduling recurring/cron-like jobs or automated recurring workflows — Slurm here is described as scheduling submitted workloads, not recurring automation. missing for 10: any cron/recurring job scheduler, workflow orchestration triggers, or documentation of repeat/interval-based job execution.

   • [claimed-docs] “Slurm automatically schedules workloads, maximizing cluster utilization while preventing resource contention.”
   • [claimed-docs] “The quick start takes you from SSH to your first multi-node GPU job in minutes.”
   • [claimed-docs] “Lambda monitors and maintains the health of Slurm daemons such as slurmctld and slurmdbd.”
   • [claimed-docs] “Lambda monitors and maintains the health of Slurm daemons such as `slurmctld` and `slurmdbd`.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”

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

   Lambda—none0/10

   The evidence describes Lambda's instance types, API endpoints for launching/managing instances, and pricing, but nowhere shows a real-time GPU availability/capacity view by type and region that an engineer could check before provisioning. Docs even describe access as 'first-come' (docs-28), implying no visibility into stock levels, and no dashboard or API field for capacity-by-region is mentioned.

   • [claimed-docs] “ODC offers a variety of predefined instance types to support different workload requirements. Available GPUs include the state-of-the-art NV…”
   • [claimed-docs] “Deploy NVIDIA B200, H100, A100, or GH200 instances in minutes with self-serve, first-come access.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”

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

   Lambda✓fullcommunity9/10

   Lambda's docs clearly list current-gen H100/B200 (and GH200) options alongside older A100 in on-demand instances and clusters, covering both current and previous-generation GPU tiers with flexible on-demand access. Missing for 10: no explicit pricing comparison table or independent benchmark confirming actual availability/pricing tiers side-by-side.

   • [claimed-docs] “ODC offers a variety of predefined instance types to support different workload requirements. Available GPUs include the state-of-the-art NV…”
   • [claimed-docs] “Deploy NVIDIA B200, H100, A100, or GH200 instances in minutes with self-serve, first-come access.”
   • [claimed-docs] “1-Click Clusters (1CC) are high-performance clusters composed of both GPU and CPU nodes, featuring 16 to 512 NVIDIA H100 or B200 SXM Tensor …”
   • [claimed-docs] “Production-ready clusters from 16 to 2,000+ NVIDIA B200 or H100 GPUs.”
   • [community] “Lambda Labs dropped H100 on-demand GPU pricing to $1.99/GPU/Hour (announced via Twitter, June 2023).”

   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

   Lambda—none0/10

   Evidence shows only generic API rate limits and a vague 'contact us for reserved capacity' pricing note, but no documented per-account instance/GPU quotas nor any defined process (e.g., support ticket workflow, quota dashboard) to request limit increases.

   • [claimed-docs] “Contact us for reserved capacity at our lowest prices.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   proof ↗⚑ flag

Clusters

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

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

   Lambda✓fullprobed9/10

   Lambda offers self-serve 1-Click Clusters (16-512 H100/B200 GPUs) with GPUDirect RDMA up to 3200 Gb/s, launched instantly with no long-term commitment and no sales cycle mentioned, plus Managed Slurm/Kubernetes for orchestration and a live self-serve API confirmed by runtime probe. Community evidence corroborates self-serve on-demand access and even third-party tooling built on the API, though no independent hands-on report specifically confirms multi-node cluster provisioning experience. Missing for 10: independent/hands-on validation of the 1-Click Cluster provisioning flow itself and interconnect performance in practice.

   • [claimed-docs] “1-Click Clusters (1CC) are high-performance clusters composed of both GPU and CPU nodes, featuring 16 to 512 NVIDIA H100 or B200 SXM Tensor …”
   • [claimed-docs] “1-Click Clusters (1CC) are high-performance clusters composed of both GPU and CPU nodes, featuring 16 to 512 NVIDIA H100 or B200 SXM Tensor …”
   • [claimed-docs] “The quick start takes you from SSH to your first multi-node GPU job in minutes.”
   • [claimed-docs] “Production-ready clusters from 16 to 2,000+ NVIDIA B200 or H100 GPUs.”
   • [claimed-docs] “Deploy NVIDIA B200, H100, A100, or GH200 instances in minutes with self-serve, first-come access.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

Orchestration

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

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

   Lambda✓fullclaimed8/10

   Lambda offers Managed Slurm and Managed Kubernetes (MK8s) as first-party managed schedulers on top of 1-Click Clusters, with Slurm handling automatic job scheduling/utilization and daemon health monitoring, and MK8s providing preconfigured GPU/RDMA Kubernetes clusters ready for workload deployment — directly fulfilling the 'managed scheduler instead of building your own' story. Missing for 10: independent/hands-on validation of Slurm or K8s job scheduling in production (community evidence only covers billing and unofficial CLI tooling, not scheduler usage), and no detail on multi-tenancy/queue customization depth.

   • [claimed-docs] “MK8s provides a Kubernetes environment with GPU and InfiniBand (RDMA) support, and shared persistent storage across all nodes in a 1CC.”
   • [claimed-docs] “Lambda provides support according to the service level agreements (SLAs) in place with the customer.”
   • [claimed-docs] “The quick start takes you from SSH to your first multi-node GPU job in minutes.”
   • [claimed-docs] “Lambda monitors and maintains the health of Slurm daemons such as slurmctld and slurmdbd.”
   • [claimed-docs] “MK8s provides a Kubernetes environment with GPU and InfiniBand (RDMA) support, and shared persistent storage across all nodes in a 1CC. Clus…”
   • [claimed-docs] “Lmod for environment management: Use Lmod to dynamically load and unload software modules available on the cluster, such as HPC-X, Node.js, …”
   • [claimed-docs] “Slurm automatically schedules workloads, maximizing cluster utilization while preventing resource contention.”
   • [claimed-docs] “Lambda monitors and maintains the health of Slurm daemons such as `slurmctld` and `slurmdbd`.”

   proof ↗⚑ flag

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

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

   Lambda~partialprobed6/10

   Lambda publishes a live, documented REST API (OpenAPI spec, key-gated) covering core instance lifecycle actions (launch, list, terminate, cloud-init, custom images) that mirror UI capabilities for On-Demand Cloud instances, and third parties have built agent-facing CLIs/MCP wrappers on top of it. However, evidence doesn't show API parity for other UI-managed features like firewall rules, filesystem management, 1-Click Cluster/Slurm cluster provisioning, or usage/billing dashboards. Missing for 10: documented API endpoints for firewalls, filesystems, 1CC/Slurm cluster lifecycle, and usage/billing views; independent confirmation of full UI-API parity.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API. For details, see Launch instances”
   • [claimed-docs] “the API allows you to use a different base image for your instance”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   proof ↗⚑ flag

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

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

   Lambda~partialclaimed6/10

   Lambda's filesystems support S3-compatible tools like rclone and s5cmd, letting users copy datasets and files out in standard, open formats rather than being locked into a proprietary export mechanism, and the Cloud API allows programmatic access to resource metadata. However, there's no explicit documentation of a full account-data export (billing, usage history, configs) or a one-click 'export everything and leave' workflow. Missing for 10: explicit full-account data export/portability guarantee, documentation of exporting non-file data (billing/usage/API keys), independent verification that egress is unrestricted or free of lock-in fees.

   • [claimed-docs] “This adapter allows you to use S3-compatible tools like rclone and s5cmd to copy files to and from your filesystems and perform common file …”
   • [claimed-docs] “This adapter allows you to use S3-compatible tools like `rclone` and `s5cmd` to copy files to and from your filesystems”
   • [claimed-docs] “A filesystem is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”

   proof ↗⚑ flag

Billing

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

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

   Lambda—none0/10

   Lambda's docs describe billing by hourly/minute increments and a web 'Usage page' with an Instances tab for viewing monthly usage (lambda-labs-docs-10, lambda-labs-docs-20), but this is UI-only, not a programmatic API. The published Lambda Cloud API (lambda-labs-docs-31/39, confirmed live via probe) covers instance provisioning/management, not billing or usage export, and no team/workload cost-attribution tagging or billing API endpoint is documented anywhere in the evidence.

   • [claimed-docs] “ODC prices instances by hourly usage and bills in one-minute increments.”
   • [claimed-docs] “To view your monthly usage, navigate to the [Usage page]...and then click the **Instances** tab.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   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

   Lambda✓fullcommunity8/10

   Lambda's docs explicitly state ODC instances are priced hourly but billed in one-minute increments, and billing only accrues while an instance is running/attached — corroborated by a community report where a user was billed for the full duration their instance remained running (idle counted as running, confirming billing follows instance lifecycle rather than usage activity). Missing for 10: true per-second billing granularity (only per-minute is documented), and independent/user confirmation that billing precisely matches the one-minute increment claim.

   • [claimed-docs] “ODC prices instances by hourly usage and bills in one-minute increments.”
   • [community] “User left a Lambda Labs GH200 instance running after brief testing and was billed $583 for 391 hours. Lambda's support said: 'Lambda does no…”

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

   Lambda~partialprobed6/10

   Lambda publishes a full OpenAPI 3.1 spec for its Cloud API keylessly (lambda-labs-probe-rt-1), and docs confirm the API is used to create/manage instances programmatically (lambda-labs-docs-5, lambda-labs-docs-23, lambda-labs-docs-31/39), with a separate public pricing page (lambda-labs-docs-41). An unofficial MCP/CLI already lets agents launch/terminate Lambda GPUs (lambda-labs-comm-3), implying some catalog query capability exists. However, actual provisioning calls (e.g. /instances) require an API key (401 per probe), and no evidence explicitly shows a documented, unauthenticated 'instance-types/catalog' endpoint returning live pricing+availability distinct from the static marketing pricing page. Missing for 10: explicit documentation of a public catalog/instance-types endpoint with live pricing+availability, and independent confirmation an agent can query it pre-spend without a key.

   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [claimed-docs] “Clear, straightforward pricing for Instances, 1-Click Clusters™, and Superclusters.”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”

   proof ↗⚑ flag

Pricing

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

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

   Lambda~partialclaimed4/10

   Lambda explicitly advertises a path to reserved/committed capacity pricing ('Contact us for reserved capacity at our lowest prices') and also offers Private Cloud for large single-tenant multi-year deployments, confirming the capability exists. However, this is sales-assisted only — there's no self-service reservation mechanism, no published discount tiers/terms, and on-demand pages emphasize 'No long-term commitments,' contrasting with the reserved offering. Missing for 10: self-service reservation/commitment workflow, published discount rates or contract terms, and independent evidence of actual reserved pricing outcomes.

   • [claimed-docs] “Contact us for reserved capacity at our lowest prices.”
   • [claimed-docs] “Private Cloud is the ideal solution for organizations requiring a single-tenant cluster with 1,000+ GPUs. Private Cloud customers have low-l…”
   • [claimed-docs] “Launch 16x to 512x NVIDIA H100 or B200 GPU clusters instantly, or start with a single-node instance. No long-term commitments.”

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

   Lambda✓fullcommunity8/10

   Lambda publishes a public pricing page (lambda.ai/pricing) with clear per-GPU-hour pricing and explicitly states 'Clear, straightforward pricing for Instances, 1-Click Clusters, and Superclusters' without requiring sales contact for on-demand instances; community evidence corroborates historical public per-GPU pricing announcements (e.g., $1.99/GPU/Hour H100). Missing for 10: independent third-party confirmation that ALL current GPU types' per-hour rates are listed publicly (reserved/private cloud capacity explicitly requires contacting sales per docs-35), and no direct evidence snippet showing the actual price table contents.

   • [claimed-docs] “Clear, straightforward pricing for Instances, 1-Click Clusters™, and Superclusters.”
   • [claimed-docs] “Production-ready clusters from 16 to 2,000+ NVIDIA B200 or H100 GPUs.”
   • [claimed-docs] “Contact us for reserved capacity at our lowest prices.”
   • [community] “Lambda Labs dropped H100 on-demand GPU pricing to $1.99/GPU/Hour (announced via Twitter, June 2023).”

   proof ↗⚑ flag

Spot

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

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

   Lambda—none0/10

   Lambda's docs describe only on-demand, reserved, and private-cloud pricing tiers; there is no mention of spot/interruptible/preemptible instances or any preemption semantics. The billing evidence even highlights that Lambda bills continuously for any running instance regardless of use, reinforcing the absence of a spot/interruptible model.

   • [claimed-docs] “ODC prices instances by hourly usage and bills in one-minute increments.”
   • [claimed-docs] “Contact us for reserved capacity at our lowest prices.”
   • [claimed-docs] “Clear, straightforward pricing for Instances, 1-Click Clusters™, and Superclusters.”
   • [community] “User left a Lambda Labs GH200 instance running after brief testing and was billed $583 for 391 hours. Lambda's support said: 'Lambda does no…”

   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

   Lambda—none0/10

   Lambda's docs mention that filesystems are a 'regional' store (implying infrastructure regions exist) but provide no evidence of user-facing controls to select a specific region or data-residency zone for compliance/privacy purposes. Missing for 10: explicit region-selection UI/API, documented list of available regions, and any data-residency/compliance guarantees.

   • [claimed-docs] “A filesystem is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “A _filesystem_ is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

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

   Lambda—none0/10

   Lambda is a GPU cloud infrastructure provider (compute instances, clusters, filesystems, API); there is no evidence of any data retention/deletion controls, data lifecycle policies, or privacy dashboard for AI-native users to manage what data is stored or deleted. The evidence covers filesystems for storage and billing/usage tracking but nothing about retention limits or deletion mechanisms. missing for 10: documented data retention policy, deletion/opt-out controls, data lifecycle settings, any privacy-posture documentation.

   • [claimed-docs] “A filesystem is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “A _filesystem_ is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “To view your monthly usage, navigate to the [Usage page]...and then click the **Instances** tab.”

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

   Lambda~partialprobed6/10

   Lambda documents a full REST API for provisioning, launching, and managing on-demand instances/clusters (with cloud-init for workload setup and a live, key-gated OpenAPI endpoint confirmed by probe), plus usage/monitoring pages and GPU dashboards — enabling non-human, API-driven lifecycle management. However, there is no official CLI and no first-party MCP server; the only MCP integration found is a third-party/unofficial community-built CLI+MCP wrapper, and monitoring is oriented toward billing/usage dashboards rather than a documented job-status API for agents. missing for 10: official CLI, first-party MCP server, and a documented workload-monitoring/job-status API distinct from usage billing.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API. For details, see Launch instances”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create\nand manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [claimed-docs] “you can add launch-time configuration instructions using [cloud-init]”
   • [claimed-docs] “To view your monthly usage, navigate to the [Usage page]...and then click the **Instances** tab.”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   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

   Lambda—none0/10

   No documentation or feature evidence shows auto-shutdown timers, idle detection, or spend-limit controls; on the contrary, community evidence explicitly states Lambda 'does not distinguish between idle and in use instance states' and a user was billed $583 for 391 hours of an idle GH200 instance, confirming the absence of this safeguard.

   • [community] “User left a Lambda Labs GH200 instance running after brief testing and was billed $583 for 391 hours. Lambda's support said: 'Lambda does no…”

   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

   Lambda!disputedcontradicted6/10

   Lambda's API and docs support programmatic launch/terminate of instances with per-minute billing (lambda-labs-docs-5, -10, -23, -31, -39, runtime probe confirms live REST API), but there's no documented stop/start (pause) capability distinct from terminate, and a hands-on community report shows billing continues for idle-but-running instances regardless of usage, contradicting 'pay only for what is running' in the sense of active workload — user was billed $583 for an idle instance because Lambda 'does not distinguish between idle and in use instance states' (lambda-labs-comm-1). missing for 10: documented stop/pause (vs. terminate) lifecycle action, confirmation that idle time is excluded from billing, independent corroboration beyond one HN anecdote.

   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “ODC prices instances by hourly usage and bills in one-minute increments.”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API. For details, see Launch instances”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “User left a Lambda Labs GH200 instance running after brief testing and was billed $583 for 391 hours. Lambda's support said: 'Lambda does no…”

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

   Lambda✓fullprobed8/10

   Lambda's docs and live API confirm on-demand GPU provisioning via console or REST API, with cloud-init, SSH, and JupyterLab access enabling immediate code execution, and pricing pages claim deployment 'in minutes.' A community-built CLI/MCP tool also independently confirms real users launching and SSHing into instances quickly. Missing for 10: independent benchmark/timing evidence validating the 'minutes' claim and first-hand confirmation of no friction in provisioning flow.

   • [claimed-docs] “Launch 16x to 512x NVIDIA H100 or B200 GPU clusters instantly, or start with a single-node instance. No long-term commitments.”
   • [claimed-docs] “You can also launch instances programmatically by using the Lambda Cloud API.”
   • [claimed-docs] “you can add launch-time configuration instructions using [cloud-init]”
   • [claimed-docs] “You can connect to your On-Demand Cloud (ODC) instances directly through SSH or by using the preinstalled JupyterLab server.”
   • [claimed-docs] “On-Demand Cloud (ODC) provides on-demand access to Linux-based, GPU-backed virtual machine instances.”
   • [claimed-docs] “Deploy NVIDIA B200, H100, A100, or GH200 instances in minutes with self-serve, first-come access.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “A developer built an unofficial CLI and MCP server for Lambda cloud GPU instances, enabling AI agents to find, launch, and terminate Lambda …”

   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

   Lambda—none0/10

   Lambda's documented products are on-demand VMs, 1-Click Clusters, Managed Kubernetes, and Managed Slurm — all provisioned/billed as running instances, not autoscaling serverless GPU functions. Community evidence explicitly confirms Lambda 'does not distinguish between idle and in use instance states' and bills continuously even when idle, the opposite of scale-to-zero behavior. No docs mention a serverless endpoint product or autoscale-to-zero deployment model.

   • [claimed-docs] “On-Demand Cloud (ODC) provides on-demand access to Linux-based, GPU-backed virtual machine instances.”
   • [claimed-docs] “ODC prices instances by hourly usage and bills in one-minute increments.”
   • [community] “User left a Lambda Labs GH200 instance running after brief testing and was billed $583 for 391 hours. Lambda's support said: 'Lambda does no…”

   proof ↗⚑ flag

Data movement

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

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

   Lambda✓fullprobed8/10

   Lambda documents an S3-compatible adapter for its filesystems, explicitly supporting rclone and s5cmd for copying data in/out, plus a REST Cloud API and cloud-init for programmatic/automated data and instance management. Missing for 10: no independent hands-on verification of transfer performance/reliability and no native cloud-storage sync service beyond the S3-compatible adapter.

   • [claimed-docs] “This adapter allows you to use S3-compatible tools like rclone and s5cmd to copy files to and from your filesystems and perform common file …”
   • [claimed-docs] “This adapter allows you to use S3-compatible tools like `rclone` and `s5cmd` to copy files to and from your filesystems”
   • [claimed-docs] “A filesystem is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”

   proof ↗⚑ flag

Storage

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

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

   Lambda✓fullclaimed8/10

   Lambda's docs explicitly describe attachable persistent filesystems ('high-capacity regional file store you can attach to your instance to store datasets and back up system state') that exist independently of any instance, plus S3-compatible tooling (rclone/s5cmd) for moving data in/out, directly matching the story of datasets/checkpoints surviving GPU teardown. missing for 10: no independent/hands-on confirmation of persistence across teardown or details on durability guarantees/pricing for the filesystem.

   • [claimed-docs] “A filesystem is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “A _filesystem_ is a high-capacity regional file store you can attach to your instance to store datasets and back up system state.”
   • [claimed-docs] “This adapter allows you to use S3-compatible tools like rclone and s5cmd to copy files to and from your filesystems and perform common file …”
   • [claimed-docs] “This adapter allows you to use S3-compatible tools like `rclone` and `s5cmd` to copy files to and from your filesystems”

   proof ↗⚑ flag

Images

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

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

   Lambda~partialclaimed6/10

   Lambda's docs show real support for custom environments: the Cloud API lets you launch instances with 'a different base image' (custom machine template) and cloud-init for launch-time configuration, plus GPU Base images for full control over the Python environment. Containerized workloads (i.e., running an actual Docker image) are supported via Managed Kubernetes (MK8s) rather than as a first-class ODC instance feature. Missing for 10: explicit first-party documentation of directly launching a Docker image as an ODC instance (vs. VM base image), a custom-image/AMI gallery, and independent hands-on confirmation that custom base images work as claimed.

   • [claimed-docs] “the API allows you to use a different base image for your instance”
   • [claimed-docs] “you can add launch-time configuration instructions using [cloud-init]”
   • [claimed-docs] “If you're launching your instance with the Lambda Cloud API, you can add launch-time configuration instructions using cloud-init”
   • [claimed-docs] “GPU Base: An image based on Ubuntu Server that includes a minimal set of key AI/ML tools and drivers... Use if: You want a minimal working s…”
   • [claimed-docs] “MK8s provides a Kubernetes environment with GPU and InfiniBand (RDMA) support, and shared persistent storage across all nodes in a 1CC.”
   • [claimed-docs] “MK8s provides a Kubernetes environment with GPU and InfiniBand (RDMA) support, and shared persistent storage across all nodes in a 1CC. Clus…”

   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

   Lambda~partialclaimed5/10

   Lambda's ODC instances preinstall 'Lambda Stack' (AI/ML drivers, tools, frameworks) and offer a 'GPU Base' minimal image, which covers PyTorch/CUDA-style ready environments, plus JupyterLab for quick start. However, there's no evidence of named pre-built templates for vLLM or ComfyUI specifically, only generic 'AI/ML tools and frameworks'. missing for 10: explicit vLLM template/image, explicit ComfyUI template/image, a documented template gallery/catalog beyond Lambda Stack and GPU Base.

   • [claimed-docs] “Lambda also preinstalls Lambda Stack, a standard set of AI/ML-related drivers, tools, and frameworks, on the instance”
   • [claimed-docs] “GPU Base: An image based on Ubuntu Server that includes a minimal set of key AI/ML tools and drivers.”
   • [claimed-docs] “GPU Base: An image based on Ubuntu Server that includes a minimal set of key AI/ML tools and drivers... Use if: You want a minimal working s…”
   • [claimed-docs] “each ODC instance provides a JupyterLab installation for creating and managing Jupyter notebooks”

   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

   Lambda—none0/10

   No evidence in the pack addresses SOC 2 certification, compliance attestations, data handling policies, or datacenter tier ratings for Lambda's cloud offerings; the docs focus entirely on GPU provisioning, clusters, filesystems, and API usage. This is a fair, applicable question for any cloud infrastructure provider hosting proprietary models, but no supporting documentation exists in the evidence pack.

   ⚑ flag

Governance

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

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

   Lambda—none0/10

   The evidence pack documents instance provisioning, filesystems, firewalls, and a key-gated REST API, but contains no mention of team/member management, role-based access control, or scoped/restricted API keys for spend control. The billing complaint (lambda-labs-comm-1) actually highlights a lack of granular usage controls rather than confirming governance features.

   • [claimed-docs] “The Lambda Cloud API provides a set of REST API endpoints you can use to create and manage your Lambda Cloud resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): https://cloud.lambda.ai/api/v1/openapi.json serves the full Lambda Cloud API OpenAPI 3.1 spec (title 'L…”
   • [community] “User left a Lambda Labs GH200 instance running after brief testing and was billed $583 for 391 hours. Lambda's support said: 'Lambda does no…”

   proof ↗⚑ flag