CoreWeave vs Paperspace

Ide

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

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

   Paperspace!disputedcontradicted4/10

   Paperspace ships a native web-based Jupyter Notebooks product and documents SSH access with 'bring your own key, full root access' to Machines, which in principle supports VS Code Remote-SSH style connections, but there is no documentation of a genuine one-step IDE handshake (e.g., no VS Code/Cursor-specific integration, devcontainer, or remote-SSH config generator). A first-hand community report directly contradicts the 'easy SSH' claim, saying getting SSH access to Paperspace Core VMs was 'an uphill battle' with a 'confusing GUI' instead. missing for 10: explicit VS Code/Cursor one-click connect docs, evidence of an SSH config/remote extension workflow, and independent confirmation that SSH setup is actually fast/frictionless.

   • [claimed-docs] “Notebooks are a web-based Jupyter IDE with shared persistent storage for long-term development and inter-notebook collaboration, backed by a…”
   • [claimed-docs] “You can connect to your Linux or Windows-based machine using the Paperspace console or desktop app using SSH connection.”
   • [claimed-docs] “Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “Root access, connect with SSH Bring your SSH key and connect directly to your VM with full root access.”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

   proof ↗⚑ flag

Networking

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

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

   Paperspace~partialclaimed5/10

   Docs confirm private networking between machines (shared drives across a private network in paperspace-docs-4) and an option to enable a 'private network' or 'public IP address' when creating a machine (paperspace-docs-25), plus SSH/root access to instances (paperspace-docs-12/19/21). However, there is no explicit documentation of exposing arbitrary application ports or firewall/port-forwarding configuration for serving apps beyond SSH; 'Deployments' (containers-as-a-service, paperspace-docs-8) hints at serving models but isn't tied to port exposure or private networking specifics. missing for 10: explicit port-exposure/firewall configuration docs, hands-on confirmation of connecting instances over private network for app traffic, and any independent corroboration of these networking features working as described.

   • [claimed-docs] “Shared drives provide storage that is accessible from multiple machines in a private network.”
   • [claimed-docs] “When you create a new machine, you choose your machine type, operating system or custom template, disk size, region, authentication, startin…”
   • [claimed-docs] “Deployments are containers-as-a-service that let you run container images and serve machine learning models.”
   • [claimed-docs] “Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “Root access, connect with SSH Bring your SSH key and connect directly to your VM with full root access.”

   proof ↗⚑ flag

Ssh

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

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

   Paperspace!disputedcontradicted5/10

   Paperspace's marketing explicitly promises 'bring your own SSH key' with full root access to the VM, and DigitalOcean docs describe SSH-based connection to machines, but a hands-on community report states that SSH access on Paperspace's Core VMs was 'an uphill battle' with a 'pointless virtual console and confusing GUI' instead of easy SSH, contradicting the frictionless claim. missing for 10: independent confirmation that SSH access works smoothly as advertised, and no rebuttal to the community complaint about SSH being hard to obtain.

   • [claimed-docs] “Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “Root access, connect with SSH Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “Root access, connect with SSH... Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “You can connect to your Linux or Windows-based machine using the Paperspace console or desktop app using SSH connection.”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

   proof ↗⚑ flag

Agent access

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

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

   Paperspace~partialprobed5/10

   The Paperspace docs live under docs.digitalocean.com, and that domain does serve a working llms.txt (HTTP 200) with a general description of DigitalOcean's documentation corpus, giving agents a discoverable entry point. However, a direct markdown/agent-friendly version of the Paperspace-specific docs page 404s, and there's no evidence the llms.txt specifically indexes or highlights Paperspace content vs. the broader DigitalOcean product catalog. Missing for 10: Paperspace-specific agent-readable docs (e.g. .md endpoint), confirmation llms.txt references Paperspace pages, and any documentation stating this is an intentional agent-onboarding feature.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.digitalocean.com/llms.txt # DigitalOcean Documentation > Comprehensive tutorials, references, exam…”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.digitalocean.com/products/paperspace/.md”

   proof ↗⚑ flag

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

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

   Paperspace~partialprobed6/10

   Paperspace exposes a REST API, JS SDK, and a working CLI (pspace) that can create/manage machines, deployments, and templates non-interactively, and Workflows offers pipeline-style automation — enough to script headless usage in CI. However there's no first-party CI-integration guide (e.g. GitHub Actions), no documented service-account/non-interactive auth flow for CI runners, and community feedback flags friction around SSH/API access reliability and product quality, so full CI-native support isn't clearly evidenced. missing for 10: documented CI/CD integration examples, non-interactive/service-account auth for automation, independent confirmation of reliable headless workflows in CI pipelines.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [claimed-docs] “Workflows automate machine learning tasks, combining GPU instances with an expressive syntax to generate production-ready machine learning p…”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

   proof ↗⚑ flag

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

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

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

