Runpod vs CoreWeave

Ide

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

   weight 1 · round to Runpod
   Runpod✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod✓fullcommunity7/10

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

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

   proof ↗⚑ flag

   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 drawn
   Runpod✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Runpod~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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 to Runpod
   Runpod~partialprobed4/10

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to CoreWeave
   Runpod—none0/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod~partialcommunity4/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to CoreWeave
   Runpod—none0/10

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod~partialprobed7/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod~partialprobed4/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Runpod—none0/10

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

   ⚑ flag

   CoreWeave—none0/10

   No evidence in the pack addresses telemetry opt-out or usage-tracking controls; the docs cover infrastructure, clusters, storage, and billing but nothing about user-level telemetry preferences. Missing for 10: any documentation of a telemetry/analytics opt-out setting, privacy controls dashboard, or usage-tracking disclosure.

   ⚑ flag

Agent ops

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

   weight 3 · round to Runpod
   Runpod✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   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 Runpod
   Runpod✓fullcommunity9/10

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

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

   proof ↗⚑ flag

   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 to Runpod
   Runpod~partialcommunity5/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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