Pricing & billing

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 balanceCopy Anchor Link

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"
  }
}

Per-token meteringCopy Anchor Link

Usage is metered across token dimensions, each with its own rate:

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.

Inference tiersCopy Anchor Link

The same model is sold at three rates, depending on how fast you need the answer. Each tier is a multiplier on the model's Sync rate:

Worked example for openrelay/gemma-4-31b, which the Batch API runs, per 1M tokens:

Batch runs only on batch-eligible models; the others have Sync and Async rates only.

AsyncCopy Anchor Link

Async is for work that does not need an answer on the open connection. You submit a request, it waits in a queue for capacity, and the result is delivered later rather than returned on the request. Async is billed at 80% of the Sync rate on input, cached input, and output.

Async is coming soon and is available as early access only. There is no public Async API yet. To request access, email sales@openrelay.inc. If you need discounted asynchronous work today, use the Batch API.

DeepSeek V4.1-Flash-1017Copy Anchor Link

The Sync rates for openrelay/deepseek-v4.1-flash-1017-heretic are:

Cached-input pricing applies to prompt tokens the engine reports as cache hits in usage.prompt_tokens_details.cached_tokens. Other prompt tokens use the fresh-input rate. Reasoning tokens use the output rate.

Input-only modelsCopy Anchor Link

Embeddings and Decisions generate no tokens, so their models have an input rate and no output line. Their usage carries prompt_tokens and total_tokens only, with no completion_tokens, and you are billed on prompt_tokens.

Usage on every responseCopy Anchor Link

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:

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.

Cost on every responseCopy Anchor Link

Every Sync response also says what the request costs, in an openrelay object beside its usage:

{
  "usage": {
    "prompt_tokens": 1024,
    "completion_tokens": 256,
    "total_tokens": 1280,
    "prompt_tokens_details": { "cached_tokens": 768 }
  },
  "openrelay": { "cost_nano_usd": 203520, "priced_at": "online" }
}

The example is 256 fresh input tokens, 768 cached and 256 output on a model priced at $0.15, $0.015 and $0.60 per 1M tokens, so it costs 256 × 150 + 768 × 15 + 256 × 600, which is 203,520 nanoUSD (about $0.0002).

• Unary responses also send the figure as an OpenRelay-Cost-Nano-USD header, for a client that reads headers only.
• Streams carry the object on each chunk that carries usage, with the cost of the usage reported so far: for a stream read to its end, the last one is the bill. Streams send no header, because headers go out before any usage exists. Read the cost from the last chunk or event that carries it, not from a message an SDK assembles: the OpenAI Python SDK's chat.completions.stream() helper keeps whatever the first chunk carried, and the message the Anthropic Python SDK assembles carries none. See Streaming and Messages.
• Batch results do not carry it. Batch work is priced when the batch finalizes, at the batch rate for its priority; the batch's usage object has its cost.

The figure is the bill for a completed response. A stream that is cut off, or ends with an error, after a chunk with a cost was sent is not billed, so the figure it sent never became a charge.

Batch requestsCopy Anchor Link

Requests run through the Batch API are metered per token exactly like Sync requests, in exchange for asynchronous, within-24-hour completion. The price depends on the batch's priority:

• standard (the default) bills 50% of the Sync rate. The halving is applied to each dimension's line (tokens times the Sync rate), so a line can round down by at most half a nanoUSD.
• expedited bills the Sync rate. The batch discount does not apply.

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 chargedCopy Anchor Link

• 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 paused because its available balance dropped below $0.50, or is under review, billable requests are refused with 403. See Errors.