4. ai-native userUse an official CLI

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

   Paperspace✓fullprobed8/10

   Paperspace ships an official CLI (pspace), documented in DigitalOcean docs and independently verified via a runtime probe showing successful install and functional commands for machines, templates, autoscaling, and deployments. missing for 10: independent third-party review specifically praising CLI agentic workflows, and no evidence of AI-native scripting/automation examples beyond basic resource management.

   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”

   proof ↗⚑ flag

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

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

   Paperspace✓fullprobed8/10

   Paperspace documents a Core RESTful API, JavaScript SDK, and CLI for programmatically managing machines, notebooks, deployments, and workflows, and a runtime probe confirms the official pspace CLI installs and works with commands for machine/deployment management. Missing for 10: no public OpenAPI/swagger spec found, no independent third-party corroboration of API robustness beyond docs.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.digitalocean.com/openapi.json, https://docs.digitalocean.com/swagger.json, https://docs…”

   proof ↗⚑ flag

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

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

   Paperspace—none0/10

   Paperspace offers API keys for programmatic access, but evidence shows no scoped or least-privilege permission model — keys appear to be account-level, not fine-grained or agent-specific credentials.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Paperspace~partialprobed6/10

   Docs confirm an official Core RESTful API and Core JavaScript SDK plus a documented CLI (pspace) verified via runtime probe, giving developers concrete official interfaces to build against. However, evidence only names one language SDK (JavaScript), with no mention of Python or other SDKs, and no independent corroboration of SDK quality or ecosystem breadth. missing for 10: evidence of additional language SDKs (e.g. Python), independent developer corroboration of SDK reliability, and a public SDK repo/changelog.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   Paperspace—none0/10

   No evidence of any webhook or event-subscription mechanism in Paperspace's API, CLI, or docs; only REST API, CLI, and SDK access are documented.

   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”

   proof ↗⚑ flag

Agentic features

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

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

   Paperspace~partialclaimed4/10

   Paperspace's 'Workflows' feature is documented as automating ML tasks/pipelines, and 'Deployments' run containerized models continuously, both of which could constitute background automation, plus API/CLI access enables scripting external automations. However there's no documentation of triggers, schedules, or persistent autonomous execution akin to cron/agentic loops, and no community evidence confirming this works well in practice. Missing for 10: scheduling/trigger mechanisms, evidence of long-running unattended execution, and independent confirmation that Workflows/Deployments actually operate autonomously without manual intervention.

   • [claimed-docs] “Workflows automate machine learning tasks, combining GPU instances with an expressive syntax to generate production-ready machine learning p…”
   • [claimed-docs] “Deployments are containers-as-a-service that let you run container images and serve machine learning models.”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”

   proof ↗⚑ flag

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

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

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

