Token pricing

A token is the billing unit: words, word pieces, punctuation, and service markers. The rate is always quoted per million tokens and always split between input and output. The beginner's mistake is multiplying the whole request by one rate: input and output are billed separately and often differ severalfold.

Request cost =
  (input_tokens  / 1 000 000 × input price) +
  (output_tokens / 1 000 000 × output price)

# Example: 2,000 input tokens at $0.50 per 1M
#          + 500 output tokens at $1.00 per 1M
#   2000 / 1_000_000 × 0.50  =  $0.001
#    500 / 1_000_000 × 1.00  =  $0.0005
#   Total before rounding: $0.0015

An upfront estimate counts the maximum; the actual charge counts the tokens really processed. So reconcile every request against usage, not your own estimate. Each model's current rates are on the models and pricing page; the examples below use catalog rates and may change. Russian version of this guide: Стоимость токенов.

The main reason behind “it cost pennies yesterday, a fortune today” is dialog history. Apps usually resend the whole conversation with every new message, so the tenth request carries nine times the input of the first for the same user question. System instructions and RAG inserts add on top.

# Why the 10th request costs more than the 1st for the same question:
#   request 1:  system prompt (500) + question (100)                         = 600 input
#   request 10: system prompt (500) + history (9 × 400) + question (100)    = 4,200 input
# Takeaway: budget by the median and 95th percentile of full input,
# not by the size of one user message.

Remedies: history summarization, a sliding window of recent messages, moving stable context into cacheable blocks. Measure the median and upper percentile of full input on real dialogs, not on a single test question.

Caching lowers the price of repeated input but only counts with confirmed cached usage: the catalog shows separate rates for exactly that case. Image models use a different unit — a fixed price per generation — and the UI must separate it from the per-million-token rate to avoid misleading users.

For a complex workflow, count separately: the number of text requests with their input/output, the number of image generations, and possible retries after errors. Mixing these units into one figure is the most common cause of estimate-vs-invoice gaps.

Cap max_tokens on every call: the model must never be able to generate a novel on your budget. Shrink repeated context, reuse system instructions through cache, pick a smaller model for classification and drafts and a flagship only for hard steps. Enable the expensive fallback (a retry on a senior model) only after cheap attempts.

Track the cost of the full user operation, not a single request: a five-call chain with retries is five charges. Build the spend dashboard from the dashboard history data, and work through the error codes behind retries using the errors guide.