Billing and Rate Limits

This page explains the charging process of a request from send to settlement, and whether errors, cancellations, and rate limits are billed. See Model Pricing for unit prices and pricing methods for each model type.

When you are charged

Every request goes through two steps: reserve, then settle:

1. Reserve: before the request is forwarded upstream, an estimated cost is reserved from the key quota and the account balance. If either is insufficient, the request is rejected immediately and never sent upstream.
2. Settle: after the request completes, the actual cost is calculated from the real usage returned by upstream. Over-reserved amounts are refunded, and under-reserved amounts are charged additionally.

How the estimate is calculated:

Model type	Estimation method
Token-billed	Input token count plus max_tokens in the request, estimated at the model unit price
Tiered pricing models	Estimated at the highest tier price, then billed at the actual tier on settlement
Per request or per image	Reserve the per-unit price directly
Async tasks (video, music, etc.)	Reserve the estimated amount on submit, settle when the task completes

Tip

The larger max_tokens is, the higher the reserved amount. If your balance is tight and a request is rejected because the reservation failed, first lower max_tokens to the value you actually need.

Are errors billed

The principle: no billable usage, no charge; the reserved amount is refunded in full.

Scenario	Billed
Invalid or expired key, or insufficient balance or key quota	Not billed; the request is not sent upstream
Invalid request parameters, model unavailable, no available channel	Not billed
Rate limited (429)	Not billed
Upstream returned an error (4xx / 5xx)	Not billed; the reserved amount is refunded in full
Upstream returned success but with zero usage	Not billed
Upstream interrupted or timed out mid-stream	Billed for the content already generated
Async task failed or timed out (not completed within 24 hours)	Not billed; the reserved amount is refunded in full

Retries and fallbacks

RouteAPI automatically retries or switches to another channel when upstream fails. The whole process reserves once and settles once; failed attempts are not billed, and you only pay for the attempt that finally succeeded. If a fallback model ultimately completes the request, billing uses the price of the model that actually served it.

Once a streaming request has started outputting to you, it is no longer retried. If upstream breaks off at that point, you are billed for the generated part.

Is manual cancellation billed

Scenario	Billed
Non-streaming request, connection closed before the response is received	Not billed; the reserved amount is refunded in full
Streaming request, connection closed midway	Billed; see below
Async tasks (video, music, Midjourney)	Cancellation is not supported after submission

When a streaming request is closed midway, upstream is usually already generating and continues to completion. RouteAPI keeps reading upstream output until generation ends and bills for the usage upstream actually generated, not just the part you have received. To control this cost, use max_tokens to limit output length.

Rate limits

To protect the stability of the platform and upstream providers, the platform may limit the model request rate per account. Limits are counted per account; all API keys under the same account share the quota.

When rate limited, the response is 429 Too Many Requests, with the same error body format as other errors:

{
  "error": {
    "message": "... (request id: ...)",
    "type": "error",
    "code": ""
  }
}

• Rate-limited requests are rejected before reservation and are not billed.
• When upstream returns 429, RouteAPI automatically switches to another channel to retry. Only if the retry is still rate limited is 429 returned to you.
• The response does not include a Retry-After header. Clients are advised to retry with exponential backoff, for example 1 s, 2 s, 4 s, plus random jitter.
• Splitting into multiple API keys does not increase the rate limit. Contact us if you need a higher request rate.

The Platform API (/api/open/v1) has separate rate limit rules; see Platform API errors and limits.

Verifying charges

In the usage log you can view the details of each billed request:

Field	Description
Time	Request time
Key	Name of the API key that made the request
Model	The model actually billed
Latency / first token	Total time taken; streaming requests also show first-token latency
Input	Input tokens; when the cache is hit, cache reads and writes are shown separately
Output	Output tokens
Cost	The actual amount charged for this request
Details	Unit price, rate multiplier, and the billing process

The usage field in the API response also returns this request’s token usage:

Field	Description
prompt_tokens	Input tokens
completion_tokens	Output tokens; reasoning tokens of reasoning models are also counted here
total_tokens	Input plus output
prompt_tokens_details.cached_tokens	Input tokens that hit the cache

If your account has an exclusive discount, the cost in the log is already the discounted amount.