Billing

The lifecycle of one request

1. Reserve. Before calling a model, the gateway prices the worst case: your prompt at the real tokenizer count, plus your max_tokens of output, at the published rate. That amount moves from available to reserved.
2. Run. If the balance will not cover the reservation, the request is refused with 402 and no model is called.
3. Settle. When the response completes, the actual token usage is priced and captured. The difference between the hold and the real cost returns to available.

The practical consequence is that your available balance dips by more than a request eventually costs, then recovers a moment later. That is the reservation being returned, not a double charge.

Failures and cancellations

A request that fails before producing tokens releases its entire hold. A stream you disconnect from is billed for what was generated up to that point, and the remainder is released. You are never charged for output you did not receive.

Where the estimate comes from

Input is counted with a real tokenizer, not a character heuristic, so the input side of the estimate is exact. Output cannot be known in advance, so the reservation assumes you will use your full max_tokens. Since that ceiling is enforced, the hold is a true upper bound rather than a guess.

Requests with a fallback chain reserve for the whole chain, because a refusal that triggers a retry means more than one model produced billable tokens.

Top-ups

Credit is added by crypto payment, with a $1 minimum. Credit lands when the payment confirms on-chain; the receipt records the invoice and the resulting balance.

Reading your usage

Requests in the dashboard lists every call with its model, token counts, latency, and what it cost, attributed to the key that made it. That is the same data the ledger settles from, so your own logs should reconcile against it exactly.