runpod

Runpod CLI for managing GPU/CPU workloads from the terminal — pods, serverless endpoints, templates, network volumes, Hub deploys, models, SSH, and file transfer (send/receive). Use for terminal/CI/scripting, SSH setup, doctor, or when the Runpod MCP tools are not connected; prefer runpod-mcp for structured tool calls in an MCP-enabled session.

Write and deploy code-first Runpod Serverless with runpod-flash: @Endpoint/@remote, flash dev, resource configuration, and debugging. Use runpod-build-template for explicit Dockerfile/template project authoring, and runpodctl/runpod-mcp for infrastructure management.

Companion CLIs for Runpod workflows — HuggingFace, GitHub, Docker, and AWS. Use runpod-build-template for complete template project authoring, and the ComfyUI model-repair guide in runpod-templates for imported workflows lacking model download metadata.

Start here for any Runpod task — running GPU/CPU pods, deploying serverless endpoints, templates, network volumes, building images, or understanding how Runpod works. Routes to the right skill (runpod-mcp, runpodctl, flash, companion-clis, runpod-usage, runpod-templates, runpod-build-template, runpod-migrate) and indexes two dozen live-verified end-to-end examples (golden paths) — use it when the lane is unclear, and for any multi-step or provisioning task even when it is not.

Explain Runpod architecture and design choices: Pods versus Serverless, GPU/VRAM, image construction, storage, networking, and workload development. For creating or improving a complete template project use runpod-build-template; execute infrastructure with runpodctl/runpod-mcp and code-first work with flash.

Manage Runpod infrastructure through the connected Runpod MCP server's tool calls (pods, serverless endpoints and jobs, templates, network volumes, registry credentials, secrets, clusters, the GPU/CPU catalog, and billing), and connect the server when it is missing (hosted or local npx). Load it before the first Runpod MCP tool call of a request: it routes the task to the journey skill that carries the procedure, owns the answer contract and the rules on which resources you may change, and defers to runpodctl for the terminal, file transfer, and SSH setup; template project and Hub listing authoring routes to runpod-build-template.

Migrate a codebase from the Runpod GraphQL API or REST v1 to REST v2 — inventory which parts use which API version, rewrite the call sites, flag breaking changes, and verify. Use when someone asks to move to v2, asks what v2 would change, or asks which Runpod API their code is on. For managing infrastructure rather than migrating code, use runpod-mcp or runpodctl.

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.

Operate a Serverless endpoint that already exists: diagnose queued jobs and dying workers, tune scaling, idle timeout and FlashBoot safely, pin the GPU selection, and manage the queue (cancel a job, purge). Read-only by default; changes only the exact setting the user authorized, with a read before and after. Use when the user has an endpoint and asks why it is slow, stuck or failing, or wants one of its settings changed through the Runpod MCP tools.

Create, verify by read-back, and manage the lifecycle of Runpod's reusable plumbing (templates, network volumes, container registry credentials, account secrets, the account's SSH public keys, and Instant Clusters), plus staging large model files on a volume and diagnosing a private-image pull failure. Use when the user wants one of those resources created, changed, inspected or removed through the Runpod MCP tools, or asks where a volume should live so a GPU can mount it. Also use for an account cleanup request: only what this conversation created may be removed; everything else is reported for the user to decide.

Read-only Runpod spend audit: find idle spend, explain serverless billing when nothing seems to run, break spend down by resource type and by resource, and give a whole-account snapshot. Every figure comes from the MCP billing and list reads; it recommends actions and never stops or changes anything. Use when the user asks about their bill, what is costing money, what is running on the account, or tells you to stop or delete idle resources it did not name by id: the audit with ids and the user's own next steps is the answer. A resource the user names by id goes to pod-doctor or endpoint-ops, and the change is made.

Answer what is available, what fits and the price against Runpod's catalogs: GPU and CPU types with price, live stock per data center and per product, the CUDA versions that have capacity, the Hub worker marketplace, the public template catalog, and the pay-per-use Public Endpoints. Read-only: it filters to the user's real constraint, sizes a model's VRAM need against real stock, quotes price and stock from the reads, and says "none found" rather than inventing an entry. Use when the user asks a catalog, sizing, availability or price question that does not ask to create anything through the Runpod MCP tools.

Provision a Runpod Pod for interactive, development or training use and tell the user exactly how to connect to it. Reads stock before creating, picks the image and GPU class from the catalog reads, exposes only the ports the workload needs, hands back the working proxy URL or SSH address, and for training co-locates a network volume so checkpoints outlive the Pod. Also covers creating a Pod and stopping it immediately, so that only its disk bills until the user comes back. Use when the user wants a GPU or CPU machine of their own (a web app, Jupyter, SSH, a training box) rather than a Serverless endpoint, through the Runpod MCP tools.

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.

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.

Create or improve a complete Runpod template project from an application request, local code, or GitHub repository, with a documented Dockerfile and app-specific files for Pods or queue/load-balanced Serverless. Use runpod-templates for finding or operating existing official templates, runpod-mcp/runpodctl to register an already-built image as a template, flash for its code-first workflow, and companion-clis for standalone image build/push commands.