Runpod vs Paperspace

Ide

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

   weight 1 · round to Runpod
   Runpod✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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