Lambda vs CoreWeave

Ide

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

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

   CoreWeave—none0/10

   Evidence shows CoreWeave provisions bare-metal Kubernetes clusters, kubeconfig access, and Terraform/API management, but there is no mention of Jupyter notebooks, VS Code/Cursor remote-connect integration, or any one-step IDE/notebook connection workflow; developers would need to manually deploy and configure such tooling themselves via generic Kubernetes primitives.

   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [claimed-docs] “CoreWeave Kubernetes Service (CKS) offers a managed Kubernetes service that lets you run clusters on bare metal servers in CoreWeave Cloud.”
   • [claimed-docs] “CKS runs Kubernetes directly on bare metal Nodes, without a hypervisor. Customer clusters don't run Virtual Machines.”

   proof ↗⚑ flag

Networking

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

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

   CoreWeave—none0/10

   Evidence covers Kubernetes cluster management, node pools, storage, and Terraform/API access, but there is no mention of exposing ports/ingress for serving applications or of private networking/VPC connectivity between instances. Missing for 10: documentation on ingress/port exposure for serving apps, VPC or private networking setup between instances, and any hands-on confirmation of connectivity features.

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

   CoreWeave—none0/10

   CoreWeave's documented access model is Kubernetes-native (kubeconfig + API tokens via CKS) rather than traditional SSH-with-your-own-keys into a GPU instance; no docs mention SSH key injection, root shell access, or instance-level SSH at all — access is described purely in terms of kubectl/API authentication to clusters running on bare metal without VMs.

   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [claimed-docs] “CKS runs Kubernetes directly on bare metal Nodes, without a hypervisor. Customer clusters don't run Virtual Machines.”
   • [claimed-docs] “This page explains how to create, use, and manage API Access Tokens and the kubeconfig files generated alongside them, so you can authentica…”
   • [claimed-docs] “API Access Tokens authenticate users and grant access to resources such as CKS clusters and VPCs.”

   proof ↗⚑ flag