Api quality

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

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

   Paperspace—none0/10

   No evidence of an interactive API reference with runnable examples; probes show no OpenAPI/swagger spec found (404s) and no interactive docs playground mentioned, only static docs and CLI/API mentions.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.digitalocean.com/openapi.json, https://docs.digitalocean.com/swagger.json, https://docs…”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.digitalocean.com/products/paperspace/.md”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”

   proof ↗⚑ flag

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

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

   Paperspace—none0/10

   Paperspace/DigitalOcean documents a Core RESTful API and CLI, but explicit probes for an OpenAPI/Swagger spec at all standard locations returned 404, and no machine-readable spec is referenced anywhere in the docs.

   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.digitalocean.com/openapi.json, https://docs.digitalocean.com/swagger.json, https://docs…”

   proof ↗⚑ flag

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

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

   Paperspace—none0/10

   Paperspace documentation covers general-purpose VM/notebook/deployment provisioning but never describes a distinct sandbox mode or production-data isolation guarantee; nothing in the evidence ties machine creation to safely testing against non-production data.

   • [claimed-docs] “Machines are Linux and Windows virtual machines with persistent storage, GPU options, and free unlimited bandwidth.”
   • [claimed-docs] “When you create a new machine, you choose your machine type, operating system or custom template, disk size, region, authentication, startin…”
   • [claimed-docs] “Deployments are containers-as-a-service that let you run container images and serve machine learning models.”

   proof ↗⚑ flag

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

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

   Paperspace—none0/10

   Evidence shows Paperspace has a REST API, CLI, and SDK, but nothing documents API versioning schemes or a deprecation policy anywhere in the docs or community sources.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”

   proof ↗⚑ flag

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

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

   Paperspace—none0/10

   Paperspace exposes an API, CLI (pspace), and Core JS SDK for programmatic resource management, which theoretically could be scripted for bulk actions, but no evidence documents any actual bulk/batch operation feature (e.g., multi-machine create/delete/update in one call, batch endpoints, or CLI loop/apply commands) across many items at once.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”

   proof ↗⚑ flag

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

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

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

3. ai-native userSchedule recurring jobs or workflows

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

   Paperspace—none0/10

   Paperspace docs mention on-demand Workflows for ML pipelines and auto-shutdown after inactivity, but there is no evidence of a scheduler, cron-like trigger, or recurring/periodic job execution capability. Absence of evidence for this applicable capability yields none.

   • [claimed-docs] “Workflows automate machine learning tasks, combining GPU instances with an expressive syntax to generate production-ready machine learning p…”
   • [claimed-docs] “The auto-shutdown feature places your machine in a stop state after a predefined period of inactivity, which can range from one hour to one …”

   proof ↗⚑ flag

Availability

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

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

   Paperspace—none0/10

   No evidence of any real-time GPU availability dashboard, API endpoint, or CLI command showing stock/quota by type and region; docs only describe choosing machine type/region at creation time and needing approval for high-end GPUs, with no visibility into availability before provisioning.

   • [claimed-docs] “There are several machine types grouped by CPU, GPU, and multi-GPU. If you choose any high-end machines, such as NVIDIA H100, you need to re…”
   • [claimed-docs] “When you create a new machine, you choose your machine type, operating system or custom template, disk size, region, authentication, startin…”

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

   Paperspace~partialclaimed6/10

   Docs confirm access to current-gen H100 (behind an approval gate) and previous-gen A100 GPUs, plus NVLink support and 'largest GPU catalog' claims, supporting a range of GPU tiers and cost/performance tradeoffs (docs-11, docs-17, docs-20, docs-26). However, there's no explicit mention of H200/B200-class GPUs or a clear listing of older, cheaper GPU tiers (e.g., T4/P100/V100) to fully match the story's specificity. missing for 10: explicit H200/B200 listing, explicit older/cheaper GPU tier catalog, independent benchmarking/corroboration of availability.

   • [claimed-docs] “Choose from the largest GPU catalog in the world. Leverage the latest NVIDIA GPUs including Ampere A100s with up to 8 GPUs.”
   • [claimed-docs] “There are several machine types grouped by CPU, GPU, and multi-GPU. If you choose any high-end machines, such as NVIDIA H100, you need to re…”
   • [claimed-docs] “Enhance data transfer speeds and scalability between NVIDIA GPUs for high-performance computing tasks by enabling NVLink.”
   • [claimed-docs] “Easily change instance types anytime so you always have access to the mix of cost and performance. Cancel anytime.”
   • [claimed-docs] “Leverage the latest NVIDIA GPUs including Ampere A100s with up to 8 GPUs.”

   proof ↗⚑ flag

