Task billing & refunds
How tasks are charged — prepaid credit deducted while the container runs, trued up to the exact end time — and exactly who pays when a task fails.
Tasks are billed for container runtime — plus, if the task uses input assets, the time spent downloading them. This page covers when the meter starts and stops, which credit is used, and what happens to the money for every way a task can end.
How billing works
Section titled “How billing works”- The meter starts when the container is Running. Queueing, scheduling, and image pulls before that are free.
- Tasks with input assets also bill the download window. While inputs are fetched before your script starts (shown as Fetching on the task page), time is billed at the task’s normal rate — the hardware is reserved and the volume is filling during that window. The billed window is capped (~6 hours).
- After the run, compute stops but storage continues. While outputs are being saved to Assets, the task’s
/outputsvolume keeps billing as storage until the transfer completes (see Asset storage billing). Compute is never billed after your script ends. - While the task runs, your prepaid credit is deducted on a ~60-second cycle, and the task card shows Cost so far live.
- When the container ends, the charge is trued-up to the actual end time — you are never billed for time after your script exited, even if it exited between billing cycles.
- The hourly rate is the same as a GPU Pod on the same hardware — see Pricing & Instances. CPU presets have their own listed rates, shown on the submit form.
pip install -r requirements.txttime runs on the clock — it happens inside the running container.
Who pays when something goes wrong
Section titled “Who pays when something goes wrong”Every finished task is classified as succeeded, a user fault, or a platform fault (the fault_class field in webhooks and on the task page). That classification decides the money:
| Outcome | Fault | Billing |
|---|---|---|
| Script exits 0 | — | Charged for actual runtime |
| Script raises / exits non-zero | User | Charged in full |
| Out of memory (exit code 137) | User | Charged in full |
Disk budget exceeded (system storage or /outputs) → evicted | User | Charged in full |
requirements.txt install fails | User | Charged in full |
| Max run time reached (Timed out) | User | Charged up to the ceiling — no refund |
| You press Stop | — | Charged for actual runtime |
| Input download fails — the source rejected it (invalid or missing token, a gated repo you lack access to, a deleted upstream) | User | Charged for the download window |
| Input download fails — platform fault | Platform | Full refund — your code never ran |
| Node goes down mid-run | Platform | Automatic refund: min(1 hour’s worth, total charged) |
| Scheduling / image preparation fails | Platform | Same automatic refund |
Platform-fault refunds are automatic — no ticket needed. If the fault happened before your script ever started running, the refund is the full charge; once the run has started, the refund is capped at one hour’s worth of the task’s rate (or the full charge, if the task ran less than an hour). It appears in your billing history alongside the charge.
Timeouts
Section titled “Timeouts”Timed out is treated exactly like Failed for billing: charged up to the max run time, no refund.
When the ceiling is hit, the script receives SIGTERM, then 30 seconds of grace before the container is killed. Use it to flush final results:
import signal, sys
def save_and_exit(signum, frame): checkpoint.save("/outputs/checkpoint.pt") # you have ~30s sys.exit(0)
signal.signal(signal.SIGTERM, save_and_exit)Files already written to /outputs are uploaded even for failed and timed-out tasks — a timeout loses the remaining work, not the finished output.
Running out of credit
Section titled “Running out of credit”Billing is prepaid: if your paid credit is exhausted mid-run, the task is stopped. Keep enough balance to cover rate × max run time for anything you can’t afford to lose — or checkpoint to /outputs so a stop is recoverable.