Token Usage and Billing

ScitiX Model Inference uses pay-as-you-go billing based on actual usage and the price of the model you call. Prices vary by model. For the latest pricing, check the model detail page in Models.

​

Token Types

A request usually consists of input, cache read, cache write, output, and other billing dimensions. Common usage fields are defined as follows:

​

Billing Formula

For token-based model requests, the complete billing formula is: Cost = input tokens x input unit price + cache read tokens x cache read unit price + cache write tokens x cache write unit price + output tokens x output unit price

• In this formula, input tokens refer to input tokens that are not served from cache. Input, cache read, cache write, and output can have separate unit prices. Check the model detail page in Models for the exact prices.
• Image input is converted into input tokens and billed at the input unit price.
• Speech models are billed by audio duration. For ASR, usage is based on input audio duration. For TTS, usage is based on output audio duration. Check the model detail page in Models for the exact unit price.

Different model types use the billing dimensions as follows:

​

max_completion_tokens

max_completion_tokens limits the total generation budget, which means the sum of reasoning tokens and visible output tokens. It does not only limit the final visible answer. When you use a reasoning model, internal reasoning may consume part of the generation budget first. If max_completion_tokens is too small, you may see the following results:

• The visible answer is short, but output tokens are high.
• The reasoning process exhausts the generation budget, so content is empty.
• The answer is truncated and finish_reason is length.

You can mitigate these issues by increasing max_completion_tokens or adjusting thinking_budget. thinking_budget is a hint, not a strict limit. A model may use it to control reasoning length, partially apply it, or ignore it.

​

View Usage

You can view per-request token usage on the Usage Detail page. Usage Detail shows fields such as Input, Image Input, Cache Read, Cache Write, Reasoning, Output, and Total Tokens. Reasoning is already included in Output, so do not add Reasoning and Output together when analyzing cost. For details, see View Usage.

​

Which Requests Are Billed

Whether a request is billed depends on whether it reaches a model and begins inference.

​

Billable Requests

A request incurs model invocation charges after it reaches a model and inference begins. This includes:

• Requests that complete normally, such as those with status code 200.
• Requests where the client disconnects before the response completes, such as 499. If server-side inference has begun, model output is still included in usage and billing.

​

Requests That Do Not Incur Model Invocation Charges

Requests rejected before reaching a model are not billed, such as invalid parameters, authentication failures, insufficient balance, missing permission, model not found, or rate-limit errors. Platform-side failures are also not billed.

​

Billing by Common Status Code

For error response structures and handling guidance, see Error Handling.

​

Client Disconnection (499) Billing

​

Why 499 Requests Are Billed

499 / client_aborted means that the client disconnects before the response completes, for example because the request is cancelled, the network disconnects, or a client or proxy timeout expires. Once a request reaches a model, server-side inference begins immediately and continues until it finishes naturally, regardless of whether the client remains connected. All output generated by the model is included in usage and billing, including output generated after the client disconnects. This policy applies to both streaming and non-streaming requests.

​

Avoid Unexpected 499 Charges

• Set max_completion_tokens: Limit the total generation budget to avoid excessive output from a single request.
• Use stop sequences: Stop generation when the response reaches a known completion point.
• Set appropriate client timeouts: Complex tasks and long responses can take longer. A timeout that is too short can disconnect while the model is still generating.
• Use streaming for long responses: Set stream: true to receive generated content progressively and monitor request progress.
• Design retries carefully: If a request disconnects during generation and is retried immediately, both the original request and the retry can incur charges.

​

Cost Control Tips

• Control input length: Remove irrelevant history, long documents, and repeated context to avoid continuous input token growth.
• Control generation budget: Set max_completion_tokens reasonably to avoid unnecessarily long output.
• Control reasoning budget: For reasoning models, set thinking_budget based on reasoning depth, latency, and cost requirements.
• Choose the right model: Use free or lower-cost models during development, then choose the production model based on quality and cost.
• Reuse long context: For repeated long prefixes, fixed system prompts, or long multi-turn materials, see Prompt Caching.
• Keep prompt prefixes stable: Keep system messages, tool definitions, and few-shot examples consistent in order and content across requests to improve Prompt Caching hit opportunities.
• Reduce irrelevant context: For large knowledge bases, use Embedding to build RAG and pass only relevant chunks to the generation model.
• Separate API keys by application: Create separate API keys for different applications, and configure monthly budget, total budget, TPM, and RPM. For details, see API Keys.

​

FAQ