runpod

Imported from runpod/runpod-plugins-official (plugins/runpod/skills/runpod/SKILL.md) via skills.sh. Install upstream with npx skills add runpod/runpod-plugins-official --skill runpod. Copyright stays with the author (Apache-2.0).

Runpod (router)

The entrypoint for the Runpod skills. This skill does no work itself — it picks the right lane and hands off. For a multi-step or provisioning task, check the worked examples first and let the matching one pick the lane; otherwise read the matching skill's SKILL.md next.

The lanes

These skills are a snapshot; the tools are the source of truth

Every lane below wraps something that ships on its own release train and moves faster than this repo. So route with these skills, but take capability and syntax from the tool in front of you:

Never tell a user a tool cannot do something without checking first. A missing capability is the claim most likely to be out of date here, and it is the one a reader has no reason to reverify — it has already gone stale twice (runpodctl v2.9.0 added serverless health, v2.10.0 added pod logs/serverless logs). If a limit still holds, name the version it holds for rather than saying "cannot".

First run — update the tools, then check auth

Update before the first command of every task. Old builds keep flags that later releases fixed or removed. runpodctl before v2.12.0 accepts pod create --stop-after / --terminate-after, but the backend never enforced them, so pods kept billing past the deadline. Update each tool you are about to use:

runpodctl update && runpodctl version   # runpodctl
flash update                            # flash

The MCP needs no step: the hosted server is always current, and a local install started with npx @runpod/mcp-server@latest fetches the latest release. Use the same build for the rest of the task.

File authoring with runpod-build-template needs no cloud credentials. Check auth only when an operation actually uses the control plane or another authenticated service.

Infra tasks (pods, endpoints, jobs, volumes) need a working control plane — the Runpod MCP or runpodctl. Don't start and discover mid-task that nothing's set up: check first, and if it isn't, help the user set up rather than limping on a partial fallback.

Check (credential resolution order: RUNPOD_API_KEY env → .env → ~/.runpod/config.toml):

runpodctl user            # succeeds ⇒ a key is set and valid

Plus, in Claude Code, /mcp should show runpod Connected.

Rule: get a key first — do not default to MCP OAuth. The reason: one RUNPOD_API_KEY unlocks every tool — it authenticates runpodctl + flash + the hosted MCP (as --header "Authorization: Bearer $RUNPOD_API_KEY"). The MCP's "Sign in with Runpod" OAuth auths the MCP alone — the CLIs stay blocked, so you hit a wall on any CLI-only task (send/receive, SSH, doctor, model cache/Model Repository, CPU endpoints). ⚠️ OAuth-only is a half-setup. If nothing's set up, stop and get a key, in order:

1. flash login — browser OAuth that saves a real key to ~/.runpod/config.toml (runpodctl
   • flash read it; reuse it for the MCP Bearer). One step, unlocks all. Human-only.