Agent access

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

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

   CoreWeave✓fullprobed9/10

   Direct probe confirms an llms.txt file is live at docs.coreweave.com/llms.txt with structured agent-oriented summary and links, and a companion MCP endpoint further confirms agent-reachable documentation. Missing for 10: independent third-party confirmation beyond the vendor's own probe/docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.coreweave.com/llms.txt # CoreWeave Docs > Learn how to deploy, manage, and observe your AI trainin…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.coreweave.com/mcp completed a FULL keyless JSON-RPC initialize hands…”

   proof ↗⚑ flag

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

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

   CoreWeave✓fullprobed7/10

   CoreWeave provides a full REST API (Bearer-token gated, confirmed live via probe) for cluster/resource management, a Terraform provider for IaC, and kubeconfig/kubectl access, all of which support headless CI/automation workflows. missing for 10: no dedicated CI/CD pipeline examples (e.g., GitHub Actions integration) or first-party automation SDKs beyond generated API clients, and no independent hands-on report confirming a full CI pipeline running against CoreWeave.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [claimed-docs] “All API requests must include a CoreWeave API access token in the Authorization header as a Bearer token.”
   • [claimed-docs] “Use the CoreWeave Terraform provider in your OpenTofu configuration.”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

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

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

   CoreWeave~partialprobed6/10

   A probe confirms CoreWeave operates a live, keyless MCP server at docs.coreweave.com/mcp that completes a JSON-RPC initialize handshake and exposes search/retrieval tools over its documentation, so an agent can officially connect via MCP. However, this MCP server only covers documentation search rather than actual platform management (clusters, node pools, inference), and there is no first-party doc page describing it or independent community verification beyond the probe. Missing for 10: a documented/announced MCP server (not just a discovered endpoint), MCP tools that let an agent actually operate CoreWeave resources (not just search docs), and independent community corroboration.

   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.coreweave.com/mcp completed a FULL keyless JSON-RPC initialize hands…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.coreweave.com/llms.txt # CoreWeave Docs > Learn how to deploy, manage, and observe your AI trainin…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   CoreWeave—none0/10

   CoreWeave's docs describe API access tokens, a Terraform/OpenTofu provider, generated gRPC/Connect clients, and kubectl via kubeconfig, but no evidence of a dedicated official CoreWeave CLI tool exists in the pack.

   ⚑ flag

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

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

   CoreWeave✓fullprobed9/10

   CoreWeave documents a public REST/gRPC API for CKS clusters and Inference (create/list/update/delete), Bearer-token auth, generated clients in multiple languages, and a Terraform provider for IaC control — and a live runtime probe confirms the CKS API endpoint is reachable and Bearer-gated exactly as documented. missing for 10: independent third-party hands-on API usage reports/tutorials beyond CoreWeave's own docs.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “All API requests must include a CoreWeave API access token in the Authorization header as a Bearer token.”
   • [claimed-docs] “Clients are available for the Connect, gRPC, and Protobuf ecosystems across languages including Go, Python, TypeScript, Java, Kotlin, Rust, …”
   • [claimed-docs] “The CoreWeave Inference API provides programmatic control over inference gateways, model deployments, and capacity claims.”
   • [claimed-docs] “You can call the Inference API over several transport protocols, depending on your client tooling and performance needs”
   • [claimed-docs] “you can install a generated client instead of writing HTTP calls by hand.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

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

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

   CoreWeave—none0/10

   CoreWeave documents API Access Tokens for authenticating to clusters/VPCs (coreweave-docs-8, coreweave-docs-17, coreweave-docs-26), but there is no evidence of scoped, least-privilege, or role-based permission configuration for these tokens — nothing describing granular scopes, IAM-style policies, or agent-specific credential issuance. missing for 10: documentation of configurable token scopes/permissions, role-based access control, or any mechanism to restrict a credential to a minimal set of actions for an autonomous agent.

   • [claimed-docs] “All API requests must include a CoreWeave API access token in the Authorization header as a Bearer token.”
   • [claimed-docs] “API Access Tokens authenticate users and grant access to resources such as CKS clusters and VPCs.”
   • [claimed-docs] “This page explains how to create, use, and manage API Access Tokens and the kubeconfig files generated alongside them, so you can authentica…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   CoreWeave✓fullprobed7/10

   CoreWeave documents official generated clients for its Inference API across Connect/gRPC/Protobuf ecosystems in Go, Python, TypeScript, Java, Kotlin, Rust, and Swift, plus a first-party Terraform/OpenTofu provider and token-gated REST APIs for CKS and inference, all directly supporting AI-native programmatic/SDK access. Missing for 10: independent/hands-on developer corroboration of SDK quality, and explicit links to public SDK repos or version/release info.

   • [claimed-docs] “Clients are available for the Connect, gRPC, and Protobuf ecosystems across languages including Go, Python, TypeScript, Java, Kotlin, Rust, …”
   • [claimed-docs] “you can install a generated client instead of writing HTTP calls by hand.”
   • [claimed-docs] “You can call the Inference API over several transport protocols, depending on your client tooling and performance needs”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “Use the CoreWeave Terraform provider in your OpenTofu configuration.”
   • [claimed-docs] “The CoreWeave Inference API provides programmatic control over inference gateways, model deployments, and capacity claims.”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   CoreWeave—none0/10

   No evidence anywhere in the pack of a webhook subscription mechanism or event-driven notification system in CoreWeave's API or platform; the evidence covers cluster management, storage, inference API, and Terraform but nothing about webhooks or event subscriptions.

   ⚑ flag

Agentic features

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

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

   CoreWeave—none0/10

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

   ⚑ flag

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

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

   CoreWeave—none0/10

   CoreWeave's documented interfaces are structured (Cloud Console, Terraform/OpenTofu, REST/gRPC API, kubectl) with no evidence of a natural-language command interface for operating clusters, node pools, or inference deployments. The MCP endpoint only exposes documentation search/retrieval tools, not natural-language operation of the platform itself.

   • [claimed-docs] “You can create a cluster with the Cloud Console or with Terraform.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.coreweave.com/mcp completed a FULL keyless JSON-RPC initialize hands…”

   proof ↗⚑ flag

