A month's spend, per node and per batch job (?month=YYYY-MM)

Your spend for a month (default: the current one), in USD, itemized: per-node rows, a jobs block for batch work, and builds, snapshot_storage, wal_storage (continuous volume replication, where it runs), and sandboxes rollup lines - each present only when that stream had something to say, and the total is the sum of them: what has BILLED, the /usage page's "Charged" figure. The sandboxes block splits its charge per tier (RAM, parked disk, resident and cold snapshots) and per UTC day in days, with the GiB-minutes held - the rows the /usage page's Sandboxes table and /usage.csv carry; void_gib_minutes is RAM-time voided on our side, never billed. Nodes bill while running or idle in their grace window; stopped nodes cost nothing. A node running RIGHT NOW has accrued minutes the fold has not journaled yet, so on the current month in_progress_usd carries that estimate and spend_so_far_usd is the two added up - which is the number get_billing quotes (your_mtd_usd, "includes in-progress") and the number spend caps enforce on. Both figures are absent whenever nothing is running, which includes every closed month. The jobs block carries the month's GPU-minutes and charge, batches (one line per submit_jobs sweep label, unlabeled jobs under a null label, the 20 priciest labels then one batch_usage_remainder line for the rest), and top_jobs (the 10 priciest, the drill-down; list_jobs enumerates the rest) - jobs bill per GPU-minute at the job rate, so their unit is gpu_minutes where a node's is wall minutes, and the counts are of what billed (an attempt we cut short costs nothing and appears nowhere). Builds meter past a monthly free allowance, so builds shows billed and free minutes. Pair with list_nodes to spot nodes you're paying for but not using.