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.
A balance above zero is a precondition for two actions: deploying a new instance, and starting a stopped one. Both are refused at zero or below. 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, so a long-running instance produces a steady stream of small entries rather than one charge at the end.
The ledger
Every movement of money is a row in an append-only record. Nothing is edited or deleted; a correction is another row. 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 |
| Detail | The instance the charge belongs to, and the number of seconds billed |
| 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 — your data survives. If the balance keeps falling to −$5, 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 before it reaches −$5, because nobody gets the disk back afterward.