Skip to content

Tokens and cost

User

Tokens are the unit of account. Running a job spends them; an administrator or a purchase adds them.

The Tokens page: current balance, total credits, total spent, and a transaction history table.

Current balance is what you can spend now. The submission form compares its estimate against this before you commit.

Total credits, Total spent and Transactions summarise the selected date range, not all time.

Charge When
Job start cost A small fixed amount each time a job starts
Runtime Per minute, scaled by GPU, CPU and memory held, and by the queue’s cost settings
Storage Per terabyte-hour, continuously, regardless of any job

The important word is held. A job that reserves a GPU and leaves it idle costs exactly as much as one that saturates it. The Metrics view is how you find out which you have.

Every credit and debit in the selected range, with a date filter capped at 90 days.

Type Meaning
Usage A charge, with the job it belongs to: Cost for job <name> ID:78
Credit Tokens added, for example Added by Tenant Administrator

Because each usage row names the job id, this page is where you answer “what did that experiment actually cost”.

If a job is charged to a project, the project’s balance pays and the charge appears against the project rather than you. The submission summary shows the project’s balance instead of yours as soon as one is selected.

Some tenants require every job to name a project. That is a tenant setting, not something you can change.

There is no overdraft. If your balance will not cover the estimate, the job is not submitted.

Topping up is one of:

  • Ask your tenant administrator to add tokens. Normal in most tenants.
  • Buy them, if your tenant allows it - a control next to the balance in the submission form opens the purchase dialog.
  • Use a project whose budget still has room.