runpod: a region and a warm-pod schedule per model, spend over the API (v0.2.82)
Three gaps, all configurable from the model page:
- data_center pins a model's pods to one RunPod region. Precedence is
volume > model > account: a pod in another region cannot attach the
volume, so the volume still decides.
- schedule_enabled/start/end/days/tz gate the WARM FLOOR only. Outside
the window the floor is 0 and the warm pod is released without waiting
out idle_timeout_s; a request arriving out of hours still cold-starts
one, exactly as min_pods=0 always has. An end before the start runs
overnight and belongs to the day it started on. An incomplete or
unparseable window is treated as no schedule rather than a floor of
zero, and an unknown time zone falls back to local, not UTC.
- GET /v1/runpod/spend serves the pods, ledger, caps and schedule status
to an API key marked admin, so an external monitor can poll spend
without an admin session. Opt-in per token; an ordinary key gets 403.
pools_schedule_status() reports in_window/next_change/effective_min_pods
on /admin/api/runpod/stats and on the new endpoint.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
This diff is collapsed.
This diff is collapsed.
Please
register
or
sign in
to comment