The Runtime Minute

Everything in the Workbench is displayed in Runtime Minutes (RM). This page defines the unit exactly, because a unit that is not defined exactly is a marketing device, and this one is a measuring device.

The definition#

1 RM = 20,000 input tokens + 4,000 output tokens
       on the Sonnet-class reference model,
       at that model's current published list price.

That is the whole definition. It is published here and on the reserve page, and the conversion is a pure function anyone can recompute:

cost per RM  = 20,000 / 1,000,000 * (input price per MTok)
             +  4,000 / 1,000,000 * (output price per MTok)

RM balance   = credit balance in USD / cost per RM

Worked against list prices as of September 2026 (check the provider's public price page; these change): the Sonnet-class reference model lists at $2 per million input tokens and $10 per million output tokens, so

cost per RM = 0.02 * 2 + 0.004 * 10 = $0.08

A credit balance of $8.00 therefore displays as 100 RM.

The three-layer rule#

An RM figure never appears alone. Every balance and every price in the product carries three layers, in this order:

1. RM, the primary figure.
2. The model range: what that balance means on cheaper models. The same credits run longer on a Haiku-class model or Gemini Flash than on the Sonnet-class reference, because their list prices are lower. A time figure without a named model is meaningless, so we never show one.
3. The dollar basis, smallest and explicitly labelled as the basis of the calculation. The dollar figure is a utility metric: it says what the credits are worth in machine work at list prices. It is not a share value, not a market price, and not a claim on the reserve.

This ordering is enforced in the product's components, not left to editorial discipline. A screen that shows an RM number without its range and basis does not build.

Why a reference basket and not a promise#

The alternative to a defined basket would be a promise: "1 RM will always buy you X." We do not make that promise, for a reason worth being explicit about.

Model prices are set by model providers, not by us. Providers change prices, retire models, and ship new ones. A fixed promise would either break the first time a provider moves, or force us to quietly redefine it, which is worse. A published reference basket does the opposite: when the underlying list price changes, the RM conversion changes visibly, with the formula and the date in view. The unit stays honest because it is recomputed in the open, not defended in private.

The same honesty applies over time in the other direction. The cost of a constant capability level in inference has been falling steeply for years. We do not promise that trend continues. We show the current conversion and its date, and anyone can compare it to last month's.

Why time units instead of dollars#

Three reasons, in descending order of importance:

1. A dollar figure on this token invites a misreading. A per-token dollar figure next to a tradable token reads like a share value or a guaranteed price. It is neither. Work units say what the system actually owes: machine time, in a defined amount, on a named model class.
2. Nobody intuits "$1,565 per 10 million tokens". People do intuit "this job took 0:47 of runtime" and "your balance is about 38 minutes of Haiku-class work". The unit is the product's own name; the display should speak it.
3. Dollars are the input, not the deliverable. The reserve holds stablecoins as raw material. What it is redeemable for is work. Denominating the display in work keeps the description aligned with the obligation.

What an RM is not#

• Not a currency. RM balances are a display of credit balances, nothing more. Credits are non-transferable and cannot be cashed out.
• Not a fixed quantity of compute. The basket is fixed; its cost floats with published list prices.
• Not a price statement about the token. The conversion runs from credits to work, never from token market price to anything.