The failure this prevents was observable, not hypothetical: a pod boots, pulls
the image, starts downloading, fills its 40 GB disk and dies at load_timeout_s
having paid for every minute. The size of a HuggingFace repo is one metadata
call, so it is asked before the pod exists, and the disk is grown to fit —
weights plus ~25 GB for the unpacked image and the download cache.

It counts what a load will actually FETCH, not the whole repo. SDXL's repo is
77 GB, of which a diffusers load pulls 28: the rest is the same weights again
as Flax .msgpack, legacy .bin and ONNX exports. Sizing to the repo would have
rented 100 GB for a 28 GB model.

An explicit container_disk_gb that is already large enough is respected. And
with a network volume attached the weights land there, not on the container
disk, so the disk stays at its configured size — which is the point of the
volume.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY