From runpod
How Runpod works and how to work it — pods vs serverless, GPU/VRAM selection, storage, building a container, networking, plus the agentic pod development loop (provision → ssh-exec → set up → poll readiness) and on-pod install hygiene (uv/apt). Use to answer "how does X work", "which GPU", "how do I build a container", or "how do I stand up a workload on a pod". Guidance, not a tool — execute with runpodctl, runpod-mcp, or flash.
How this skill is triggered — by the user, by Claude, or both
Slash command
/runpod:runpod-usageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Background knowledge for making the right choice before you act. This skill runs
evals/pod-service-loop.eval.mdevals/verify-with-real-request.eval.mdreference/building-images.mdreference/concepts.mdreference/development-loop.mdreference/docker.mdreference/endpoint-workflows.mdreference/getting-started.mdreference/gotchas.mdreference/gpu-selection.mdreference/networking.mdreference/on-pod-setup.mdreference/pod-workflows.mdreference/storage.mdBackground knowledge for making the right choice before you act. This skill runs nothing — once you know what to do, execute with runpod-mcp/runpodctl (infra), flash (your own code), or companion-clis (models/images/data).
Read the one reference file that matches the question:
| Question | Read |
|---|---|
First-run setup / auth — get + set RUNPOD_API_KEY, SSH, companion creds | reference/getting-started.md |
| Pods vs serverless, workers, cold starts, FlashBoot, queue vs load-balanced | reference/concepts.md |
| The development loop for ANY workload (start here) — plan → prefer prebuilt → provision → verify → teardown | reference/development-loop.md |
| Stand up / iterate a workload on a pod — the pod sub-loop | reference/pod-workflows.md |
| Deploy / iterate a serverless endpoint — Hub vs flash vs custom, invoke + verify | reference/endpoint-workflows.md |
Install software on a pod — package hygiene, uv, non-interactive, caching | reference/on-pod-setup.md |
Build a Docker image Runpod can run (handler contract, Dockerfile, --platform=linux/amd64) | reference/docker.md |
| How to build an image well — base image, layering, bake-in vs volume, pod vs serverless (queue/LB) contract | reference/building-images.md |
| Where data lives — container disk vs network volume, model caching, S3 access | reference/storage.md |
| Which GPU / how much VRAM / cost & availability / data centers | reference/gpu-selection.md |
| Reaching a pod or endpoint over HTTP (proxy URLs, exposed ports) | reference/networking.md |
| Common mistakes and how to avoid them | reference/gotchas.md |
npx claudepluginhub runpod/runpod-plugins-official --plugin runpodStart here for any Runpod task — running GPU/CPU pods, deploying serverless endpoints, templates, network volumes, building images, or understanding how Runpod works. Routes the request to the right Runpod skill (runpod-mcp, runpodctl, flash, companion-clis, or runpod-usage). Use when it is unclear which Runpod skill applies.
Platform-specific configuration templates and GPU selection guidance for Modal, Lambda Labs, and RunPod cloud platforms.
Launches and manages GPU/TPU/CPU workloads across 25+ clouds, Kubernetes, and Slurm. Handles training, fine-tuning, inference serving with autoscaling, and cost optimization.