Scaleway, Exoscale, OVHcloud and Hyperstack all rent GPUs by the hour or the
second, and nothing about the fleet logic is really RunPod-shaped. Written
down now so the seam does not have to be re-derived later; none of it is
built.

The point worth keeping: the provider-specific part is small. Demand-based
growth, the reaper, budgets, the ledger, spillover, shared pools, LoRA
fan-out and region selection all sit above the provider and ask it for about
eight things, which RunpodClient already is -- ping, a catalogue with VRAM
and price, create, get/list, wait_ready, stop/terminate, logs, volumes. A
second provider is a second client plus a per-pool choice, not a second
orchestrator.

The section also lists what will NOT port, because the §10 notes were all
found live and most are categories rather than one provider's quirk: an
undocumented image size ceiling, a boot budget that has to cover the image
pull, how the port is reached (proxy vs direct TCP vs a load balancer with
its own idle timeout), rate limits in their own units, terminal states that
do not look terminal, and region-scoped storage.

Indexed from docs/README.md so it is findable without reading to the end of
an 890-line file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC