runpod-ops

Stars10

Forks2

UpdatedJuly 14, 2026 at 02:10

RunPod endpoint operations runbook — checking worker state, forcing scale-down, reading the spend query, and cold-start expectations. Use before and after cloud inference sessions. Forward-looking — RunPod tooling lives outside this repo.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

alejandroJaramillo87

alejandroJaramillo87/ai-experiments

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Network and Computer Systems AdministratorsComputer and Mathematical Occupations·SOC 15-1244

SKILL.md

readonly

name	runpod-ops
description	RunPod endpoint operations runbook — checking worker state, forcing scale-down, reading the spend query, and cold-start expectations. Use before and after cloud inference sessions. Forward-looking — RunPod tooling lives outside this repo.

RunPod operations runbook

Reference for managing RunPod serverless/pod endpoints used for cloud inference and training. RunPod itself is external to this repository; this skill captures the operating procedure so sessions do not leave workers running or misread spend.

Status: forward-looking. Wire the concrete commands to whatever RunPod CLI / API wrapper the integration roadmap lands (make agent-usage becomes the spend entry point). Until then, treat the steps below as the checklist and use the RunPod console/API directly.

Sandboxed execution: agents have no access to the host, its make targets, or the RunPod console. The human executes each checklist step and reports the result; the agent tracks the checklist and records the reported worker state and spend.

Before a cloud session

Confirm the target endpoint exists and its image tag is pinned (no :latest).
Check current worker state: how many workers are warm vs cold, and max-worker cap.
Note expected cold start: first request after scale-to-zero pays image pull + model load; do not attribute that latency to inference.

During

Keep an eye on active worker count; a stuck request can hold a worker (and spend) open.
Route measurement work through the bench protocol (see the benchmarking skill) so cloud numbers are comparable to local ones and cold-start runs are discarded.

After a cloud session (required)

Force scale-down to zero workers so idle GPUs stop billing.
Verify no workers remain warm.
Read the spend query (via make agent-usage once wired) and record it against the task.

The skeptic and the primary agent both run this checklist: primary before starting cloud work, skeptic when verifying a "completed" cloud task actually released its resources.

More from this repository

same repository

training-runs

alejandroJaramillo87/ai-experiments

How to launch, resume, and serve model training runs on this stack — checkpoint layout, the memory-fit calculator, and the train-and-serve round trip. Skeleton reference; grows once the training tier lands.

2026-07-1610

docker-debug

alejandroJaramillo87/ai-experiments

Container debugging runbook for this inference stack — per-service healthcheck endpoints, common CUDA/driver failure signatures, log locations, and the safe restart procedure. Use when a service is unhealthy or failing to start.

2026-07-1410

benchmarking

alejandroJaramillo87/ai-experiments

The reproducible benchmark protocol for this workstation — which entry points to run, warm-up policy, how results are recorded and compared, and what counts as a regression. Use before reporting any latency/throughput/memory number.

2026-07-1410

name	runpod-ops
description	RunPod endpoint operations runbook — checking worker state, forcing scale-down, reading the spend query, and cold-start expectations. Use before and after cloud inference sessions. Forward-looking — RunPod tooling lives outside this repo.

RunPod operations runbook

Status: forward-looking. Wire the concrete commands to whatever RunPod CLI / API wrapper the integration roadmap lands (make agent-usage becomes the spend entry point). Until then, treat the steps below as the checklist and use the RunPod console/API directly.

Sandboxed execution: agents have no access to the host, its make targets, or the RunPod console. The human executes each checklist step and reports the result; the agent tracks the checklist and records the reported worker state and spend.

Before a cloud session

Confirm the target endpoint exists and its image tag is pinned (no :latest).
Check current worker state: how many workers are warm vs cold, and max-worker cap.
Note expected cold start: first request after scale-to-zero pays image pull + model load; do not attribute that latency to inference.

During

Keep an eye on active worker count; a stuck request can hold a worker (and spend) open.
Route measurement work through the bench protocol (see the benchmarking skill) so cloud numbers are comparable to local ones and cold-start runs are discarded.

After a cloud session (required)

Force scale-down to zero workers so idle GPUs stop billing.
Verify no workers remain warm.
Read the spend query (via make agent-usage once wired) and record it against the task.

The skeptic and the primary agent both run this checklist: primary before starting cloud work, skeptic when verifying a "completed" cloud task actually released its resources.