Api quality

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

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

   CoreWeave—none0/10

   The evidence shows static API reference docs (CKS API, Inference API) and client libraries, but nothing describes an interactive, runnable API explorer (e.g., a 'try it' console or embedded runnable code samples). Absence of such evidence for an applicable capability (API reference documentation) yields none.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “The CoreWeave Inference API provides programmatic control over inference gateways, model deployments, and capacity claims.”
   • [claimed-docs] “You can call the Inference API over several transport protocols, depending on your client tooling and performance needs”
   • [claimed-docs] “you can install a generated client instead of writing HTTP calls by hand.”

   proof ↗⚑ flag

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

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

   CoreWeave—none0/10

   The evidence pack documents REST/gRPC/Protobuf APIs (CKS API, Inference API) and generated client libraries, but nowhere mentions an OpenAPI/Swagger spec or any downloadable machine-readable schema file that an AI agent could ingest directly.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “Clients are available for the Connect, gRPC, and Protobuf ecosystems across languages including Go, Python, TypeScript, Java, Kotlin, Rust, …”
   • [claimed-docs] “The CoreWeave Inference API provides programmatic control over inference gateways, model deployments, and capacity claims.”
   • [claimed-docs] “you can install a generated client instead of writing HTTP calls by hand.”
   • [claimed-docs] “You can call the Inference API over several transport protocols, depending on your client tooling and performance needs”

   proof ↗⚑ flag

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

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

   CoreWeave—none0/10

   CoreWeave's evidence covers cluster/node-pool creation, autoscaling, storage, and Terraform/API management, but nothing describes a dedicated sandbox/test environment or a mechanism to isolate test workloads from production data. While a customer could theoretically stand up a separate cluster, no docs, tutorials, or examples describe this as a supported 'sandbox vs production' workflow.

   • [claimed-docs] “You can create a cluster with the Cloud Console or with Terraform.”
   • [claimed-docs] “You can deploy multiple Node Pools within a single cluster, where each Node Pool contains any number of Nodes.”
   • [claimed-docs] “You can deploy multiple Node Pools within a single cluster, where each Node Pool contains any number of Nodes. This lets you run different t…”

   proof ↗⚑ flag

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

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

   CoreWeave—none0/10

   The evidence pack documents CoreWeave's various APIs (CKS API, Inference API, Terraform provider) but contains no mention of API versioning scheme or a documented deprecation policy anywhere in the docs or community sources.

   ⚑ flag

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

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

   CoreWeave~partialclaimed5/10

   CoreWeave's API and Terraform provider let you create/list/update/delete clusters, node pools, and other infra as code, which supports scripted bulk provisioning across many resources, and autoscaling lets node pools scale in bulk with demand. However, there is no explicit 'bulk operation' endpoint, batch API, or documented way to perform multi-item operations (e.g., bulk delete/update across many storage objects or inference deployments) in a single call — missing for 10: dedicated batch/bulk API endpoints, documented bulk operations for storage/inference resources, and independent evidence of large-scale bulk usage.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler...letting you scale CKS Node Pools in response to workload demand…”
   • [claimed-docs] “You can deploy multiple Node Pools within a single cluster, where each Node Pool contains any number of Nodes. This lets you run different t…”
   • [claimed-docs] “Use the CoreWeave Terraform provider in your OpenTofu configuration.”

   proof ↗⚑ flag

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

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

   CoreWeave—none0/10

   CoreWeave's docs only describe fixed Kubernetes Cluster Autoscaler behavior reacting to resource demand, not a general-purpose rules/automation engine where users define custom event-trigger-action logic; no evidence of webhooks, alert-based actions, or configurable automation rules.

   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler...letting you scale CKS Node Pools in response to workload demand…”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler, letting you scale CKS Node Pools in response to workload demands…”
   • [claimed-docs] “letting you scale CKS Node Pools in response to workload demands for GPU, CPU, or memory resources”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   CoreWeave—none0/10

   Evidence describes cluster provisioning, node pools, autoscaling, Slurm-on-Kubernetes (SUNK) for training/inference jobs, and Terraform/API management, but nothing documents recurring job scheduling, cron-style triggers, or workflow orchestration primitives for automating repeated runs.

   ⚑ flag

Availability

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

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

   CoreWeave~partialclaimed5/10

   CoreWeave documents a 'Capacity Finder' tool that lets users compare placement availability across zones for a requested instance type and node count before creating a Spot Node Pool, plus quota visibility/error reporting in the Cloud Console — this directly supports pre-provisioning availability checks. However, evidence is limited to Spot Node Pools and doesn't clearly show real-time GPU availability by type/region across all provisioning paths (e.g., on-demand reserved instances), and there's no independent/hands-on confirmation of accuracy or granularity. missing for 10: broader coverage beyond Spot pools (on-demand/reserved capacity visibility), independent verification that Capacity Finder prevents stockouts in practice, API/programmatic access to availability data, and region-level (not just zone-level) granularity confirmation.

   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [claimed-docs] “use Capacity Finder in the Cloud Console to compare placement availability across Zones for your requested instance type and Node count”
   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”
   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”

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

   CoreWeave—none0/10

   The evidence pack covers CKS node pools, autoscaling, spot/on-demand pricing, and capacity finder across 'instance types' and 'Zones,' but never names specific GPU models or generations (H100/H200/B200 or older SKUs) nor confirms a menu of current- vs previous-generation GPU choices. Without any explicit mention of GPU SKU/generation selection, this applicable capacity-availability axis has no supporting evidence.

   ⚑ flag

