The page listed what each pod COSTS and nothing about what it is doing, so a
saturated pod and an idle one looked identical next to the same $/hr.

Read from the PODS, not from RunPod. A pod runs coderai, so it already serves
/admin/api/gpu-stats -- per-card util, VRAM used/total and temperature,
collected with nvidia-smi off its own event loop and cached there for 1.5s.
RunPod reports utilisation too, but it lags by tens of seconds and every read
spends the quota that renting and boot-polling need: a 429 there is what
stopped the fleet scaling for 3.3h on 2026-10-19. Telemetry must never be able
to cost a fleet its ability to rent.

Utilisation and temperature are the BUSIEST card, not the mean -- on a
multi-card pod the saturated card decides whether it can take more work, and
averaging it with an idle sibling hides exactly that condition. VRAM is summed,
being the pool a model is loaded into.

Bounded everywhere, because this is the page an operator opens when something
is already wrong: 2.5s per pod, all pods concurrently, a 4s TTL so several open
tabs collapse onto one round, and a 3s cap on the round -- a slow pod drops out
and the rest still render. The spend figures beside it stay right when the
telemetry does not arrive, and a pod that is booting or unreachable shows a
dash, never a zero: a zeroed bar reads as "idle" when the truth is "unknown".

held_pod_endpoints() is deliberately separate from pods_status(): that snapshot
is serialised into a browser and a pod's bearer must not be. Covered by a test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S8LAP3ueNzQJtwzhgVbq66