Skip to content
OpenRelay is in early access, and the /v1 API is stable. New capabilities ship in the changelog.
Inference API

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:

DimensionWhat it counts
InputFresh prompt tokens sent to the model.
Cached inputPrompt tokens served from a prompt cache (billed at a reduced rate).
Cache writeMessages-only: tokens written into the prompt cache (cache_creation_input_tokens). Not reported on Chat Completions.
OutputTokens 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 fieldBilling dimension
prompt_tokensprompt_tokens_details.cached_tokensInput (fresh)
prompt_tokens_details.cached_tokensCached input
completion_tokensOutput

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.

On this page