Quotas

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

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

   Paperspace~partialclaimed3/10

   Docs mention that high-end GPU machines (e.g., H100) require an approval request, implying some quota/limit gating exists, but there is no dedicated documentation of quota tiers, numeric limits, or a defined escalation/support process for raising them beyond that single mention. Missing for 10: a documented quotas/limits reference page, explicit instance-count or resource caps, and a clear support ticket/process for requesting increases.

   • [claimed-docs] “There are several machine types grouped by CPU, GPU, and multi-GPU. If you choose any high-end machines, such as NVIDIA H100, you need to re…”

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

   Paperspace—none0/10

   Evidence shows Paperspace provisions single machines with up to 8 GPUs and NVLink for intra-node scaling, but nothing describes provisioning a multi-node cluster with fast cross-node interconnect (e.g., InfiniBand/RDMA) for distributed training, nor any self-service multi-node cluster workflow.

   • [claimed-docs] “Choose from the largest GPU catalog in the world. Leverage the latest NVIDIA GPUs including Ampere A100s with up to 8 GPUs.”
   • [claimed-docs] “Enhance data transfer speeds and scalability between NVIDIA GPUs for high-performance computing tasks by enabling NVLink.”
   • [claimed-docs] “Leverage the latest NVIDIA GPUs including Ampere A100s with up to 8 GPUs.”
   • [claimed-docs] “There are several machine types grouped by CPU, GPU, and multi-GPU. If you choose any high-end machines, such as NVIDIA H100, you need to re…”

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

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

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

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

   Paperspace~partialprobed6/10

   Paperspace ships both an API and a first-party pspace CLI that support machine creation, custom templates, autoscaling groups, and deployments (paperspace-docs-1, paperspace-docs-6, paperspace-docs-23/24, paperspace-probe-4, paperspace-probe-rt-1), giving strong API/CLI parity for core resource lifecycle tasks. However, some UI-only features like SSH connection setup are described as done via console/desktop app (paperspace-docs-2), no public OpenAPI/Swagger spec was found (paperspace-probe-3), and there's no explicit evidence that shared drives, auto-shutdown, or notebook management are fully API-controllable. Missing for 10: OpenAPI/spec confirmation of full endpoint coverage, explicit API parity for shared drives/auto-shutdown/notebooks, and independent hands-on confirmation that API-driven workflows match UI capability without gaps.

   • [claimed-docs] “You can create a Linux machine using the Paperspace console, Paperspace API, or Paperspace CLI.”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”
   • [claimed-docs] “You can connect to your Linux or Windows-based machine using the Paperspace console or desktop app using SSH connection.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.digitalocean.com/openapi.json, https://docs.digitalocean.com/swagger.json, https://docs…”

   proof ↗⚑ flag

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

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

   Paperspace~partialprobed4/10

   Paperspace machines use standard SSH/root access and shared drives, and API/CLI access lets users programmatically pull down VM configs, custom templates, and data via SSH/SCP, which provides some data portability. However there is no documented one-click 'export all data' or bulk data-export feature, no explicit open-format guarantee for notebooks/deployments/workflows metadata, and no evidence of a full account data export or migration tool. missing for 10: dedicated bulk data export/download feature, explicit open-format export guarantees for notebooks/deployments/workflows, documented account-level data portability or migration tooling, independent confirmation of successful full data export.

   • [claimed-docs] “You can connect to your Linux or Windows-based machine using the Paperspace console or desktop app using SSH connection.”
   • [claimed-docs] “Shared drives provide storage that is accessible from multiple machines in a private network.”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”

   proof ↗⚑ flag

Billing

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

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

   Paperspace—none0/10

   No evidence of any billing/usage export or cost-attribution API, report, or CLI command — the API/CLI docs cover compute resources (machines, notebooks, deployments) but nothing about programmatic billing or GPU spend breakdown by team/workload.

   ⚑ flag

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

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

   Paperspace—none0/10

   No evidence in the pack states per-second or per-minute billing granularity; the only granularity mentioned is an 'hourly rate' (paperspace-comm-8) and a flat monthly subscription tier with fixed hours (paperspace-comm-5), neither of which confirms sub-minute billing precision while running.

   • [community] “I use a Paperspace VM + Parsec for personal ML projects. An hourly rate on a standard VM w/GPU is better than buying a local machine, and yo…”
   • [community] “I use Stable Diffusion with Paperspace's Pro tier ($9/mo) for up to 6 hours of non per-usage GPU time, avoiding worry about electricity cost…”

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

   Paperspace—none0/10

   While Paperspace documents machine types, GPU options, and an API/CLI for creating machines, there is no evidence of a documented endpoint or CLI command that returns live pricing or availability data for the GPU catalog before provisioning—only marketing claims like 'save up to 70%' and 'largest GPU catalog' with no queryable pricing API surfaced.

   • [claimed-docs] “Choose from the largest GPU catalog in the world. Leverage the latest NVIDIA GPUs including Ampere A100s with up to 8 GPUs.”
   • [claimed-docs] “There are several machine types grouped by CPU, GPU, and multi-GPU. If you choose any high-end machines, such as NVIDIA H100, you need to re…”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.digitalocean.com/openapi.json, https://docs.digitalocean.com/swagger.json, https://docs…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”

   proof ↗⚑ flag