2. export RUNPOD_API_KEY=… (https://console.runpod.io/user/settings) — same full unlock; best for headless agents.
3. MCP OAuth only (/mcp → Sign in) — last resort, MCP-only work; CLIs stay unauthed.

Then: if a lane already works, use it — but if only the MCP is OAuth'd, still get a key before any CLI-only step. Missing a CLI? curl -sSL https://cli.runpod.net | bash (runpodctl) · uv tool install runpod-flash (flash) · npx @runpod/mcp-server@latest add (MCP). Full setup: runpod-usage/reference/getting-started.md.

How to route

0. Does a worked example already cover this? For anything beyond a single call, check the golden-paths index before picking a lane — a matching path already names the lane(s), the flags, the ordering, and the traps, so routing becomes reading rather than re-deriving. Check it when any of these is true:

• the task needs more than one resource (image + template + endpoint, pod + volume, multi-region, …) or more than one lane
• it provisions something billable, or the user's ask is shaped like "get X running / deployed / working"
• it involves storage, networking, autoscaling, streaming, or debugging a live resource — the areas where the non-obvious ordering is the whole difficulty
• you are about to write a multi-step plan for it

Skip step 0 for a single read or a single CRUD call ("list my pods", "stop pod X", "what GPUs are available") — go straight to the lane. A matching golden path outranks this router's lane table for workflow selection. Its commands do not establish that a capability is CLI-only: choose the execution lane from the live tool surface and the capability matrix below, while preserving the path's ordering and verification steps.

For an explicit request to create or optimize a Dockerfile/template project, match path 26 before generic deployment examples; GP26 is an authoring specification with local checks, not a live-verified deployment. An existing prebuilt does not replace the requested deliverable.

1. Conceptual question, or an unmade design choice (serverless vs pod? which GPU? bake the model or mount a volume?) → read runpod-usage first, then continue with the answer.
2. Author or improve a template project / Dockerfile, including converting local code or a GitHub repository, or prepare its Hub listing files → runpod-build-template. It delegates build/push mechanics and infrastructure work to their existing lanes. Registering an already-built image as a reusable template ("make a template from my image") and browsing/deploying an existing Hub listing use the infrastructure lanes below; registration needs no new Dockerfile.
3. Run a common workload on a pod, or fix a template pod ("run ComfyUI / PyTorch dev box", won't boot, missing models) → runpod-templates — check for an official prebuilt before planning any install, and let it route repairs.
4. Write/iterate/ship your own code on Runpod GPUs using its code-first workflow → flash.
5. Produce an artifact (download a model, build+push an image, create a repo release, sync data to a volume) → companion-clis.
6. Migrate existing code between Runpod API versions — "move us to REST v2", "which Runpod API is this repo on?", "what breaks if we upgrade?" → runpod-migrate. (Calling the API to do something is a different job; that is the infra lanes below.)
7. Manage infrastructure (create/list/update/delete pods, endpoints, templates, volumes; list GPUs/data centers; run a serverless job; billing):
   • Capability only the CLI has — send/receive, SSH keys, doctor, model cache → runpodctl.
   • Otherwise, if the Runpod MCP tools are connected in this session (create-pod, list-endpoints, … are available) → runpod-mcp.
   • Otherwise (shell-only agent, no MCP) → runpodctl.

runpod-mcp vs runpodctl (the overlap)

Both drive the same Runpod API, so they overlap on infra CRUD. Choose by capability first, environment second:

• MCP wins on convenience for simple, structured operations — reads and basic CRUD — when its tools are connected (typed params, no shell quoting).
• runpodctl takes over when an operation needs a capability MCP lacks — even if MCP is connected — and is the only option for a shell-only agent or when the user wants a reproducible command.

Capability matrix (pick the preferred lane per operation):

Rule of thumb: default to MCP for the easy stuff, hand off to runpodctl the moment an op needs a flag/feature MCP doesn't expose.

Deploying a workload (the golden loop)

For any "get running on Runpod" task, follow the development loop in runpod-usage/reference/development-loop.md: decide pod vs serverless → provision → set up (only if from-scratch) → verify → deliver → cost-guard + teardown. These rules bind within it:

• Prefer a prebuilt template / Hub worker over building an image from scratch — except when the user explicitly requests a custom template project or Dockerfile; official pod templates are indexed in runpod-templates.
• Before delivering, verify the workload with a real request from outside the pod/endpoint — a "Running"/"ready" status does not mean it is serving.
• Default to Secure Cloud. Community Cloud hosts are approved vendors; Secure Cloud hosts are data-center-grade providers and so tend toward more stable behavior. Only deploy Community when the user explicitly asks. (runpodctl pod create already defaults to --cloud-type SECURE; don't override it.)
• Cache vs network volume is a latency call, not a cost call. Download time is never billed, but on a cache miss Runpod holds the worker start until the model lands — the job sits in the queue and the endpoint looks idle. Latency-sensitive → pre-load a network volume; otherwise the cache is the cheaper default. Cache capacity is per machine, so time both on the user's own endpoint rather than quoting a threshold. See runpodctl/reference/model-caching.md.
• Pin the CUDA floor on every GPU create — --min-cuda-version 12.8 in runpodctl, gpu.minCudaVersion: "12.8" in REST v2 and MCP (13.0 only for a CUDA-13 image). Without it the create accepts any host CUDA version and a modern image can land on a host too old to run it, which reads as a container that dies at startup or silently runs on CPU: gpu-selection.md.

It branches to two sub-loops:

• Service you open at a URL (Ollama, ComfyUI, dev box) → runpod-usage/reference/pod-workflows.md (ports + env + volume at creation, SSH-exec install, bind 0.0.0.0, poll the proxy URL). Execute in the runpodctl lane.
• Request/response API that scales to zero (Whisper, inference) → runpod-usage/reference/endpoint-workflows.md (Hub worker vs flash vs custom image; invoke /run//runsync; poll job status).

Worked examples (golden paths)

This is step 0 of routing, not an appendix. Two dozen end-to-end scenarios (nearly all live-verified on a real account) live in ./golden-paths/README.md, with the real commands and the observed output to copy from — plus a Gotchas and a Cost & cleanup section each, which is the part that is expensive to rediscover.

Match the task to a row below and open that path before you plan or call anything. A partial match is still worth opening: the closest path's ordering and gotchas usually transfer even when the model, GPU, or region does not. Only fall through to the lane tables above when nothing here is close.

Multi-lane tasks

Sequence is always understand → produce artifacts → manage infra → verify, because infra can only reference artifacts that already exist. Keep each step in one lane, and switch lanes at credential boundaries.

Example — "deploy openai/gpt-oss-20b to a serverless endpoint":

1. runpod-usage — serverless vs pod, GPU tier for 20B, bake vs mount vs cache.
2. companion-clis — hf download …, docker build --platform=linux/amd64 …, docker push.
3. runpod-mcp or runpodctl — create the endpoint referencing the image + GPU pool.
4. Same infra lane — invoke the endpoint / check status to verify.

Auth

Everything is one key: RUNPOD_API_KEY (https://console.runpod.io/user/settings). Each lane just makes that key resolvable — runpodctl doctor, flash login, MCP stdio env var, or MCP hosted "Sign in with Runpod" (OAuth, no key on disk). Companion CLIs use their own credentials (HuggingFace token, GitHub auth, Docker Hub PAT, Runpod S3 keys for aws) — do not reuse RUNPOD_API_KEY for those.