Tokens and billing

What gets charged

Text models are billed by tokens: the input (system prompt, history, the last message) at the input price, the answer at the output price. Both are rubles per 1M tokens and visible in the catalog and in GET /v1/models (pricing.prompt_rub, pricing.completion_rub). Charging happens on completion: you pay for exactly the tokens that actually went in and came out — the exact figures are always in the response’s usage.

The other modalities are billed not by tokens but by the natural unit of the result — an image, a second of video, a character of text, a minute of audio. The summary table is at the bottom of this page.

The rate depends on request length and time of day

The catalog price is the base rate, and for some models it does not describe every request. The upstream changes the rate in two ways.

A prompt-length threshold. Once the input crosses it, the higher rate applies to the whole request, not just to the tokens above the line:

Models	Threshold	Input	Output
GPT-5.6 (all) and GPT-6 Astra, Pro included	272,000 tokens	×2	×1.5
Grok 4.5, Grok 4.6	200,000 tokens	×2	×2
Qwen 3.7 Plus	256,000 tokens	×2	×2

A UTC schedule. Some hosts of open-weight models (DeepSeek, Alibaba) price by the hour: cheaper at night, dearer by day. That difference is twofold as well.

Charging always follows the facts, so the real cost of a request is in the response’s usage. The balance-based cap accounts for steps: the output ceiling is computed from the rate that will apply to your request, not from the base one. The steps in force for a given model are shown on its card in the catalog — as a note under the price, and per route in the providers table.

The usage structure

Quantity	/v1/chat/completions	/v1/messages	/v1/responses
Input	usage.prompt_tokens	usage.input_tokens + usage.cache_read_input_tokens	usage.input_tokens
Of which cached	usage.prompt_tokens_details.cached_tokens	usage.cache_read_input_tokens	usage.input_tokens_details.cached_tokens
Output	usage.completion_tokens	usage.output_tokens	usage.output_tokens
Total	usage.total_tokens	the sum of input and output	usage.total_tokens
Charged, $	usage.cost	usage.cost	usage.cost
Charged, ₽	usage.cost_rub	usage.cost_rub	usage.cost_rub
Source	usage.billing_source	usage.billing_source	usage.billing_source

The protocols differ: in the OpenAI formats (/v1/chat/completions, /v1/responses) the input field already includes the cache, while in the Anthropic format (/v1/messages) input_tokens is only the non-cached remainder, with the cache broken out into its own field. Add the fields once, per the protocol’s semantics — otherwise the cache gets counted twice.

An example (/v1/chat/completions; of 3,660 input tokens, 3,644 came from the cache):

{
  "prompt_tokens": 3660,
  "completion_tokens": 120,
  "total_tokens": 3780,
  "prompt_tokens_details": {"cached_tokens": 3644},
  "cost": 0.001834,
  "cost_rub": 0.1633,
  "billing_source": "balance"
}

When streaming, the same usage arrives as a final chunk if you pass stream_options: {"include_usage": true} — see Chat & streaming.

Request cost in the response

What a given request cost arrives right in usage — no separate trip to /v1/history:

• cost — the amount in USD (a number; many aggregator clients already read a field by this name, so nothing changes for them);
• cost_rub — the same amount in roubles, the balance currency, to 0.0001 ₽ (the ledger step);
• billing_source — balance (charged to the balance) or free_quota (the request went to the free quota; cost and cost_rub are then 0).

The fields are identical across /v1/chat/completions, /v1/responses and /v1/messages; in the Gemini format (/v1beta) they live in usageMetadata as cost, costRub, billingSource. The amount already reflects caching and price tiers — it is exactly what left the balance.

Reasoning tokens

A model’s reasoning is billed as output tokens — at the same completion price as the answer itself. Depth is controlled by reasoning_effort (see reasoning modes): more effort means more output tokens on the bill. There is no separate “how much of the output was reasoning” line in usage: the upstream does not report the split, so output_tokens_details.reasoning_tokens on /v1/responses is always 0.

Cache tokens

Tokens read from the context cache cost less than full input and arrive in usage as a separate field. How caching works and where it saves money — in Context caching.

The balance-based cap

If the balance cannot cover the full response you asked for, Mixen lowers the output-token ceiling to the length the balance can actually pay for and sends it to the model as max_tokens. The answer may cut off mid-way — visible in the response:

Protocol	Truncation marker
/v1/chat/completions	finish_reason: "length"
/v1/messages	stop_reason: "max_tokens"
/v1/responses	status: "incomplete" and incomplete_details.reason: "max_output_tokens"

The same marker arrives when your own max_tokens set the ceiling — the response alone cannot tell the two apart, so check the balance. This is protection against driving the balance negative, not a way to squeeze out an answer: the charge is always exactly what happened. If the balance cannot cover even a minimal answer, the request is rejected before it reaches the model — 402 insufficient_quota (Errors).

Where to watch spending

• The account at mixen.ai — balance and request history across all modalities. The balance is shared by the bot, the web account, and the API.
• GET /v1/balance — the same balance programmatically: {"balance_rub": "123.46", "currency": "RUB"} (Keys and authentication).
• GET /v1/history — balance movements programmatically: charges (negative), top-ups, bonuses and referral earnings (positive), newest first. Cursor pagination: pass the response’s next_cursor as cursor. amount_rub is a string with up to 4 decimals — the exact charged value.
• GET /v1/generations?type=image|video|music — history of generated artifacts (bot, cabinet and API together): model, prompt, charge. Bytes at GET /v1/generations/{type}/{id}/content.
• The usage field of the response — the cost of each request; in streaming, the final chunk with include_usage.
• 402 insufficient_quota — the balance is empty: top up and retry (Errors).

Who pays for what

Modality	Unit	Catalog example
Text and search	₽ per 1M tokens; input and output separately	GLM 5.3 Flash — 8.40 ₽ input / 27.90 ₽ output
Context cache	₽ per 1M tokens of cache read and write	Claude Sonnet 5 — 21.40 ₽ read / 267.40 ₽ write
Images	₽ per image	Nano Banana — 2.67 ₽
Video	₽ per second of video	Wan 3.0 — 6.68 ₽/s
Music	₽ per request	Suno — two tracks for one payment
Web search (web_search)	₽ per performed request	the model’s native search or Exa — Web search; on Sonar it is already included in the token price
Speech	TTS — ₽ per 1,000 characters of input; STT — ₽ per minute of audio	see the catalog
Embeddings	₽ per 1M input tokens, no output	see the catalog

Each model’s billing unit is spelled out in the catalog’s pricing.currency_note. Showcase prices move, so before invoicing your own customers take fresh values from GET /v1/models at request time rather than stored ones.