The autoscaler reacts to load — a pod is added once the least-loaded one
already has scale_up_inflight_per_pod requests in flight. That is right for
traffic nobody predicted and wrong for a client that KNOWS what is coming: a
batch of a thousand documents otherwise discovers the pool one cold start at a
time.

So a client may now say so: POST /v1/runpod/scale {model, pods}. It is a lease,
bounded three ways, because a client that can raise the floor can raise the
bill:

  * allow_client_scale, off by default, so no model is client-scalable unless
    someone said so;
  * clamped to max_pods — asking for more returns the ceiling with
    "clamped": true rather than an error, since the client asked for "as many
    as you can" and refusing would leave it with none;
  * client_scale_ttl_s (default 30 min), because the failure that matters is
    not a wrong number, it is a client that asks for four A40s and then dies.
    A lease that never expired would be a bill that never stopped, so a 0 in
    the config falls back to the default instead of meaning "forever".

The lease and a warm-pod schedule are MAXED, never summed: both mean "hold this
many ready", so a client cannot lower a configured floor and a closed window
cannot cancel a lease. /v1/runpod/status reports the live lease per model, so an
unexpected bill has a visible cause.

Not admin-scoped, unlike /v1/runpod/spend: the gate is the per-model flag, not
the key, and the account's $/hr and spend caps still refuse to provision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>