Billing & usage

Prepaid credit, spent per token, reconciled to the nano-dollar. No subscription and no expiry.

How a request is priced

cost = (prompt_tokens - cached_tokens) × input_price   / 1,000,000
     + cached_tokens                × cached_price  / 1,000,000
     + completion_tokens            × output_price  / 1,000,000

Cached tokens are a subset of prompt tokens, and we bill them once, at the cached rate. Charging them at both rates is the most common way a metered API quietly overcharges, and it hits agent workloads hardest — they replay the same system prompt on every loop.

Where the token counts come from

From the inference engine’s own usage report, on every request. We do not run a separate tokeniser and estimate, because our estimate and the engine’s reality would drift and you’d have no way to tell which was right.

On the rare occasion an engine fails to report usage, we fall back to counting the response stream and flag that row as inexact. You can see the flag — a ≈ in your activity log — on any request it applies to.

What isn’t billed

Requests that fail before generating anything — 5xx, no capacity, timeouts.
Requests rejected for rate limiting or insufficient credit.
Requests to a model that doesn’t exist.
/v1/models, /v1/key and /v1/credits.

These still appear in your activity log at $0.00 — you should be able to see our failure rate, not just your successful requests.

Cancelled requests

Billed for the tokens actually produced. The GPU did that work, so it isn’t free — but you are not charged for the generation you cancelled. The row is logged as cancelled with the exact count, so a partial charge is explainable.

Running out

Requests are admitted while your balance is above a small negative floor (typically -$1.00). Beyond it, requests return:

{
  "error": {
    "message": "Insufficient credits. Your balance is $0.00. Top up at ...",
    "type": "insufficient_quota",
    "code": "insufficient_credits"
  }
}

The negative floor exists because a request’s cost isn’t known until it finishes. Rather than holding a lock for the length of a generation — which would serialise your traffic and turn a slow model into a queue — we admit while you’re above the floor and settle exactly afterwards. The exposure is bounded and the latency cost is zero.

Verifying a bill

Every request has an x-request-id and a corresponding row in your activity log with the token counts, timings and cost. Export it as CSV from the console and the rows sum exactly to the change in your balance — the balance is derived from those rows, so it cannot disagree with them.

We recompute every balance nightly from Σ(credits) − Σ(usage) and alert internally on any discrepancy.