Where to find rates
Rates are set per GPU type and change over time, so they live in the CLI rather than in these docs:$/GPU-hour. A GPU type with no active rate isn’t sold on-demand and won’t appear.
When you dispatch, the CLI echoes the GPU type it resolved and the rate it will bill at, so the cost is visible before the run starts rather than first appearing on an invoice:
The rate is snapshotted onto your run at dispatch. If rates change while your run is in flight, your run keeps the rate it started with.
What gets billed
Queueing, scheduling, and image pull are not billed. A cold node pulling a multi-gigabyte prime-rl image can take many minutes — that time is on us.
Dispatch requirements
A run is admitted against your wallet, so before dispatch you need:- On-demand enabled on your account or team. On-demand training is in beta, so request access if it is not enabled yet
- Spendable balance — your balance plus any overdraft allowance and training credit grants
- A run within your per-run GPU cap
Capacity and queueing
If the on-demand pool has no headroom, your run queues rather than being rejected, and is promoted automatically as capacity frees. Your wallet is re-checked at promotion.prime train models shows a Capacity column per GPU type, either available or busy. That is a coarse hint about pool headroom, not an admission decision: whether your run starts immediately or queues also depends on how many GPUs you ask for and their topology, which the discovery endpoint does not know.
If you already hold reserved capacity for a matching GPU type, your run is placed there instead of on-demand — that hardware is already paid for.
Models
Which models and GPU types you can dispatch on.
Full Fine-Tuning
Config schema, dispatch knobs, and run lifecycle.