Pricing

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

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

   Paperspace—none0/10

   No evidence of reserved instances, committed-use contracts, or sustained-use discounts; only pay-as-you-go pricing claims like 'save up to 70%' and 'cancel anytime' are documented, which implies on-demand rather than committed pricing.

   • [claimed-docs] “Save up to 70% on compute costs”
   • [claimed-docs] “Easily change instance types anytime so you always have access to the mix of cost and performance. Cancel anytime.”

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

   Paperspace—none0/10

   The evidence pack contains marketing claims like 'save up to 70% on compute costs' but no actual published per-GPU-hour pricing table or pricing page content is shown; no citation demonstrates a public price list for each GPU type.

   • [claimed-docs] “Save up to 70% on compute costs”
   • [claimed-docs] “Save up to 70% on compute costs Spend significantly less on your GPU compute compared to the major public clouds or buying your own servers.”
   • [claimed-docs] “Save up to 70% on compute costs. Spend significantly less on your GPU compute compared to the major public clouds or buying your own servers…”

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

   Paperspace—none0/10

   No evidence anywhere in the pack mentions spot, preemptible, or interruptible instances, discount pricing tiers, or preemption semantics; only standard on-demand GPU rentals and general 'save up to 70%' marketing are documented.

   ⚑ flag

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

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

   Paperspace~partialclaimed4/10

   Docs confirm you select a 'region' when creating a machine ([paperspace-docs-25]), showing basic region choice for compute placement, but there is no evidence of dedicated data residency controls, storage region selection, compliance certifications (e.g., GDPR, SOC2 data residency), or documentation on where notebooks/deployments data is stored. missing for 10: explicit data residency/compliance documentation, storage-specific region selection, list of available regions, independent confirmation of enforcement.

   • [claimed-docs] “When you create a new machine, you choose your machine type, operating system or custom template, disk size, region, authentication, startin…”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

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

   Paperspace—none0/10

   No evidence pack items address data retention policies, deletion controls, or privacy/data lifecycle management for Paperspace resources like notebooks, storage, or machine data; the docs cover creation, connection, and compute features but nothing on retention/deletion control.

   ⚑ flag

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

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

   Paperspace—none0/10

   No evidence pack items mention telemetry, usage tracking, analytics opt-out, or privacy controls for Paperspace; the docs cover machine creation, CLI, and pricing but never address data collection or opt-out mechanisms.

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

   Paperspace~partialprobed5/10

   Paperspace documents API keys, a Core RESTful API, and an official CLI (pspace) for creating/managing machines, custom templates, and auto-shutdown, and a runtime probe confirms the CLI installs and lists machine/deployment commands — enough to plausibly script provisioning and teardown without a human in the console. However there is no MCP server, no documented end-to-end 'create→monitor→run workload→teardown' workflow example, and community reports describe friction getting SSH/API access working reliably on Core VMs, undercutting a clean automated experience. Missing for 10: an MCP server, explicit workload-run/monitoring API docs, and independent confirmation of a full agent-driven lifecycle without console fallback.

   • [claimed-docs] “You can create a Linux machine using the Paperspace console, Paperspace API, or Paperspace CLI.”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [claimed-docs] “The auto-shutdown feature places your machine in a stop state after a predefined period of inactivity, which can range from one hour to one …”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

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

   Paperspace~partialclaimed6/10

   Paperspace documents an auto-shutdown feature that stops a machine after inactivity (from 1 hour to 1 week), directly addressing the 'forgotten instance' risk, and this is corroborated by official docs. However, there is no evidence of configurable spend/budget limits or billing caps, which is the other half of the story. missing for 10: documented spend-limit/budget-cap feature, independent hands-on confirmation that auto-shutdown reliably prevents runaway billing.

   • [claimed-docs] “The auto-shutdown feature places your machine in a stop state after a predefined period of inactivity, which can range from one hour to one …”

   proof ↗⚑ flag

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

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

   Paperspace~partialprobed5/10

   Evidence confirms programmatic creation of machines via API/CLI/console and an auto-shutdown feature that stops machines after inactivity to control costs, and the pspace CLI clearly manages 'machine' resources. However, no direct documentation shows explicit start/stop/restart/terminate commands or billing-only-when-running semantics beyond auto-shutdown. missing for 10: explicit API/CLI start, stop, restart, terminate operations, confirmation that billing pauses immediately on stop, independent verification of lifecycle commands working.

   • [claimed-docs] “You can create a Linux machine using the Paperspace console, Paperspace API, or Paperspace CLI.”
   • [claimed-docs] “The auto-shutdown feature places your machine in a stop state after a predefined period of inactivity, which can range from one hour to one …”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “official CLI documented at https://docs.digitalocean.com/reference/paperspace/pspace/”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”

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

   Paperspace!disputedcontradicted5/10

   Docs and marketing show provisioning via console/API/CLI, SSH root access, and ML-ready templates enabling fast startup (paperspace-docs-1,6,10,12,13,24), and a runtime probe confirms the CLI installs and lists machine-management commands (paperspace-probe-rt-1). However, a hands-on community report directly contradicts the 'connect and run in minutes' claim: 'Getting SSH access is an uphill battle; instead there's a pointless virtual console... very slow internet, takes forever to copy datasets in' (paperspace-comm-7), and another user calls the notebook experience 'really bad' (paperspace-comm-6). Missing for 10: independent verified timing benchmarks of provisioning-to-running-code, resolution of the SSH-access friction reported by users, and more recent hands-on corroboration.

   • [claimed-docs] “You can create a Linux machine using the Paperspace console, Paperspace API, or Paperspace CLI.”
   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Go from signup to training a model in seconds”
   • [claimed-docs] “Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “Choose "ML in a Box" template that comes preinstalled with all the major ML frameworks and CUDA® drivers.”
   • [claimed-docs] “Install and use the new Paperspace Command Line Interface.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”
   • [community] “PaperSpace product recently has been really bad. Gradient Notebooks are a worse version of Google Colab, useless for serious DL product buil…”

   proof ↗⚑ flag

Serverless

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

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

   Paperspace—none0/10

   Paperspace's evidence describes VM-based 'Machines' with auto-shutdown after inactivity (docs-5) and container 'Deployments'/autoscaling-groups (docs-8, probe-rt-1), but nothing confirms true serverless GPU workers that scale to zero per-request and back up automatically without idle billing — the model described is always-provisioned instances that stop, not ephemeral serverless invocation.

   • [claimed-docs] “The auto-shutdown feature places your machine in a stop state after a predefined period of inactivity, which can range from one hour to one …”
   • [claimed-docs] “Deployments are containers-as-a-service that let you run container images and serve machine learning models.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official installer (`curl -fsSL https://paperspace.com/install.sh | sh`) installed the pspace CLI i…”

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

   Paperspace—none0/10

   No evidence of S3-compatible endpoints, cloud-storage sync, or dedicated data-transfer tooling; only generic 'shared drives' (docs-4) and CLI/API for resource management are documented, and community reports (paperspace-comm-7) describe data transfer to Core VMs as slow and cumbersome, further undermining any efficiency claim. missing for 10: S3-compatible endpoint, documented sync/transfer tool, benchmarked transfer speeds, and any first-party guidance on moving data in/out.

   • [claimed-docs] “Shared drives provide storage that is accessible from multiple machines in a private network.”
   • [claimed-docs] “Machines are Linux and Windows virtual machines with persistent storage, GPU options, and free unlimited bandwidth.”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

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

   Paperspace~partialcommunity6/10

   Docs describe persistent storage attached to machines (paperspace-docs-16) and separate 'shared drives' accessible from multiple machines in a private network (paperspace-docs-4), plus persistent notebook storage (paperspace-docs-7), which together imply data can outlive a single GPU instance. However, no evidence explicitly confirms shared drives survive full instance deletion/teardown, nor documents attach/detach workflow, pricing, or size limits, and one community comment complains about slow data transfer into Paperspace VMs (paperspace-comm-7). Missing for 10: explicit lifecycle documentation proving storage persists after instance termination, attach/detach mechanics, and independent hands-on confirmation of durability across teardown.

   • [claimed-docs] “Shared drives provide storage that is accessible from multiple machines in a private network.”
   • [claimed-docs] “Machines are Linux and Windows virtual machines with persistent storage, GPU options, and free unlimited bandwidth.”
   • [claimed-docs] “Notebooks are a web-based Jupyter IDE with shared persistent storage for long-term development and inter-notebook collaboration, backed by a…”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

   proof ↗⚑ flag

Images

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

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

   Paperspace✓fullcommunity7/10

   Paperspace lets users create custom machine templates (paperspace-docs-3, paperspace-docs-25) and run container images via Deployments (paperspace-docs-8), plus SSH root access to VMs for custom setups (paperspace-docs-12, paperspace-docs-19). Community reports (paperspace-comm-7) note friction getting reliable SSH/console access on Core VMs, which tempers confidence. Missing for 10: independent hands-on confirmation that custom Docker images run smoothly end-to-end, and clearer detail on template versioning/sharing.

   • [claimed-docs] “Custom templates are templates of your machines and their configurations. You can use these custom templates to create new machines with you…”
   • [claimed-docs] “Deployments are containers-as-a-service that let you run container images and serve machine learning models.”
   • [claimed-docs] “When you create a new machine, you choose your machine type, operating system or custom template, disk size, region, authentication, startin…”
   • [claimed-docs] “Bring your SSH key and connect directly to your VM with full root access.”
   • [claimed-docs] “Root access, connect with SSH Bring your SSH key and connect directly to your VM with full root access.”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

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

   Paperspace~partialcommunity5/10

   Paperspace docs confirm a pre-built "ML in a Box" template with major ML frameworks and CUDA drivers preinstalled, plus custom-template creation for reuse, supporting the general concept of launching from ready-made ML environments. However, no evidence names specific frameworks like PyTorch, vLLM, or ComfyUI templates, and community comments describe friction (slow setup, SDK upgrade walls, GUI confusion) that undercuts a seamless 'launch instantly' experience. missing for 10: explicit PyTorch/vLLM/ComfyUI-named templates, hands-on confirmation of frictionless template launch, independent corroboration beyond marketing docs.

   • [claimed-docs] “Choose "ML in a Box" template that comes preinstalled with all the major ML frameworks and CUDA® drivers.”
   • [claimed-docs] “Custom templates are templates of your machines and their configurations. You can use these custom templates to create new machines with you…”
   • [claimed-docs] “When you create a new machine, you choose your machine type, operating system or custom template, disk size, region, authentication, startin…”
   • [community] “Paperspace gives free access to Graphcore IPU nodes (4 IPUs each), theoretically more throughput than Colab T4. But porting Stable Diffusion…”
   • [community] “Their DL virtual servers (Core) are horrible - very slow internet, takes forever to copy datasets in. Getting SSH access is an uphill battle…”

   proof ↗⚑ flag

Compliance

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

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

   Paperspace—none0/10

   No evidence pack items mention SOC 2 compliance, certifications, data handling policies, or datacenter tier information; the evidence is entirely product feature docs and community complaints about performance/support, none of which address compliance posture. missing for 10: SOC 2/ISO certifications, data handling/privacy documentation, datacenter tier specs, any compliance attestations.

   ⚑ flag

Governance

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

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

   Paperspace—none0/10

   Evidence confirms API keys exist for programmatic access (paperspace-docs-6, paperspace-docs-23) but there is no mention of team member management, role assignment, scoped/permissioned API keys, or spend-control governance features anywhere in the pack.

   • [claimed-docs] “API keys let you interact with Paperspace through the Core RESTful API, the Core JavaScript SDK, and Gradient command-line utility (CLI).”
   • [claimed-docs] “Programmatically manage Paperspace resources using conventional HTTP requests.”

   proof ↗⚑ flag