Credits and the ledger
Superheat is prepaid. You add credits to an organization's balance, and running instances draw that balance down. There is no invoice at the end of the month and no post-payment — if the balance is empty, nothing new starts.
The balance
One balance per organization, shared by everyone in it. Members can see it and spend against it; only admins can add to it. See Organizations.
Credits arrive one way: a Stripe checkout. Pick a $10, $25 or $100 pack, or enter a custom amount between $5 and $1,000. The credits land on the balance as soon as the payment confirms, which is usually seconds after you finish checkout.
Two actions need runway, not just a balance above zero: deploying a new instance, and starting a stopped one. Each is refused unless the balance covers one hour of the organization's whole burn with that instance running: its hourly GPU price and disk, plus the GPU and disk of every other instance that is running, starting or being created and the disk of every stopped one. Stopping and destroying are always allowed.
What draws it down
| Charge | When it accrues | Rate |
|---|---|---|
| GPU | While an instance is running | The offer's hourly price for the whole slice, metered per second |
| Disk | While an instance is stopped | The offer's storage rate, per GB per hour, on the disk you attached |
That is the entire list. Time spent creating, starting, stopping or destroying is free, an errored instance is free, and a destroyed instance costs nothing further.
The disk row is the one that catches people. A stopped instance is still holding a disk on a physical machine, and you pay for that reservation until you destroy the instance. Stop vs destroy is worth reading in full.
A settlement pass runs about once a minute. Each pass charges what accrued since the last one at the rate of the state the instance was actually in, and adds it to that instance's ledger row for the current hour, so a long-running instance produces one entry per hour rather than one charge at the end.
The ledger
Every movement of money is a row in an append-only record. Nothing is deleted, and a correction is another row. The rows that still change are the charges for the hour in progress, marked in progress: each minute's settlement is added to an instance's open row until the hour ends, the instance changes state, or a top-up or adjustment lands after it, and the balance shown on the charge rows after it moves with it. The full table is on the Billing page, under the balance and the spend chart.
| Column | What it holds |
|---|---|
| Date | When the entry was written, to the second |
| Type | Credits added, GPU usage, Storage, or Adjustment — or, for an adjustment with a reason, the reason, such as Refund or Support adjustment |
| Detail | The instance the charge belongs to, and how long the charge covers |
| Amount | Signed: top-ups positive, charges negative |
| Balance | The balance immediately after this entry |
The balance column is what makes the record auditable. Any figure you see anywhere in the console is the sum of these rows, so if a number looks wrong, the entry that made it wrong is in this table.
Charges carry the instance they came from, which is how the per-instance spend figure is calculated; the Detail cell links through to that instance. Top-ups carry no instance.
An instance's own Billing tab is a summary rather than a copy of the ledger: settled spend so far, the hourly burn rate while running, and the hourly burn rate while stopped, with a link back to the full table.
Reading it programmatically
curl -s "$SUPERHEAT_API/v1/billing/transactions?limit=50" \
-H "Authorization: Bearer $SUPERHEAT_KEY"
The endpoint pages with a cursor and accepts an instance_id filter to pull the charges for one instance. limit defaults to 50 and tops out at 200. GET /v1/billing/spend-daily returns charges alone, collapsed into daily totals, which is what the spend chart draws; its days window defaults to 30 and tops out at 90.
A balance can go negative
Settlement looks backward: it charges for time already used. Between two passes an instance keeps consuming, so the balance can pass zero before anything reacts to it.
That is why there are two thresholds rather than one. At $0, running instances are stopped and the GPUs of stopped instances are released where the machine supports it — your data survives. If the balance then stays at or below $0 for 24 hours and falls to −$5, stopped instances are destroyed, and the disks go with them.
If you are a member of someone else's organization, you cannot top up. Watch the balance and tell an admin as soon as it reaches $0 — well before it has been negative for 24 hours and reached −$5 — because nobody gets the disk back afterward.