Quotas

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

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

   CoreWeave✓fullclaimed8/10

   CoreWeave docs explicitly cover viewing quotas in the Cloud Console, interpreting quota-exceeded errors, and requesting capacity increases, plus a Capacity Finder tool to check placement availability before requesting Spot Node Pools. Missing for 10: independent/hands-on corroboration of the request process turnaround or SLA, and no detail on approval workflow specifics.

   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [claimed-docs] “use Capacity Finder in the Cloud Console to compare placement availability across Zones for your requested instance type and Node count”
   • [claimed-docs] “A Node Pool in CKS represents one or more instances that share a common configuration, such as the same labels, taints, and annotations.”

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

   CoreWeave~partialprobed6/10

   CoreWeave documents self-service provisioning of multi-node GPU clusters via Console, Terraform, and API (docs-1,5,6,28), with Node Pools spanning many nodes, autoscaling, and Spot capacity available 'without long-term commitments or reservations' (docs-4,15,16,20,23) — all consistent with no-sales-cycle self-service. However, the evidence pack never explicitly mentions fast interconnect (e.g., InfiniBand/NVLink) specs, and quota pages imply some capacity increases require a request process (docs-12) which could reintroduce a sales-like step. missing for 10: explicit fast-interconnect/networking specs for multi-node training, and clearer confirmation that quota/capacity requests bypass sales entirely.

   • [claimed-docs] “You can create a cluster with the Cloud Console or with Terraform.”
   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”
   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “You can deploy multiple Node Pools within a single cluster, where each Node Pool contains any number of Nodes. This lets you run different t…”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler, letting you scale CKS Node Pools in response to workload demands…”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

Orchestration

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

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

   CoreWeave✓fullclaimed8/10

   CoreWeave offers CKS as managed Kubernetes on bare metal with autoscaling node pools, and SUNK lets platform engineers run managed Slurm jobs inside that same Kubernetes cluster, directly delivering scheduling without building custom schedulers on raw nodes. missing for 10: independent/hands-on validation of Slurm-on-K8s (SUNK) at scale beyond CoreWeave's own docs, and details on job-queue features (priorities, preemption) comparable to a full HPC scheduler.

   • [claimed-docs] “Run training and inference workloads on the same cluster by running Slurm jobs inside Kubernetes.”
   • [claimed-docs] “Run training and inference workloads on the same cluster by running Slurm jobs inside Kubernetes. Share the same compute resources between w…”
   • [claimed-docs] “SUNK enables its users to do the following: Run training and inference workloads on the same cluster by running Slurm jobs inside Kubernetes…”
   • [claimed-docs] “CoreWeave Kubernetes Service (CKS) offers a managed Kubernetes service that lets you run clusters on bare metal servers in CoreWeave Cloud.”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler...letting you scale CKS Node Pools in response to workload demand…”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler, letting you scale CKS Node Pools in response to workload demands…”
   • [claimed-docs] “CKS runs Kubernetes directly on bare metal Nodes, without a hypervisor. Customer clusters don't run Virtual Machines.”

   proof ↗⚑ flag

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

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

   CoreWeave~partialprobed6/10

   CoreWeave documents a broad API (CKS cluster CRUD, Terraform provider covering CKS/VPC/storage/inference, Inference API for gateways/deployments/capacity) confirmed live via a runtime probe (401 Bearer-gated), and notes some UI-only helpers like Capacity Finder that lack a documented API equivalent. Not all Cloud Console features (e.g., billing insights, quota views, Capacity Finder) are explicitly confirmed as API-accessible, so full UI/API parity isn't demonstrated. missing for 10: explicit API endpoints for billing insights/quota viewing, explicit API equivalent for Capacity Finder, independent third-party confirmation of full UI/API parity.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “The CoreWeave Inference API provides programmatic control over inference gateways, model deployments, and capacity claims.”
   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”
   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [claimed-docs] “use Capacity Finder in the Cloud Console to compare placement availability across Zones for your requested instance type and Node count”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

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

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

   CoreWeave~partialclaimed3/10

   CoreWeave's object storage is S3-compatible (open standard) and infrastructure is managed via open Terraform/OpenTofu configs and standard kubeconfig/kubectl access, which support some data/infra portability, but there is no explicit documented 'export all your data' tool or account-exit workflow. missing for 10: a dedicated bulk data-export feature, documentation of exporting model weights/configs/billing history in open formats, and any statement about facilitating full account migration/leave.

   • [claimed-docs] “Store training data, checkpoints, and model weights with efficient S3-compatible access directly to your GPU compute resources.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “Use the CoreWeave Terraform provider in your OpenTofu configuration.”
   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”

   proof ↗⚑ flag

Billing

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

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

   CoreWeave~partialclaimed4/10

   Docs mention a Billing Insights view for consumption breakdowns by resource type (coreweave-docs-13), but there is no evidence of a programmatic API/export for pulling usage or billing data, nor any mention of attributing spend by team, project, or workload tags. missing for 10: documented billing/usage API or export endpoint, evidence of team/workload-level cost attribution or tagging, and any programmatic (non-console) access to billing data.

   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”

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

   CoreWeave—none0/10

   Docs mention pay-as-you-go, on-demand/spot capacity, and billing insights showing usage breakdowns, but no evidence specifies per-second or per-minute billing granularity or confirms billing only occurs while instances are actively running.

   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”

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

   CoreWeave—none0/10

   Evidence shows a public pricing page and Capacity Finder UI for availability, but no documented/public API endpoint that returns live GPU catalog pricing and availability programmatically for an agent to query before committing spend.

   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [claimed-docs] “use Capacity Finder in the Cloud Console to compare placement availability across Zones for your requested instance type and Node count”
   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”

   proof ↗⚑ flag

Pricing

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

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

   CoreWeave—none0/10

   Evidence mentions on-demand and spot capacity (no long-term commitment) and references a 'capacity-plans' section, but no doc excerpt describes reserved or committed-use discount pricing, contract terms, or commitment tiers for platform engineers to lock in.

   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”

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

   CoreWeave—none0/10

   The only pricing-related evidence is a marketing snippet from coreweave.com/pricing touting 'flexibility of great pricing' for on-demand/spot GPUs, but no evidence shows an actual published per-GPU-hour price table or rate card visible without contacting sales.

   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”

   proof ↗⚑ flag

Spot

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

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

   CoreWeave~partialclaimed4/10

   CoreWeave docs confirm Spot Node Pools exist as pay-as-you-go, no-commitment bare-metal capacity with a Capacity Finder tool to check availability, but the evidence never documents actual preemption semantics (notice period, eviction behavior, discount percentage vs on-demand) that an ML engineer would need to plan around interruptions. Missing for 10: documented eviction/notice mechanics, explicit discount pricing tied to spot vs on-demand, and any hands-on or independent confirmation of how preemption actually behaves.

   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [claimed-docs] “use Capacity Finder in the Cloud Console to compare placement availability across Zones for your requested instance type and Node count”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”

   proof ↗⚑ flag

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

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

   CoreWeave—none0/10

   The evidence describes CoreWeave's compute 'Zones' for GPU capacity placement (docs-23, docs-31) but never documents a customer-facing region/residency selection control for data storage (e.g., choosing a region for AI Object Storage or CKS clusters) or any data-residency compliance guarantees.

   ⚑ flag

