[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CFW2PPRQZ006AVQXGMWPH1":3,"skill-same:01M6CFW2PPRQZ006AVQXGMWPH1":174},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":68,"ownerDescription":6,"updatedAt":69,"install":70,"resources":83},"01M6CFW2PPRQZ006AVQXGMWPH1","runpodctl",null,"Runpod CLI for managing GPU\u002FCPU workloads from the terminal — pods, serverless endpoints, templates, network volumes, Hub deploys, models, SSH, and file transfer (send\u002Freceive, network-volume upload\u002Fdownload). Use for terminal\u002FCI\u002Fscripting, SSH setup, `doctor`, or when the Runpod MCP tools are not connected; prefer runpod-mcp for structured tool calls in an MCP-enabled session.","runpod\u002Frunpod-plugins-official","runpod","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F95939477?v=4","01M6CFSV7PCCKKMKEV6AM8XC7H","Runpod","01M6CFSVC1QMHFR2P1HF14EZ08",49,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,9,32,33,34,35,36,37,38,39,40,41],"terminal","when","windows","send","endpoint","macos","Tools","ssh setup","network","CPU","volume","template","cli","Bash","MCP","ci","model","doctor","2026-11-10 10:12:30",false,"---\nname: runpodctl\ndescription: >-\n  Runpod CLI for managing GPU\u002FCPU workloads from the terminal — pods, serverless\n  endpoints, templates, network volumes, Hub deploys, models, SSH, and file\n  transfer (send\u002Freceive, network-volume upload\u002Fdownload). Use for\n  terminal\u002FCI\u002Fscripting, SSH setup, `doctor`, or when the Runpod MCP tools are\n  not connected; prefer runpod-mcp for structured tool calls in an MCP-enabled\n  session.\nallowed-tools: Bash(runpodctl:*)\ncompatibility: Linux, macOS, Windows\nmetadata:\n  author: runpod\n  version: \"2.0.0\" # x-release-please-version\n  concepts: [runpodctl, pod, cpu-pod, serverless-endpoint, template, network-volume, hub-repo, ssh-key, file-transfer, model-store, volume-cache]\nlicense: Apache-2.0\n---\n\n# Runpodctl\n\nManage GPU pods, serverless endpoints, templates, volumes, and models. For serverless development workflows, use the [Runpod SDK](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-python) regardless of CLI version.\n\n## Install\n\n`curl -fsSL https:\u002F\u002Fcli.runpod.net | sudo bash` (Linux\u002FmacOS, and Windows via WSL) or `brew install runpod\u002Frunpodctl\u002Frunpodctl`. Manual binaries and the Windows and conda steps: the [runpodctl README](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl#install), beside the `install.sh` they describe. API key: https:\u002F\u002Fconsole.runpod.io\u002Fuser\u002Fsettings\n\n> Old builds silently lack newer flags\u002Fbehaviors (e.g. `--model-reference` doesn't exist before\n> v2.4.0) and produce confusing downstream errors, and the Homebrew tap can lag well behind.\n> Before any work: **update to the latest build** (`runpodctl version`, then `runpodctl update`,\n> or reinstall from the [latest release](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Freleases)); **pin one\n> recent version for the whole task**; **never switch between an old and a new binary mid-task**\n> (a known failure); **verify once** with `runpodctl version` before you continue.\n\n## Quick start\n\n```bash\nrunpodctl update && runpodctl version   # FIRST: latest build, confirmed, before any work\nexport RUNPOD_API_KEY=your_key      # agents: non-interactive auth, read by runpodctl\nrunpodctl doctor                    # humans: interactive first-time setup (prompts for API key + SSH keys); not for scripted use\nrunpodctl pod create --help         # inspect exact current flags before creating\nrunpodctl gpu list                  # GPU types\nrunpodctl datacenter list           # GPU availability per data center (co-locate GPU + volume)\nrunpodctl hub search vllm           # find a hub repo\nrunpodctl serverless create --hub-id \u003Cid> --name \"my-vllm\"  # deploy from hub\nrunpodctl template search pytorch   # find a template\nrunpodctl pod create --template-id runpod-torch-v280 --gpu-id \"NVIDIA GeForce RTX 4090\" --min-cuda-version 12.8  # create from template\nrunpodctl pod list                  # your pods\n```\n\n## Live Help Is Authoritative\n\nLive `runpodctl --help`, `runpodctl \u003Cresource> --help` and `runpodctl \u003Cresource> \u003Caction> --help` are authoritative for exact flags, aliases, and syntax (the generated pages under [`runpodctl\u002Fdocs\u002F`](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Ftree\u002Fmain\u002Fdocs) mirror them). Inspect live help before unfamiliar commands; this skill covers workflows, decision rules, safety notes, and common examples, and is not an exhaustive flag reference.\n\nLive help does **not** cover output shapes, error codes, or exit-code behavior: use [reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md), and when in doubt **probe the binary** (run it wrong on purpose, e.g. `runpodctl serverless get nope`, and read the JSON). Every doc is a snapshot, this skill included; the binary in front of you wins.\n\n## Output & errors\n\nData is **JSON on stdout** (`--output=yaml` is the only alternative; there is no table format; v2.10.0+ rejects any other value with `usage_error`, v2.9.0 and earlier silently return JSON). A failure is one flat JSON object on **stderr** plus a **non-zero exit**:\n\n```jsonc\n{\"error\":\"failed to get endpoint: endpoint not found\",\"code\":\"not_found\",\"status\":404}\n```\n\n- **Branch on `code`, never on `status` or the message** (GraphQL reports a missing resource as HTTP 200 + null data, so `status` is often absent).\n- **Retry with backoff only on `network_error`, `rate_limited`, `server_error`;** the API commands never retry internally. `no_credentials` = no key set (for `network-volume upload`\u002F`download`: no S3 API keys, or no API key for the data-center lookup, which `--data-center-id` skips; the message names which); `unauthorized`\u002F`forbidden` = a key is set but wrong or lacks access (don't re-prompt). `usage_error`, `cli_error`, `bad_request`, `not_found`, `conflict`: fix the input. Any other code is fatal: surface `error` verbatim.\n- **`network-volume upload`\u002F`download` (v3.1.0+) retry on their own** (429, 5xx, dropped connections). `transfer_incomplete` = it stopped partway: **rerun the same command**, it resumes. `volume_full` = grow the volume (`network-volume update --size`), then rerun.\n- **Gate on the exit code, then parse stderr:** deprecation `warning:`\u002F`note:` lines go to stderr on success too.\n- **Coded errors, the serverless `urls` object and GPU pricing need runpodctl ≥ v2.8.0.** Older binaries emit `{\"error\":\"…\"}` with no `code`, so gate on `code` being present, not on `runpodctl version`.\n- **`project` behaves differently per build** (exit 0 with errors on stdout through v3.0.1; exit 1 with a Runpod SDK notice in builds with [runpod\u002Frunpodctl#382](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Fpull\u002F382)). Treat that notice as fatal.\n\nFull code table, `cli_error` vs `usage_error`, plain-text exceptions, the exact SDK notice, and the env-var table (incl. `RUNPOD_INVOKE_URL`): **[reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md)**.\n\n## Decision Rules\n\n- **Hub** for a known deployable app or worker (vLLM, ComfyUI, Whisper, a Runpod-maintained repo). **Picking a worker:** prefer a **first-party or well-adopted, recently-released** worker on a **broad, high-availability GPU pool**; signals in `runpodctl hub list`: `--owner runpod-workers` (first-party), `--order-by releasedAt`\u002F`updatedAt` (recency), `--order-by deploys`\u002F`stars` (adoption). Don't pin a scarce large-GPU tier a small model doesn't need.\n- **Templates** when the user already has a template ID, wants reusable image\u002Fconfig defaults, or needs lower-level control than Hub. **`pod create --image`** for a specific Docker image with no saved template.\n- **Serverless** for request\u002Fresponse inference APIs and scalable workers; **pods** for interactive work, notebooks, training, debugging, or long-lived sessions. **CPU pods** for preprocessing, file movement, lightweight scripts, and non-CUDA work; **GPU pods** when CUDA, model inference, training, or GPU memory is required.\n- **\"Active worker\" = minimum workers, not maximum:** `--workers-min 1` (one worker always warm → no cold start; ideal for development\u002Fiteration), **not** `--workers-max 1` (that only caps the ceiling).\n- ⚠️ **A min-1 worker bills continuously, even while idle** (it defeats scale-to-zero). After dev you **must** set `--workers-min 0` (or delete the endpoint), or it quietly runs up cost.\n  - **Needs runpodctl ≥ v2.10.0.** Earlier binaries **silently dropped** `--workers-min 0` and `--idle-timeout 0` from the update request (`omitempty` ate the zero): the reset looked applied and the endpoint kept billing. Check `runpodctl version`; on an older binary confirm with `serverless get \u003Cid>` and fall back to `PATCH https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fserverless\u002F\u003Cid>` with an explicit `{\"workers\":{\"min\":0}}`.\n- **Set the execution timeout on every endpoint create.** A v2 create without `timeout` comes back `\"timeout\": 0` (live-verified 2026-10-29; [why it matters](..\u002Frunpod-usage\u002Freference\u002Fgotchas.md#endpoint-timeout-comes-back-0)). runpodctl ≥ 2.14.0 has `serverless create --execution-timeout \u003Cseconds>` (as of 2.14.0 `serverless update` does not; check `--help`); read the timeout back with `serverless get`, and fix a 0 with `PATCH https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fserverless\u002F\u003Cid>` `{\"timeout\":\u003Cms>}`.\n- `serverless update` has **no `--gpu-id` flag**. To change an endpoint's GPU pools, `PATCH https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fserverless\u002F\u003Cid>` with `{\"gpu\":{\"pools\":[\"ADA_24\"]}}` (pool ids, from the `pool` field of `GET \u002Fv2\u002Fcatalog\u002Fgpus`). Sending `pools` without `excludedTypes` clears any exclusions.\n- **CPU serverless endpoints:** `runpodctl serverless create --compute-type CPU` (on REST v2, send `cpu` instead of `gpu`). **Never** send `\"computeType\":\"CPU\"` to REST v1 `POST https:\u002F\u002Frest.runpod.io\u002Fv1\u002Fendpoints`: it silently provisions a **GPU** endpoint ([evidence](reference\u002Fcommand-reference.md#cpu-endpoints-and-rest-v1)).\n- **Leave `--cloud-type` at its `SECURE` default** ([why](..\u002Frunpod-usage\u002Freference\u002Fgpu-selection.md#step-5-secure-vs-community-cloud)). Pass `--cloud-type COMMUNITY` only when the user explicitly asks (a public port 22 there needs a machine with a public IP, which the CLI cannot request).\n- A CPU pod gets 2 vCPUs on whichever CPU flavor has the most stock; `--name` defaults to the image name without its tag. CPU pods take a network volume (`--network-volume-id`) but not a pod volume (`--volume-in-gb` is rejected). Do not pass GPU flags.\n- **Set a CUDA floor on every GPU create: `--min-cuda-version 12.8`** (`pod create` and `serverless create`; not `template create`). Without it a modern image can land on a host too old to run it, and the create will not reject it: the container dies at startup or silently runs on CPU. `13.0` only for a CUDA-13 image; omit for CPU. Rule, exceptions and capacity check: [`runpod-usage` gpu-selection \"pin the CUDA floor\"](..\u002Frunpod-usage\u002Freference\u002Fgpu-selection.md#step-3-pin-the-cuda-floor).\n- **Waiting for a resource to be usable: use `--wait`, don't hand-roll a poll loop** (v2.9.0+). `create` returns once the resource is *scheduled*, which is why a \"RUNNING\" pod often refuses ssh and a fresh endpoint 404s. `pod create --wait` returns when port 22 answers with an ssh banner. `pod create --wait-for running` (v2.15.0+) returns when the container is up, no ssh needed: use it when container-up is all the task needs, or for an image that does not start sshd (most cpu images, since cpu pods get no Runpod-managed ssh), where plain `--wait` would bill through the whole timeout and then fail; a cpu image that starts its own sshd still satisfies plain `--wait`, so keep that when the user needs ssh. `serverless create --wait` returns when `\u002Fhealth` reports a ready or running worker. On timeout or ctrl-c the resource is **kept** and its id is in the error object's `id` field: read it and clean up, don't assume nothing was created (a pod bills by the second; an endpoint with no running worker doesn't, but starts one on the first request).\n- **A service on a pod** (Ollama, ComfyUI, a dev server): declare its `--ports` and `--env` at creation when possible (`runpodctl pod update` can change them on an existing pod), then follow the pod development loop in `runpod-usage` (`reference\u002Fpod-workflows.md`): SSH-exec the install, bind to `0.0.0.0`, poll the proxy URL until it answers.\n- **SSH:** connection details from `runpodctl pod get \u003Cpod-id>` or `runpodctl ssh info \u003Cpod-id>`. runpodctl has **no interactive-shell command**: `ssh info` returns the connection command + key but does not connect, so run `ssh user@host \"command\"` yourself.\n- Network volumes are location-sensitive: pick the data center from the GPU stock read (`datacenter list`, or `gpu list --include-unavailable`) before creating the volume, and create it once. If `pod create` is then refused for stock, re-read stock: retry once with the same volume when its data center shows stock; otherwise ask the user (wait, another GPU type there, the console's Deploy when available, or a move to another data center, which is the user's call). Never delete the volume to try another data center; on a move, name it in the hand-back (id, data center, storage cost) and delete it only when the user asks. Move data onto or off a volume with `network-volume upload` \u002F `download` (v3.1.0+, resumable); `send` \u002F `receive` for machine to machine.\n- Clean up paid resources after tests: serverless endpoints, pods, and temporary volumes created for validation.\n  - **Cost guard:** remove the pod when the work is done (`runpodctl pod remove \u003Cpod-id>`); a stopped pod still bills for disk and any volume. Unattended deadline: [pod-workflows](..\u002Frunpod-usage\u002Freference\u002Fpod-workflows.md#2-provision) (schedule a stop from inside the pod).\n  - **`--stop-after` \u002F `--terminate-after` never worked.** Before v2.12.0 `pod create` accepts both, but the backend never enforced them, so the pod keeps running and billing past the deadline; v2.12.0 removed them. If `runpodctl pod create --help` still lists them, run `runpodctl update`. Never offer them as a cost guard.\n  - **Attached volume:** to delete a network volume, remove the pod using it first.\n\n### Serverless facts (context, not rules)\n\n- **Scale-to-zero billing:** endpoints scale to zero with `--workers-min 0` (the default): no GPU billing while idle, only per request-second; the right cost posture for a request\u002Fresponse API.\n- **Broken-image tell:** deployed workers go `ready` but jobs sit `IN_QUEUE` with `inProgress: 0` → the image is broken\u002Fmis-dispatching; switch to a different worker rather than wait it out.\n- **Diagnosing it:** worker\u002Fjob counts with `runpodctl serverless health \u003Cendpoint-id>` (v2.9.0+), then what the workers printed with `runpodctl serverless logs \u003Cendpoint-id>` (v2.10.0+); no hand-built curl needed. Repeated `system` \"start container\" lines with no `container` output = the container exits before the handler runs.\n\n## Commands\n\nEssentials only; flags come from `--help`. [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md) holds what `--help` cannot answer: what a flag *means* when it succeeds, which field to trust, and what a failure looks like.\n\n### Pods\n\n```bash\nrunpodctl pod list                                   # running pods (+ --all \u002F --status \u002F --since \u002F --created-after)\nrunpodctl pod get \u003Cpod-id>                           # details incl. SSH info + runtimeStatus\nrunpodctl pod create --template-id \u003Cid> --gpu-id \"NVIDIA GeForce RTX 4090\" --min-cuda-version 12.8   # from template (or --image \u003Cimg>)\nrunpodctl pod create --compute-type cpu --image ubuntu:22.04                 # CPU pod (2 vCPUs; name defaults to the image)\nrunpodctl pod create --image \u003Cimg> --gpu-id \u003Cid> --wait                      # block until ssh answers, then print the pod (v2.9.0+)\nrunpodctl pod create --compute-type cpu --image ubuntu:22.04 --wait-for running  # block until the container is up; no sshd needed (v2.15.0+)\nrunpodctl pod {start|stop|restart|update|delete} \u003Cpod-id>                    # lifecycle (delete aliases: rm\u002Fremove)\nrunpodctl pod logs \u003Cpod-id> [--follow] [--since 30m --source system]          # recent container+system logs, json lines (v2.10.0+); --follow keeps streaming and reconnects on its own; --source system = platform view: image pull \u002F create \u002F start\n```\n\nrunpodctl v3.0.0 removed `pod reset`; use `pod restart` only when a restart is intended.\n\n**A stalled deploy shows up in `--source system`** (v2.10.0+): repeated pull progress, or a `create container` that never reaches `start`. `--source container` is your workload's own output. Each line is one `{source,line,ts}` object; pipe it to `jq`.\n\n**Read `runtimeStatus`, not `desiredStatus`, to decide whether a pod is usable** (v2.9.0+): `desiredStatus: RUNNING` says that while the image is still pulling. Field meanings, reason tokens, and two edges (`--status` filters `desiredStatus` only; `unknown` = lookup failed, not pod down) → [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#pod-status-fields).\n\n### Hub\n\nBrowse\u002Fsearch existing Runpod Hub listings; pick the execution lane with the [router capability matrix](..\u002Frunpod\u002FSKILL.md#runpod-mcp-vs-runpodctl-the-overlap). Authoring a project's Hub listing files: [runpod-build-template](..\u002Frunpod-build-template\u002FSKILL.md).\n\n```bash\nrunpodctl hub search vllm                            # find a repo (+ hub list [--type\u002F--category\u002F--order-by\u002F--owner])\nrunpodctl hub get \u003Clisting-id|owner\u002Fname>            # repo details\n```\n\n### Serverless (alias: sls)\n\n```bash\nrunpodctl serverless list | get \u003Cendpoint-id> | delete \u003Cendpoint-id>\nrunpodctl serverless create --name \"x\" --template-id \u003Cid> --min-cuda-version 12.8   # from template\nrunpodctl serverless create --name \"x\" --hub-id \u003Clisting-id>    # from hub (+ --env KEY=VAL to override defaults)\nrunpodctl serverless create --hub-id \u003Cid> --gpu-id \"NVIDIA GeForce RTX 4090\" \\\n  --model-reference https:\u002F\u002Fhuggingface.co\u002F\u003Corg>\u002F\u003Cmodel>:main   # attach & host-cache a HF model (GPU only)\nrunpodctl serverless update \u003Cendpoint-id> --workers-max 5\nrunpodctl serverless create --template-id \u003Cid> --workers-min 1 --wait          # block until a worker is ready (v2.9.0+)\n```\n\n**Invoke URLs come back with the endpoint:** `create`\u002F`get`\u002F`list`\u002F`update` include a `urls` object (`run`, `runsync`, `health`), so read them instead of assembling the URL. They're built from `RUNPOD_INVOKE_URL` (default `https:\u002F\u002Fapi.runpod.ai\u002Fv2`), which `RUNPOD_API_URL`\u002F`RUNPOD_GRAPHQL_URL` do **not** move: [reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md#serverless-invoke-urls).\n\n**Reading worker logs** (v2.10.0+), first-class, so worker output needs neither the MCP lane nor a hand-built SSE read:\n\n```bash\nrunpodctl serverless logs \u003Cendpoint-id>                       # every worker's recent logs, json lines, each tagged with its workerId\nrunpodctl serverless logs \u003Cendpoint-id> --worker \u003Cworker-id>  # just one worker\nrunpodctl serverless logs \u003Cendpoint-id> --follow              # picks up workers that scale up mid-follow\nrunpodctl serverless logs \u003Cendpoint-id> --since 1h --source system   # why a worker will not start\n```\n\nThe crash-loop tell is under [Serverless facts](#serverless-facts-context-not-rules).\n\n**Invoking an endpoint** (v2.9.0+), first-class, so an agent does not hand-build a curl request or manage a bearer token:\n\n```bash\nrunpodctl serverless run \u003Cendpoint-id> --input '{\"prompt\":\"hello\"}'   # submit and wait for the result\nrunpodctl serverless run \u003Cendpoint-id> --input-file payload.json      # same, payload from a file (\"-\" = stdin)\nrunpodctl serverless run \u003Cendpoint-id> --input '{}' --wait 15m        # longer budget (default 5m)\nrunpodctl serverless run \u003Cendpoint-id> --input '{}' --no-wait         # submit, print the queued job, exit 0\nrunpodctl serverless status \u003Cendpoint-id> \u003Cjob-id>                    # check a job submitted earlier\nrunpodctl serverless health \u003Cendpoint-id>                             # worker + job counts\n```\n\n- **Pass only the handler payload:** the cli wraps it as `{\"input\": \u003Cyour json>}` itself, so pasting a whole curl envelope double-wraps it.\n- **`timeout` means the cli stopped waiting, not that the endpoint broke.** When the message names a `serverless status` command the job is still running server-side: poll it, do **not** re-invoke (that buys a second job).\n\nPayload rules, the stdout\u002Fstderr split, exit codes and why `\u002Frunsync` is never used → [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#invoking-an-endpoint-serverless-run-v290).\n\n**Create from hub:** `--hub-id` resolves the hub listing, extracts the build image and config (GPU IDs, container disk, env vars), creates an inline template, and deploys. Accepts both SERVERLESS and POD listing types. The hub config's GPU IDs and env defaults are included automatically; override with `--gpu-id` and `--env`.\n\n**CPU serverless endpoints** (rule in Decision Rules): `runpodctl serverless create --compute-type CPU` (optionally `--instance-id`, e.g. `cpu3g-4-16`). The 2026-07-14 evidence against REST v1, and why the invoke API is unaffected: [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#cpu-endpoints-and-rest-v1).\n\n**Model cache (`--model-reference`, GPU only, runpodctl v2.4.0+):** attach a Hugging Face model by full URL with a ref (`…:main`); Runpod caches it host-side in the standard HF cache dir (`\u002Frunpod-volume\u002Fhuggingface-cache\u002Fhub\u002F`), so the worker loads it directly: no bake, no volume. Works with `--template-id` and `--hub-id`. Example, the one-cached-model limit, and how it compares to baking \u002F network volume \u002F the Model Repository: **[reference\u002Fmodel-caching.md](reference\u002Fmodel-caching.md)**. Worked end-to-end: golden path [20 — model-caching endpoint](..\u002Frunpod\u002Fgolden-paths\u002F20-model-caching-endpoint.md).\n\n**Multi-region \u002F HA:** `--network-volume-ids \u003Cv1>,\u003Cv2> --data-center-ids \u003Cdc1>,\u003Cdc2>` (one volume per DC; **runpodctl ≥ v2.4.0**, and the Homebrew tap can lag). Data does **not** sync between volumes: golden path [10](..\u002Frunpod\u002Fgolden-paths\u002F10-multi-region-ha-serverless.md). Model-reference output on `update` and the `--clear-models` shape: [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#endpoint-update-and-zero-values).\n\n### Templates (alias: tpl)\n\n```bash\nrunpodctl template search \u003Cq>                        # find (+ template list [--type official\u002Fcommunity\u002Fuser, --all, --limit])\nrunpodctl template get \u003Ctemplate-id>                 # details (README, env, ports)\nrunpodctl template create --name \"x\" --image \"img\" [--serverless]\nrunpodctl template delete \u003Ctemplate-id>\n```\n\n### Network Volumes (alias: nv)\n\n```bash\nrunpodctl network-volume list | get \u003Cvolume-id> | delete \u003Cvolume-id>\nrunpodctl network-volume create --name \"x\" --size 100 --data-center-id \"US-GA-1\"\nrunpodctl network-volume update \u003Cvolume-id> --name \"new\"\nrunpodctl network-volume upload \u003Cvolume-id> \u003Clocal-path> [remote-path]    # v3.1.0+\nrunpodctl network-volume download \u003Cvolume-id> \u003Cremote-path> [local-path]  # \"\u002F\" = whole volume\n```\n\nExact flags: `runpodctl network-volume \u003Caction> --help`.\n\n**Upload\u002Fdownload** use the volume's S3 API, so they need **S3 API keys** (`RUNPOD_S3_ACCESS_KEY` \u002F `RUNPOD_S3_SECRET_KEY`), separate from the API key, and a [data center with the S3 API](https:\u002F\u002Fdocs.runpod.io\u002Fstorage\u002Fs3-api). On `transfer_incomplete`, rerun the same command; resume rules, `--force` and partial files: [command-reference File Transfer](reference\u002Fcommand-reference.md#file-transfer).\n\n> **No storage-tier flag.** `create` provisions the data center's **default** tier; there's no `--type`. For a **High-Performance** volume use the console (a ⚡ data center's toggle), a raw **v2 REST** call (`POST https:\u002F\u002Fv2-rest.runpod.io\u002Fv2\u002Fnetwork-volumes` with `\"type\":\"HIGH_PERFORMANCE\"`), or the MCP `create-network-volume` tool's `volumeType` (`STANDARD` | `HIGH_PERFORMANCE`). Tier is immutable after creation. Launch details: golden path [21](..\u002Frunpod\u002Fgolden-paths\u002F21-storage-tiers.md).\n\n### Models (Model Repository)\n\n`runpodctl model` manages the **Runpod Model Repository**: managed, versioned storage for your **own** model artifacts (upload once, distributed to workers; not pinned to a data center like a network volume). What it is, why\u002Fhow, migrating off a baked-in model, and Model-Repo-vs-volume: **[reference\u002Fmodel-caching.md](reference\u002Fmodel-caching.md)**.\n\n```bash\nrunpodctl model list [--all] [--name \"llama\"] [--provider \"meta\"]   # yours by default; --all = not just yours\nrunpodctl model add --name \"my-model\" --model-path .\u002Fmodel   # upload a local model dir (multipart)\nrunpodctl model remove --name \"my-model\" --owner \u003Cowner>\n```\n\n`model add` also supports upload sessions, versioning, metadata, and private-source credentials: see live `runpodctl model add --help`.\n\n### Info & SSH\n\n```bash\nrunpodctl user                                       # account info + balance (alias: me)\nrunpodctl gpu list                                   # available GPUs + $\u002Fhr + per-DC stock (+ --include-unavailable)\nrunpodctl datacenter list                            # datacenters (alias: dc)\nrunpodctl ssh info \u003Cpod-id>                          # SSH connection details (command + key; NOT an interactive session)\n```\n\n**`gpu list` carries pod on-demand pricing and a `dataCenterAvailability[]` breakdown.** When a create must land in a specific DC, read the breakdown (top-level `stockStatus` is only the best across DCs) and pass `--include-unavailable` (the default listing hides no-stock GPUs and can omit one that has stock only in your DC). Shape, stock vocabulary, `null` prices and the `\"none\"` vs omitted-key sentinel: [reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md#gpu-pricing-and-per-data-center-availability).\n\nRegistry auth, `billing` and SSH key management: [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md). Host key pinning (which versions pin, and why **`ssh forget` needs the operator's go-ahead**): [Pod host key trust](reference\u002Fcommand-reference.md#pod-host-key-trust-v2150).\n\n### File Transfer\n\n```bash\nrunpodctl send \u003Cpath>                                # prints a one-time code, then blocks until the receiver connects\nrunpodctl receive \u003Ccode>                             # positional code (no --code flag)\n```\n\nEncrypted\u002Fincremental\u002Fcompressed: don't pre-tar. **Key gotchas:** capture the **first line of `send` stdout** (the code) as it streams (background + tee); each `send` mints a **fresh** code; both sides must exit `0`. Full agent flow (pod push via `ssh` + `receive`): [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#file-transfer).\n\n### Utilities\n\n`runpodctl doctor` (diagnose and fix CLI issues), `update`, `version`, `completion` (auto-detects the shell and installs completion).\n\n## URLs\n\n- **Pod:** `https:\u002F\u002F\u003Cpod-id>-\u003Cport>.proxy.runpod.net` for an exposed port (e.g. `https:\u002F\u002Fabc123xyz-8888.proxy.runpod.net`).\n- **Serverless:** prefer `runpodctl serverless run|status|health` (same api, with auth, validation and bounded polling handled) and the `urls` object the endpoint commands return. Use raw urls only for what the commands don't cover: streaming, the OpenAI-compatible route, or a copy-paste `curl` for a user. Only `status\u002F\u003Cjob-id>` has to be built by hand.\n\n```\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Frun        # Async request\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Frunsync    # Sync request\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Fhealth     # Health check\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Fstatus\u002F\u003Cjob-id>  # Job status\n```\n\n## Source & docs\n\n- CLI source: https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\n- Releases (binaries): https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Freleases\n- Docs: https:\u002F\u002Fdocs.runpod.io\u002Frunpodctl\u002Foverview\n","# Runpodctl\n\nManage GPU pods, serverless endpoints, templates, volumes, and models. For serverless development workflows, use the [Runpod SDK](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-python) regardless of CLI version.\n\n## Install\n\n`curl -fsSL https:\u002F\u002Fcli.runpod.net | sudo bash` (Linux\u002FmacOS, and Windows via WSL) or `brew install runpod\u002Frunpodctl\u002Frunpodctl`. Manual binaries and the Windows and conda steps: the [runpodctl README](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl#install), beside the `install.sh` they describe. API key: https:\u002F\u002Fconsole.runpod.io\u002Fuser\u002Fsettings\n\n> Old builds silently lack newer flags\u002Fbehaviors (e.g. `--model-reference` doesn't exist before\n> v2.4.0) and produce confusing downstream errors, and the Homebrew tap can lag well behind.\n> Before any work: **update to the latest build** (`runpodctl version`, then `runpodctl update`,\n> or reinstall from the [latest release](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Freleases)); **pin one\n> recent version for the whole task**; **never switch between an old and a new binary mid-task**\n> (a known failure); **verify once** with `runpodctl version` before you continue.\n\n## Quick start\n\n```bash\nrunpodctl update && runpodctl version   # FIRST: latest build, confirmed, before any work\nexport RUNPOD_API_KEY=your_key      # agents: non-interactive auth, read by runpodctl\nrunpodctl doctor                    # humans: interactive first-time setup (prompts for API key + SSH keys); not for scripted use\nrunpodctl pod create --help         # inspect exact current flags before creating\nrunpodctl gpu list                  # GPU types\nrunpodctl datacenter list           # GPU availability per data center (co-locate GPU + volume)\nrunpodctl hub search vllm           # find a hub repo\nrunpodctl serverless create --hub-id \u003Cid> --name \"my-vllm\"  # deploy from hub\nrunpodctl template search pytorch   # find a template\nrunpodctl pod create --template-id runpod-torch-v280 --gpu-id \"NVIDIA GeForce RTX 4090\" --min-cuda-version 12.8  # create from template\nrunpodctl pod list                  # your pods\n```\n\n## Live Help Is Authoritative\n\nLive `runpodctl --help`, `runpodctl \u003Cresource> --help` and `runpodctl \u003Cresource> \u003Caction> --help` are authoritative for exact flags, aliases, and syntax (the generated pages under [`runpodctl\u002Fdocs\u002F`](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Ftree\u002Fmain\u002Fdocs) mirror them). Inspect live help before unfamiliar commands; this skill covers workflows, decision rules, safety notes, and common examples, and is not an exhaustive flag reference.\n\nLive help does **not** cover output shapes, error codes, or exit-code behavior: use [reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md), and when in doubt **probe the binary** (run it wrong on purpose, e.g. `runpodctl serverless get nope`, and read the JSON). Every doc is a snapshot, this skill included; the binary in front of you wins.\n\n## Output & errors\n\nData is **JSON on stdout** (`--output=yaml` is the only alternative; there is no table format; v2.10.0+ rejects any other value with `usage_error`, v2.9.0 and earlier silently return JSON). A failure is one flat JSON object on **stderr** plus a **non-zero exit**:\n\n```jsonc\n{\"error\":\"failed to get endpoint: endpoint not found\",\"code\":\"not_found\",\"status\":404}\n```\n\n- **Branch on `code`, never on `status` or the message** (GraphQL reports a missing resource as HTTP 200 + null data, so `status` is often absent).\n- **Retry with backoff only on `network_error`, `rate_limited`, `server_error`;** the API commands never retry internally. `no_credentials` = no key set (for `network-volume upload`\u002F`download`: no S3 API keys, or no API key for the data-center lookup, which `--data-center-id` skips; the message names which); `unauthorized`\u002F`forbidden` = a key is set but wrong or lacks access (don't re-prompt). `usage_error`, `cli_error`, `bad_request`, `not_found`, `conflict`: fix the input. Any other code is fatal: surface `error` verbatim.\n- **`network-volume upload`\u002F`download` (v3.1.0+) retry on their own** (429, 5xx, dropped connections). `transfer_incomplete` = it stopped partway: **rerun the same command**, it resumes. `volume_full` = grow the volume (`network-volume update --size`), then rerun.\n- **Gate on the exit code, then parse stderr:** deprecation `warning:`\u002F`note:` lines go to stderr on success too.\n- **Coded errors, the serverless `urls` object and GPU pricing need runpodctl ≥ v2.8.0.** Older binaries emit `{\"error\":\"…\"}` with no `code`, so gate on `code` being present, not on `runpodctl version`.\n- **`project` behaves differently per build** (exit 0 with errors on stdout through v3.0.1; exit 1 with a Runpod SDK notice in builds with [runpod\u002Frunpodctl#382](https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Fpull\u002F382)). Treat that notice as fatal.\n\nFull code table, `cli_error` vs `usage_error`, plain-text exceptions, the exact SDK notice, and the env-var table (incl. `RUNPOD_INVOKE_URL`): **[reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md)**.\n\n## Decision Rules\n\n- **Hub** for a known deployable app or worker (vLLM, ComfyUI, Whisper, a Runpod-maintained repo). **Picking a worker:** prefer a **first-party or well-adopted, recently-released** worker on a **broad, high-availability GPU pool**; signals in `runpodctl hub list`: `--owner runpod-workers` (first-party), `--order-by releasedAt`\u002F`updatedAt` (recency), `--order-by deploys`\u002F`stars` (adoption). Don't pin a scarce large-GPU tier a small model doesn't need.\n- **Templates** when the user already has a template ID, wants reusable image\u002Fconfig defaults, or needs lower-level control than Hub. **`pod create --image`** for a specific Docker image with no saved template.\n- **Serverless** for request\u002Fresponse inference APIs and scalable workers; **pods** for interactive work, notebooks, training, debugging, or long-lived sessions. **CPU pods** for preprocessing, file movement, lightweight scripts, and non-CUDA work; **GPU pods** when CUDA, model inference, training, or GPU memory is required.\n- **\"Active worker\" = minimum workers, not maximum:** `--workers-min 1` (one worker always warm → no cold start; ideal for development\u002Fiteration), **not** `--workers-max 1` (that only caps the ceiling).\n- ⚠️ **A min-1 worker bills continuously, even while idle** (it defeats scale-to-zero). After dev you **must** set `--workers-min 0` (or delete the endpoint), or it quietly runs up cost.\n  - **Needs runpodctl ≥ v2.10.0.** Earlier binaries **silently dropped** `--workers-min 0` and `--idle-timeout 0` from the update request (`omitempty` ate the zero): the reset looked applied and the endpoint kept billing. Check `runpodctl version`; on an older binary confirm with `serverless get \u003Cid>` and fall back to `PATCH https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fserverless\u002F\u003Cid>` with an explicit `{\"workers\":{\"min\":0}}`.\n- **Set the execution timeout on every endpoint create.** A v2 create without `timeout` comes back `\"timeout\": 0` (live-verified 2026-10-29; [why it matters](..\u002Frunpod-usage\u002Freference\u002Fgotchas.md#endpoint-timeout-comes-back-0)). runpodctl ≥ 2.14.0 has `serverless create --execution-timeout \u003Cseconds>` (as of 2.14.0 `serverless update` does not; check `--help`); read the timeout back with `serverless get`, and fix a 0 with `PATCH https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fserverless\u002F\u003Cid>` `{\"timeout\":\u003Cms>}`.\n- `serverless update` has **no `--gpu-id` flag**. To change an endpoint's GPU pools, `PATCH https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fserverless\u002F\u003Cid>` with `{\"gpu\":{\"pools\":[\"ADA_24\"]}}` (pool ids, from the `pool` field of `GET \u002Fv2\u002Fcatalog\u002Fgpus`). Sending `pools` without `excludedTypes` clears any exclusions.\n- **CPU serverless endpoints:** `runpodctl serverless create --compute-type CPU` (on REST v2, send `cpu` instead of `gpu`). **Never** send `\"computeType\":\"CPU\"` to REST v1 `POST https:\u002F\u002Frest.runpod.io\u002Fv1\u002Fendpoints`: it silently provisions a **GPU** endpoint ([evidence](reference\u002Fcommand-reference.md#cpu-endpoints-and-rest-v1)).\n- **Leave `--cloud-type` at its `SECURE` default** ([why](..\u002Frunpod-usage\u002Freference\u002Fgpu-selection.md#step-5-secure-vs-community-cloud)). Pass `--cloud-type COMMUNITY` only when the user explicitly asks (a public port 22 there needs a machine with a public IP, which the CLI cannot request).\n- A CPU pod gets 2 vCPUs on whichever CPU flavor has the most stock; `--name` defaults to the image name without its tag. CPU pods take a network volume (`--network-volume-id`) but not a pod volume (`--volume-in-gb` is rejected). Do not pass GPU flags.\n- **Set a CUDA floor on every GPU create: `--min-cuda-version 12.8`** (`pod create` and `serverless create`; not `template create`). Without it a modern image can land on a host too old to run it, and the create will not reject it: the container dies at startup or silently runs on CPU. `13.0` only for a CUDA-13 image; omit for CPU. Rule, exceptions and capacity check: [`runpod-usage` gpu-selection \"pin the CUDA floor\"](..\u002Frunpod-usage\u002Freference\u002Fgpu-selection.md#step-3-pin-the-cuda-floor).\n- **Waiting for a resource to be usable: use `--wait`, don't hand-roll a poll loop** (v2.9.0+). `create` returns once the resource is *scheduled*, which is why a \"RUNNING\" pod often refuses ssh and a fresh endpoint 404s. `pod create --wait` returns when port 22 answers with an ssh banner. `pod create --wait-for running` (v2.15.0+) returns when the container is up, no ssh needed: use it when container-up is all the task needs, or for an image that does not start sshd (most cpu images, since cpu pods get no Runpod-managed ssh), where plain `--wait` would bill through the whole timeout and then fail; a cpu image that starts its own sshd still satisfies plain `--wait`, so keep that when the user needs ssh. `serverless create --wait` returns when `\u002Fhealth` reports a ready or running worker. On timeout or ctrl-c the resource is **kept** and its id is in the error object's `id` field: read it and clean up, don't assume nothing was created (a pod bills by the second; an endpoint with no running worker doesn't, but starts one on the first request).\n- **A service on a pod** (Ollama, ComfyUI, a dev server): declare its `--ports` and `--env` at creation when possible (`runpodctl pod update` can change them on an existing pod), then follow the pod development loop in `runpod-usage` (`reference\u002Fpod-workflows.md`): SSH-exec the install, bind to `0.0.0.0`, poll the proxy URL until it answers.\n- **SSH:** connection details from `runpodctl pod get \u003Cpod-id>` or `runpodctl ssh info \u003Cpod-id>`. runpodctl has **no interactive-shell command**: `ssh info` returns the connection command + key but does not connect, so run `ssh user@host \"command\"` yourself.\n- Network volumes are location-sensitive: pick the data center from the GPU stock read (`datacenter list`, or `gpu list --include-unavailable`) before creating the volume, and create it once. If `pod create` is then refused for stock, re-read stock: retry once with the same volume when its data center shows stock; otherwise ask the user (wait, another GPU type there, the console's Deploy when available, or a move to another data center, which is the user's call). Never delete the volume to try another data center; on a move, name it in the hand-back (id, data center, storage cost) and delete it only when the user asks. Move data onto or off a volume with `network-volume upload` \u002F `download` (v3.1.0+, resumable); `send` \u002F `receive` for machine to machine.\n- Clean up paid resources after tests: serverless endpoints, pods, and temporary volumes created for validation.\n  - **Cost guard:** remove the pod when the work is done (`runpodctl pod remove \u003Cpod-id>`); a stopped pod still bills for disk and any volume. Unattended deadline: [pod-workflows](..\u002Frunpod-usage\u002Freference\u002Fpod-workflows.md#2-provision) (schedule a stop from inside the pod).\n  - **`--stop-after` \u002F `--terminate-after` never worked.** Before v2.12.0 `pod create` accepts both, but the backend never enforced them, so the pod keeps running and billing past the deadline; v2.12.0 removed them. If `runpodctl pod create --help` still lists them, run `runpodctl update`. Never offer them as a cost guard.\n  - **Attached volume:** to delete a network volume, remove the pod using it first.\n\n### Serverless facts (context, not rules)\n\n- **Scale-to-zero billing:** endpoints scale to zero with `--workers-min 0` (the default): no GPU billing while idle, only per request-second; the right cost posture for a request\u002Fresponse API.\n- **Broken-image tell:** deployed workers go `ready` but jobs sit `IN_QUEUE` with `inProgress: 0` → the image is broken\u002Fmis-dispatching; switch to a different worker rather than wait it out.\n- **Diagnosing it:** worker\u002Fjob counts with `runpodctl serverless health \u003Cendpoint-id>` (v2.9.0+), then what the workers printed with `runpodctl serverless logs \u003Cendpoint-id>` (v2.10.0+); no hand-built curl needed. Repeated `system` \"start container\" lines with no `container` output = the container exits before the handler runs.\n\n## Commands\n\nEssentials only; flags come from `--help`. [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md) holds what `--help` cannot answer: what a flag *means* when it succeeds, which field to trust, and what a failure looks like.\n\n### Pods\n\n```bash\nrunpodctl pod list                                   # running pods (+ --all \u002F --status \u002F --since \u002F --created-after)\nrunpodctl pod get \u003Cpod-id>                           # details incl. SSH info + runtimeStatus\nrunpodctl pod create --template-id \u003Cid> --gpu-id \"NVIDIA GeForce RTX 4090\" --min-cuda-version 12.8   # from template (or --image \u003Cimg>)\nrunpodctl pod create --compute-type cpu --image ubuntu:22.04                 # CPU pod (2 vCPUs; name defaults to the image)\nrunpodctl pod create --image \u003Cimg> --gpu-id \u003Cid> --wait                      # block until ssh answers, then print the pod (v2.9.0+)\nrunpodctl pod create --compute-type cpu --image ubuntu:22.04 --wait-for running  # block until the container is up; no sshd needed (v2.15.0+)\nrunpodctl pod {start|stop|restart|update|delete} \u003Cpod-id>                    # lifecycle (delete aliases: rm\u002Fremove)\nrunpodctl pod logs \u003Cpod-id> [--follow] [--since 30m --source system]          # recent container+system logs, json lines (v2.10.0+); --follow keeps streaming and reconnects on its own; --source system = platform view: image pull \u002F create \u002F start\n```\n\nrunpodctl v3.0.0 removed `pod reset`; use `pod restart` only when a restart is intended.\n\n**A stalled deploy shows up in `--source system`** (v2.10.0+): repeated pull progress, or a `create container` that never reaches `start`. `--source container` is your workload's own output. Each line is one `{source,line,ts}` object; pipe it to `jq`.\n\n**Read `runtimeStatus`, not `desiredStatus`, to decide whether a pod is usable** (v2.9.0+): `desiredStatus: RUNNING` says that while the image is still pulling. Field meanings, reason tokens, and two edges (`--status` filters `desiredStatus` only; `unknown` = lookup failed, not pod down) → [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#pod-status-fields).\n\n### Hub\n\nBrowse\u002Fsearch existing Runpod Hub listings; pick the execution lane with the [router capability matrix](..\u002Frunpod\u002FSKILL.md#runpod-mcp-vs-runpodctl-the-overlap). Authoring a project's Hub listing files: [runpod-build-template](..\u002Frunpod-build-template\u002FSKILL.md).\n\n```bash\nrunpodctl hub search vllm                            # find a repo (+ hub list [--type\u002F--category\u002F--order-by\u002F--owner])\nrunpodctl hub get \u003Clisting-id|owner\u002Fname>            # repo details\n```\n\n### Serverless (alias: sls)\n\n```bash\nrunpodctl serverless list | get \u003Cendpoint-id> | delete \u003Cendpoint-id>\nrunpodctl serverless create --name \"x\" --template-id \u003Cid> --min-cuda-version 12.8   # from template\nrunpodctl serverless create --name \"x\" --hub-id \u003Clisting-id>    # from hub (+ --env KEY=VAL to override defaults)\nrunpodctl serverless create --hub-id \u003Cid> --gpu-id \"NVIDIA GeForce RTX 4090\" \\\n  --model-reference https:\u002F\u002Fhuggingface.co\u002F\u003Corg>\u002F\u003Cmodel>:main   # attach & host-cache a HF model (GPU only)\nrunpodctl serverless update \u003Cendpoint-id> --workers-max 5\nrunpodctl serverless create --template-id \u003Cid> --workers-min 1 --wait          # block until a worker is ready (v2.9.0+)\n```\n\n**Invoke URLs come back with the endpoint:** `create`\u002F`get`\u002F`list`\u002F`update` include a `urls` object (`run`, `runsync`, `health`), so read them instead of assembling the URL. They're built from `RUNPOD_INVOKE_URL` (default `https:\u002F\u002Fapi.runpod.ai\u002Fv2`), which `RUNPOD_API_URL`\u002F`RUNPOD_GRAPHQL_URL` do **not** move: [reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md#serverless-invoke-urls).\n\n**Reading worker logs** (v2.10.0+), first-class, so worker output needs neither the MCP lane nor a hand-built SSE read:\n\n```bash\nrunpodctl serverless logs \u003Cendpoint-id>                       # every worker's recent logs, json lines, each tagged with its workerId\nrunpodctl serverless logs \u003Cendpoint-id> --worker \u003Cworker-id>  # just one worker\nrunpodctl serverless logs \u003Cendpoint-id> --follow              # picks up workers that scale up mid-follow\nrunpodctl serverless logs \u003Cendpoint-id> --since 1h --source system   # why a worker will not start\n```\n\nThe crash-loop tell is under [Serverless facts](#serverless-facts-context-not-rules).\n\n**Invoking an endpoint** (v2.9.0+), first-class, so an agent does not hand-build a curl request or manage a bearer token:\n\n```bash\nrunpodctl serverless run \u003Cendpoint-id> --input '{\"prompt\":\"hello\"}'   # submit and wait for the result\nrunpodctl serverless run \u003Cendpoint-id> --input-file payload.json      # same, payload from a file (\"-\" = stdin)\nrunpodctl serverless run \u003Cendpoint-id> --input '{}' --wait 15m        # longer budget (default 5m)\nrunpodctl serverless run \u003Cendpoint-id> --input '{}' --no-wait         # submit, print the queued job, exit 0\nrunpodctl serverless status \u003Cendpoint-id> \u003Cjob-id>                    # check a job submitted earlier\nrunpodctl serverless health \u003Cendpoint-id>                             # worker + job counts\n```\n\n- **Pass only the handler payload:** the cli wraps it as `{\"input\": \u003Cyour json>}` itself, so pasting a whole curl envelope double-wraps it.\n- **`timeout` means the cli stopped waiting, not that the endpoint broke.** When the message names a `serverless status` command the job is still running server-side: poll it, do **not** re-invoke (that buys a second job).\n\nPayload rules, the stdout\u002Fstderr split, exit codes and why `\u002Frunsync` is never used → [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#invoking-an-endpoint-serverless-run-v290).\n\n**Create from hub:** `--hub-id` resolves the hub listing, extracts the build image and config (GPU IDs, container disk, env vars), creates an inline template, and deploys. Accepts both SERVERLESS and POD listing types. The hub config's GPU IDs and env defaults are included automatically; override with `--gpu-id` and `--env`.\n\n**CPU serverless endpoints** (rule in Decision Rules): `runpodctl serverless create --compute-type CPU` (optionally `--instance-id`, e.g. `cpu3g-4-16`). The 2026-07-14 evidence against REST v1, and why the invoke API is unaffected: [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#cpu-endpoints-and-rest-v1).\n\n**Model cache (`--model-reference`, GPU only, runpodctl v2.4.0+):** attach a Hugging Face model by full URL with a ref (`…:main`); Runpod caches it host-side in the standard HF cache dir (`\u002Frunpod-volume\u002Fhuggingface-cache\u002Fhub\u002F`), so the worker loads it directly: no bake, no volume. Works with `--template-id` and `--hub-id`. Example, the one-cached-model limit, and how it compares to baking \u002F network volume \u002F the Model Repository: **[reference\u002Fmodel-caching.md](reference\u002Fmodel-caching.md)**. Worked end-to-end: golden path [20 — model-caching endpoint](..\u002Frunpod\u002Fgolden-paths\u002F20-model-caching-endpoint.md).\n\n**Multi-region \u002F HA:** `--network-volume-ids \u003Cv1>,\u003Cv2> --data-center-ids \u003Cdc1>,\u003Cdc2>` (one volume per DC; **runpodctl ≥ v2.4.0**, and the Homebrew tap can lag). Data does **not** sync between volumes: golden path [10](..\u002Frunpod\u002Fgolden-paths\u002F10-multi-region-ha-serverless.md). Model-reference output on `update` and the `--clear-models` shape: [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#endpoint-update-and-zero-values).\n\n### Templates (alias: tpl)\n\n```bash\nrunpodctl template search \u003Cq>                        # find (+ template list [--type official\u002Fcommunity\u002Fuser, --all, --limit])\nrunpodctl template get \u003Ctemplate-id>                 # details (README, env, ports)\nrunpodctl template create --name \"x\" --image \"img\" [--serverless]\nrunpodctl template delete \u003Ctemplate-id>\n```\n\n### Network Volumes (alias: nv)\n\n```bash\nrunpodctl network-volume list | get \u003Cvolume-id> | delete \u003Cvolume-id>\nrunpodctl network-volume create --name \"x\" --size 100 --data-center-id \"US-GA-1\"\nrunpodctl network-volume update \u003Cvolume-id> --name \"new\"\nrunpodctl network-volume upload \u003Cvolume-id> \u003Clocal-path> [remote-path]    # v3.1.0+\nrunpodctl network-volume download \u003Cvolume-id> \u003Cremote-path> [local-path]  # \"\u002F\" = whole volume\n```\n\nExact flags: `runpodctl network-volume \u003Caction> --help`.\n\n**Upload\u002Fdownload** use the volume's S3 API, so they need **S3 API keys** (`RUNPOD_S3_ACCESS_KEY` \u002F `RUNPOD_S3_SECRET_KEY`), separate from the API key, and a [data center with the S3 API](https:\u002F\u002Fdocs.runpod.io\u002Fstorage\u002Fs3-api). On `transfer_incomplete`, rerun the same command; resume rules, `--force` and partial files: [command-reference File Transfer](reference\u002Fcommand-reference.md#file-transfer).\n\n> **No storage-tier flag.** `create` provisions the data center's **default** tier; there's no `--type`. For a **High-Performance** volume use the console (a ⚡ data center's toggle), a raw **v2 REST** call (`POST https:\u002F\u002Fv2-rest.runpod.io\u002Fv2\u002Fnetwork-volumes` with `\"type\":\"HIGH_PERFORMANCE\"`), or the MCP `create-network-volume` tool's `volumeType` (`STANDARD` | `HIGH_PERFORMANCE`). Tier is immutable after creation. Launch details: golden path [21](..\u002Frunpod\u002Fgolden-paths\u002F21-storage-tiers.md).\n\n### Models (Model Repository)\n\n`runpodctl model` manages the **Runpod Model Repository**: managed, versioned storage for your **own** model artifacts (upload once, distributed to workers; not pinned to a data center like a network volume). What it is, why\u002Fhow, migrating off a baked-in model, and Model-Repo-vs-volume: **[reference\u002Fmodel-caching.md](reference\u002Fmodel-caching.md)**.\n\n```bash\nrunpodctl model list [--all] [--name \"llama\"] [--provider \"meta\"]   # yours by default; --all = not just yours\nrunpodctl model add --name \"my-model\" --model-path .\u002Fmodel   # upload a local model dir (multipart)\nrunpodctl model remove --name \"my-model\" --owner \u003Cowner>\n```\n\n`model add` also supports upload sessions, versioning, metadata, and private-source credentials: see live `runpodctl model add --help`.\n\n### Info & SSH\n\n```bash\nrunpodctl user                                       # account info + balance (alias: me)\nrunpodctl gpu list                                   # available GPUs + $\u002Fhr + per-DC stock (+ --include-unavailable)\nrunpodctl datacenter list                            # datacenters (alias: dc)\nrunpodctl ssh info \u003Cpod-id>                          # SSH connection details (command + key; NOT an interactive session)\n```\n\n**`gpu list` carries pod on-demand pricing and a `dataCenterAvailability[]` breakdown.** When a create must land in a specific DC, read the breakdown (top-level `stockStatus` is only the best across DCs) and pass `--include-unavailable` (the default listing hides no-stock GPUs and can omit one that has stock only in your DC). Shape, stock vocabulary, `null` prices and the `\"none\"` vs omitted-key sentinel: [reference\u002Foutput-and-errors.md](reference\u002Foutput-and-errors.md#gpu-pricing-and-per-data-center-availability).\n\nRegistry auth, `billing` and SSH key management: [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md). Host key pinning (which versions pin, and why **`ssh forget` needs the operator's go-ahead**): [Pod host key trust](reference\u002Fcommand-reference.md#pod-host-key-trust-v2150).\n\n### File Transfer\n\n```bash\nrunpodctl send \u003Cpath>                                # prints a one-time code, then blocks until the receiver connects\nrunpodctl receive \u003Ccode>                             # positional code (no --code flag)\n```\n\nEncrypted\u002Fincremental\u002Fcompressed: don't pre-tar. **Key gotchas:** capture the **first line of `send` stdout** (the code) as it streams (background + tee); each `send` mints a **fresh** code; both sides must exit `0`. Full agent flow (pod push via `ssh` + `receive`): [reference\u002Fcommand-reference.md](reference\u002Fcommand-reference.md#file-transfer).\n\n### Utilities\n\n`runpodctl doctor` (diagnose and fix CLI issues), `update`, `version`, `completion` (auto-detects the shell and installs completion).\n\n## URLs\n\n- **Pod:** `https:\u002F\u002F\u003Cpod-id>-\u003Cport>.proxy.runpod.net` for an exposed port (e.g. `https:\u002F\u002Fabc123xyz-8888.proxy.runpod.net`).\n- **Serverless:** prefer `runpodctl serverless run|status|health` (same api, with auth, validation and bounded polling handled) and the `urls` object the endpoint commands return. Use raw urls only for what the commands don't cover: streaming, the OpenAI-compatible route, or a copy-paste `curl` for a user. Only `status\u002F\u003Cjob-id>` has to be built by hand.\n\n```\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Frun        # Async request\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Frunsync    # Sync request\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Fhealth     # Health check\nhttps:\u002F\u002Fapi.runpod.ai\u002Fv2\u002F\u003Cendpoint-id>\u002Fstatus\u002F\u003Cjob-id>  # Job status\n```\n\n## Source & docs\n\n- CLI source: https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\n- Releases (binaries): https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpodctl\u002Freleases\n- Docs: https:\u002F\u002Fdocs.runpod.io\u002Frunpodctl\u002Foverview\n",{"name":5,"license":15,"metadata":47,"description":7,"allowed-tools":59,"compatibility":60},{"author":9,"version":48,"concepts":49},"2.0.0",[5,50,51,52,35,53,54,55,56,57,58],"pod","cpu-pod","serverless-endpoint","network-volume","hub-repo","ssh-key","file-transfer","model-store","volume-cache","Bash(runpodctl:*)","Linux, macOS, Windows","main","91b9f9671af0f15186420ec466fe6e80c1b13f25","plugins\u002Frunpod\u002Fskills\u002Frunpodctl",10,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official","https:\u002F\u002Fdocs.runpod.io\u002Fagent-setup.md","https:\u002F\u002Fgithub.com\u002Frunpod","https:\u002F\u002Fwww.runpod.io","2026-11-10 06:32:38",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add runpod\u002Frunpod-plugins-official --skill runpodctl",{"tool":76,"command":77},"bunx","bunx skills add runpod\u002Frunpod-plugins-official --skill runpodctl",{"tool":79,"command":80},"pnpm","pnpm dlx skills add runpod\u002Frunpod-plugins-official --skill runpodctl","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002FSKILL.md",true,[84,90,94,98,102,106,110,114,118,122,126,130,134,138,142,146,150,154,158,162,166,170],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fcpu-pod-create.eval.md","REFERENCE","参考文档",642,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fcpu-pod-create.eval.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"evals\u002Fcpu-pod-wait-for-running.eval.md",1434,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fcpu-pod-wait-for-running.eval.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"evals\u002Fcreate-and-wait-until-usable.eval.md",1236,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fcreate-and-wait-until-usable.eval.md",{"path":99,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":100,"sourceHtmlUrl":101},"evals\u002Ferror-handling.eval.md",3405,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Ferror-handling.eval.md",{"path":103,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":104,"sourceHtmlUrl":105},"evals\u002Fhttps-install.eval.md",646,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fhttps-install.eval.md",{"path":107,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":108,"sourceHtmlUrl":109},"evals\u002Fhub-deploy-serverless.eval.md",1653,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fhub-deploy-serverless.eval.md",{"path":111,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":112,"sourceHtmlUrl":113},"evals\u002Fimage-to-template-to-serverless.eval.md",1327,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fimage-to-template-to-serverless.eval.md",{"path":115,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":116,"sourceHtmlUrl":117},"evals\u002Finvoke-urls-and-gpu-pricing.eval.md",2093,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Finvoke-urls-and-gpu-pricing.eval.md",{"path":119,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":120,"sourceHtmlUrl":121},"evals\u002Fmodel-cache-size-vs-volume.eval.md",2137,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fmodel-cache-size-vs-volume.eval.md",{"path":123,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":124,"sourceHtmlUrl":125},"evals\u002Fpod-auto-terminate.eval.md",1034,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fpod-auto-terminate.eval.md",{"path":127,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":128,"sourceHtmlUrl":129},"evals\u002Fpod-from-template-with-volume.eval.md",583,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fpod-from-template-with-volume.eval.md",{"path":131,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":132,"sourceHtmlUrl":133},"evals\u002Fpod-ssh-connect.eval.md",734,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fpod-ssh-connect.eval.md",{"path":135,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":136,"sourceHtmlUrl":137},"evals\u002Fpod-v2-lifecycle.eval.md",929,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fpod-v2-lifecycle.eval.md",{"path":139,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":140,"sourceHtmlUrl":141},"evals\u002Fprefer-secure-cloud.eval.md",1343,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fprefer-secure-cloud.eval.md",{"path":143,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":144,"sourceHtmlUrl":145},"evals\u002Fproject-sdk-notice.eval.md",3042,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fproject-sdk-notice.eval.md",{"path":147,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":148,"sourceHtmlUrl":149},"evals\u002Fregistry-password-stdin.eval.md",1124,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fregistry-password-stdin.eval.md",{"path":151,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":152,"sourceHtmlUrl":153},"evals\u002Fserverless-autoscale-by-requests.eval.md",816,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fserverless-autoscale-by-requests.eval.md",{"path":155,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":156,"sourceHtmlUrl":157},"evals\u002Fserverless-invoke-job.eval.md",1283,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fserverless-invoke-job.eval.md",{"path":159,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":160,"sourceHtmlUrl":161},"evals\u002Fstock-before-volume.eval.md",1751,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Fevals\u002Fstock-before-volume.eval.md",{"path":163,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":164,"sourceHtmlUrl":165},"reference\u002Fcommand-reference.md",18913,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Freference\u002Fcommand-reference.md",{"path":167,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":168,"sourceHtmlUrl":169},"reference\u002Fmodel-caching.md",16163,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Freference\u002Fmodel-caching.md",{"path":171,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":172,"sourceHtmlUrl":173},"reference\u002Foutput-and-errors.md",23283,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002Freference\u002Foutput-and-errors.md",[175,203,220,241,260,282],{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":187,"publishedAt":42},"01M717A4HFW93XQC7PTXV1QFFH","runpod-vllm","Serve a Hugging Face model with vLLM on Runpod (Hub worker-vllm queue endpoint, load-balancing endpoint on a vllm\u002Fvllm-openai image, or a Pod), sized, CUDA-pinned and verified with a real OpenAI client. Use for any \"deploy\u002Fserve\u002Ftest this LLM with vLLM\" request or a vLLM deployment that will not boot; defer to runpod-serverless-deploy for non-vLLM engines and runpod-endpoint-ops for an endpoint that already works.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-vllm\u002FSKILL.md",[181,184],{"categoryNo":182,"categoryName":183,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[188,9,189,34,40,190,191,192,193,194,195,32,196,197,198,199,28,200,201,202],"runpod vllm","vLLM","worker","image","log","port","request","release","verified","hugging face","openai","face","availability","load-balancing","for",{"skillNo":204,"name":9,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":209,"publishedAt":42},"01M6CFVTW32TE82Y5NA85H83CK","Start here when the Runpod lane is unclear: picks the skill for a task (runpod-mcp and the journey playbooks it routes to, such as runpod-serverless-deploy, runpod-pod-deploy, runpod-pod-doctor and runpod-cost-audit; runpodctl, runpod-flash, runpod-companion-clis, runpod-usage, runpod-templates, runpod-build-template, runpod-migrate) and indexes two dozen end-to-end worked examples (golden paths). Use it before any multi-step or provisioning task, even when the lane is clear, to check for a matching golden path; for the Runpod MCP tools, runpod-mcp owns the answer contract, connection and tool rules.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod\u002FSKILL.md",[208],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[9,38,210,35,32,211,34,212,213,214,215,216,28,217,218,30,219,5,41,25],"migrate","start","end","companion","paths","flash","golden","journey","audit","path",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":227,"publishedAt":42},"01M6CFVK41CSZ4HM1N7TKM3WWY","runpod-usage","Explain Runpod architecture and design choices: Pods versus Serverless, GPU\u002FVRAM, image construction, storage, networking, and workload development. For creating or improving a complete template project use runpod-build-template; execute infrastructure with runpodctl\u002Frunpod-mcp and code-first work with runpod-flash.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-usage\u002FSKILL.md",[226],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[228,9,229,5,230,231,232,38,233,191,234,235,236,237,34,202,238,239,190,240],"runpod usage","usage","development","container","design","use","code","explain","architecture","disk","project","complete","vram",{"skillNo":242,"name":243,"nameZh":6,"description":244,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":245,"categories":246,"keywords":248,"publishedAt":42},"01M6CFVEPPADDF61NC3MC4KCE5","runpod-templates","Find, use, and troubleshoot official Runpod Pod templates, including ComfyUI workflow model metadata repair. For creating or optimizing Dockerfiles and application template projects use runpod-build-template; deploy through runpod-mcp or runpodctl.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-templates\u002FSKILL.md",[247],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[249,250,9,5,251,252,253,40,254,38,255,191,37,35,193,256,257,258,259,202],"runpod templates","templates","projects","python3","official","inventory","workflow","scripts","troubleshoot","png","repair",{"skillNo":261,"name":262,"nameZh":6,"description":263,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":264,"categories":265,"keywords":269,"publishedAt":42},"01M6PP9W1XMN6PT4J4H0XEMTKW","runpod-serverless-deploy","Bring any source (a HuggingFace repo, a ComfyUI workflow, a Hub release, a custom container image, a GGUF repo, a Civitai asset, or a community template) to a proven Runpod Serverless endpoint: pick the engine for the modality and model format, size the GPU from the model's real metadata, provision, warm, prove it with one real job, and hand back the URL with what it bills. Deploys an existing source through the Runpod MCP tools; code-first Python deploys (the Flash dev loop) are out of scope. Use when the user wants a model or worker served on Runpod Serverless, whatever the modality: text generation, speech-to-text or text-to-speech, image or video generation, embeddings, document processing, or their own handler image. For an LLM served with vLLM (Hub worker-vllm, a vllm\u002Fvllm-openai image, or a vLLM Pod), defer to runpod-vllm.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-serverless-deploy\u002FSKILL.md",[266,267,268],{"categoryNo":182,"categoryName":183,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[270,9,271,272,273,274,275,276,34,277,278,40,279,190,38,280,281,255,191,25],"runpod serverless deploy","serverless deploy","deploy","serverless","back","Video","community","processing","scope","pick","loop","URL",{"skillNo":283,"name":284,"nameZh":6,"description":285,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":286,"categories":287,"keywords":289,"publishedAt":42},"01M6PP9PRZJJHNF10N95P2C10J","runpod-pod-doctor","Diagnose a Runpod Pod that is unreachable, GPU-blind or stuck, and perform a recovery action only when the user authorizes one. Use when an existing Pod misbehaves, through the Runpod MCP tools: its proxy URL answers 502, CUDA is not available inside the container, a restarted Pod has no GPU, the user wants a Pod's logs read, an account-wide check for stuck Pods, or the stop-versus-terminate decision for a Pod they already have. Read-only until the user asks for an action.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-pod-doctor\u002FSKILL.md",[288],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[290,9,41,291,34,292,293,38,294,281,237,295,192,193,296,297,30,298,200,25],"runpod pod doctor","pod doctor","decision","only","unreachable","logs","read","action","stop"]