Pricing & billing
How inference is billed — a prepaid balance, per-token metering with distinct input, cached-input, and output rates, and per-request usage.
Inference is prepaid and metered per token. You fund your organization's balance, and each request draws down from it based on the tokens it used.
Prepaid balance
Your organization holds a balance that pays for usage. Top it up in the
dashboard. When the available balance falls below
the spending floor, new inference requests are refused with
402 Payment Required until you add funds:
{
"error": {
"message": "insufficient balance; add funds to continue",
"type": "insufficient_quota",
"code": "insufficient_balance"
}
}Discovery is free — GET /v1/models is not balance-gated. Only billable
requests like POST /v1/chat/completions require a funded balance.
Per-token metering
Usage is metered across token dimensions, each with its own rate:
| Dimension | What it counts |
|---|---|
| Input | Fresh prompt tokens sent to the model. |
| Cached input | Prompt tokens served from a prompt cache (billed at a reduced rate). |
| Cache write | Messages-only: tokens written into the prompt cache (cache_creation_input_tokens). Not reported on Chat Completions. |
| Output | Tokens the model generates, including any reasoning tokens. |
Rates are per token and vary by model. Cached-input tokens are billed at a lower rate than fresh input tokens. The total cost of a request is the sum of each dimension's token count multiplied by that dimension's rate.
Current rates
Per-model, per-dimension rates are published in the dashboard and on the pricing page. Always treat those as the source of truth for current prices.
Usage on every response
Every completion reports the token counts it was billed on in its usage
object, so you can reconcile spend yourself. This section covers the Chat
Completions usage shape; Messages uses
Anthropic's field names and a different cache-accounting rule, covered on
that page.
{
"usage": {
"prompt_tokens": 1024,
"completion_tokens": 256,
"total_tokens": 1280,
"prompt_tokens_details": { "cached_tokens": 768 }
}
}These fields map onto the billing dimensions as follows:
usage field | Billing dimension |
|---|---|
prompt_tokens − prompt_tokens_details.cached_tokens | Input (fresh) |
prompt_tokens_details.cached_tokens | Cached input |
completion_tokens | Output |
For streaming requests, the same usage object is
delivered on the final chunk — usage is always reported, so streaming requests
are billed exactly like unary ones.
Batch requests
Requests run through the Batch API are metered per
token exactly like online requests, but at a lower rate (roughly half the
online rate) in exchange for asynchronous, within-24-hour completion. A batch's
rolled-up token counts and cost are exposed on its usage object, and each
result line carries its own per-request usage.
What is and isn't charged
- Failed requests are not charged. A non-2xx result, or a streamed response that is interrupted before it completes, is not billed.
- Account holds. If your account is suspended for balance or is under
review, billable requests are refused with
403. See Errors.