2. ai-native userControl data retention and deletion

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

   CoreWeave—none0/10

   Evidence shows CoreWeave APIs can delete clusters/resources (coreweave-docs-5) but there's no documentation of data retention policies, data deletion guarantees for stored training data/checkpoints, or privacy controls governing customer data lifecycle — the core of the story is unaddressed.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “Store training data, checkpoints, and model weights with efficient S3-compatible access directly to your GPU compute resources.”

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

   CoreWeave~partialprobed6/10

   CoreWeave documents a REST API (verified live and Bearer-token-gated in probe) and Terraform provider for creating/listing/updating/deleting CKS clusters (GPU node pools), plus Kubernetes-native monitoring, autoscaling, and quota/billing visibility, all of which an agent could drive without a human touching the Console. However, the MCP endpoint found is only for docs search/retrieval, not for provisioning or lifecycle actions, and there's no CLI or agent-specific tooling documented beyond kubectl/Terraform/API — full automated teardown and monitoring loop is implied but not shown end-to-end in a single agent-facing workflow. missing for 10: an agent-oriented CLI, an MCP server exposing actual provisioning/monitor/teardown actions (not just doc search), and a documented single end-to-end agent workflow example tying create→monitor→run→delete together.

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [claimed-docs] “All API requests must include a CoreWeave API access token in the Authorization header as a Bearer token.”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler...letting you scale CKS Node Pools in response to workload demand…”
   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”
   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.coreweave.com/mcp completed a FULL keyless JSON-RPC initialize hands…”

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

   CoreWeave—none0/10

   Evidence shows quota management and billing usage dashboards (coreweave-docs-12, coreweave-docs-13), but nothing about auto-shutdown timers, idle-instance termination, or configurable spend limits/budget alerts that would stop a forgotten instance from running up costs.

   • [claimed-docs] “This page shows you how to view your quotas in the Cloud Console, how to read quota errors when a Node Pool exceeds its quota, and how to re…”
   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”

   proof ↗⚑ flag

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

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

   CoreWeave~partialprobed6/10

   CoreWeave's CKS API supports programmatic create/list/update/delete of clusters and Node Pools, autoscaling to grow/shrink capacity, and Spot Node Pools are explicitly pay-as-you-go with no commitment, and billing dashboards show usage-based consumption — a live runtime probe even confirms the create/list/delete API is reachable and token-gated. However, the story asks specifically about start/stop/restart of individual instances, and evidence only documents cluster/node-pool-level create, delete, and autoscale operations rather than explicit stop/start/restart semantics for a single running instance. Missing for 10: explicit instance-level start/stop/restart API or docs (only pool-level scale/create/delete and Spot on-demand billing are evidenced).

   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler...letting you scale CKS Node Pools in response to workload demand…”
   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”
   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

Provision

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

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

   CoreWeave~partialprobed6/10

   CoreWeave documents Console/Terraform/API provisioning of Spot and On-Demand Node Pools with kubeconfig-based access to run kubectl/code, and the API is confirmed live and Bearer-token-gated by a runtime probe. However, provisioning is framed around Kubernetes clusters/Node Pools rather than a single quick 'instance' spin-up, and there is no first-party or independent evidence of actual end-to-end timing (minutes) or a simple single-VM/instance API akin to typical cloud on-demand GPU flows. missing for 10: evidence of a simple single-instance (non-cluster) on-demand GPU provisioning path, documented/observed time-to-running-code, and independent hands-on confirmation of the 'minutes' claim.

   • [claimed-docs] “You can create a cluster with the Cloud Console or with Terraform.”
   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”
   • [claimed-docs] “The API lets you create, list, update, and delete managed Kubernetes clusters on CoreWeave infrastructure.”
   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [claimed-docs] “Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your request…”
   • [probe] “PROBE runtime (recorded 2026-09-05): a bare GET to the documented CKS provisioning API https://api.coreweave.com/v1beta1/cks/clusters answer…”

   proof ↗⚑ flag

Serverless

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

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

   CoreWeave—none0/10

   CoreWeave's documented autoscaling is Kubernetes Cluster Autoscaler scaling Node Pools/bare-metal instances up/down with demand (coreweave-docs-3, coreweave-docs-16, coreweave-docs-30), and Spot/On-Demand node pools for burst capacity (coreweave-docs-4, coreweave-docs-20) — this is infrastructure-level cluster scaling, not a serverless 'deploy code and it scales to zero' abstraction. No evidence describes a serverless function/endpoint product, a scale-to-zero guarantee, or a developer simply pushing code without managing nodes/pools.

   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler...letting you scale CKS Node Pools in response to workload demand…”
   • [claimed-docs] “Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations.”
   • [claimed-docs] “CKS supports scaling Node Pools by using the Kubernetes Cluster Autoscaler, letting you scale CKS Node Pools in response to workload demands…”
   • [claimed-docs] “Utilize on-demand GPU instances for additional workloads when you're not looking for long-term capacity commitments. Quickly spin-up burst O…”
   • [claimed-docs] “letting you scale CKS Node Pools in response to workload demands for GPU, CPU, or memory resources”

   proof ↗⚑ flag

Data movement

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

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

   CoreWeave~partialclaimed6/10

   CoreWeave documents S3-compatible Object Storage for moving training data, checkpoints, and model weights directly to GPU compute (coreweave-docs-10), plus a Terraform provider for managing storage buckets/policies as code (coreweave-docs-6). However, there is no documentation of cloud-storage sync tooling (e.g., rsync-like utilities, cross-cloud migration tools) or a dedicated CLI/SDK specifically for bulk data transfer beyond generic S3 API compatibility. missing for 10: dedicated data-migration/sync tooling, third-party or first-party CLI examples for bulk transfer, independent hands-on verification of transfer performance/throughput claims.

   • [claimed-docs] “Store training data, checkpoints, and model weights with efficient S3-compatible access directly to your GPU compute resources.”
   • [claimed-docs] “The CoreWeave Terraform provider lets you manage CoreWeave infrastructure as code, including CKS clusters, VPC networking, AI Object Storage…”
   • [claimed-docs] “All API requests must include a CoreWeave API access token in the Authorization header as a Bearer token.”

   proof ↗⚑ flag

Storage

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

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

   CoreWeave~partialclaimed5/10

   Docs confirm S3-compatible object storage for persisting training data, checkpoints, and model weights independent of GPU compute (coreweave-docs-10), which satisfies the 'outlives any single GPU rental' need, but there's no explicit evidence of attachable persistent block/network volumes (e.g., Kubernetes PersistentVolumes or NFS-style storage) for CKS nodes specifically surviving instance teardown. missing for 10: documentation of block/network-attached persistent volumes for CKS nodes, PVC/storage-class details, and independent confirmation of data survival across instance teardown.

   • [claimed-docs] “Store training data, checkpoints, and model weights with efficient S3-compatible access directly to your GPU compute resources.”

   proof ↗⚑ flag

Images

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

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

   CoreWeave~partialclaimed3/10

   CKS is described as a managed Kubernetes service running directly on bare metal, which implies workloads (including custom Docker containers) can be deployed, but the evidence never explicitly documents how to submit a custom Docker image or create a custom machine/VM template with a specific environment. missing for 10: explicit docs on deploying custom container images to CKS, and any mention of custom machine templates/VM image support.

   • [claimed-docs] “CKS runs Kubernetes directly on bare metal Nodes, without a hypervisor. Customer clusters don't run Virtual Machines.”
   • [claimed-docs] “CoreWeave Kubernetes Service (CKS) offers a managed Kubernetes service that lets you run clusters on bare metal servers in CoreWeave Cloud.”
   • [claimed-docs] “You can deploy multiple Node Pools within a single cluster, where each Node Pool contains any number of Nodes. This lets you run different t…”

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

   CoreWeave—none0/10

   The evidence pack covers CKS cluster/node-pool management, Terraform, storage, Slurm-on-K8s, and API access tokens, but contains no mention of pre-built ML environment templates or container images for PyTorch, CUDA, vLLM, or ComfyUI that a developer could launch directly. This is a fair axis for a GPU cloud platform, but no supporting evidence exists.

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

   CoreWeave—none0/10

   The evidence pack contains no mention of SOC 2 certification, compliance attestations, data handling/privacy policies, or datacenter tier certifications; it only covers infrastructure/API features (CKS, Terraform, autoscaling, tokens) and unrelated financial/community discussion. Missing for 10: SOC 2 or ISO certifications, data handling/privacy documentation, physical datacenter tier/uptime certifications, any compliance trust page or audit report.

   ⚑ flag

Governance

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

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

   CoreWeave~partialclaimed4/10

   CoreWeave documents API Access Tokens that authenticate and scope access to specific resources (CKS clusters, VPCs) and billing insight views, showing some credential and spend visibility, but there is no evidence of team-member/user role management (RBAC for humans, org roles, or permission tiers) or spend controls/limits tied to specific keys. missing for 10: team member/role management (invite users, assign roles), scoped-key permission granularity beyond resource type, and spend-limiting or budget-control features tied to API keys.

   • [claimed-docs] “API Access Tokens authenticate users and grant access to resources such as CKS clusters and VPCs.”
   • [claimed-docs] “This page explains how to create, use, and manage API Access Tokens and the kubeconfig files generated alongside them, so you can authentica…”
   • [claimed-docs] “Create and download a kubeconfig for a specific cluster, so you can interact with the cluster using commands like kubectl.”
   • [claimed-docs] “Billing insights: View billable resource usage and consumption breakdowns by resource type.”

   proof ↗⚑ flag