How to Estimate LLM API Cost (With Formulas)

Every LLM API publishes a price per million tokens, yet teams are still surprised by their first invoice. The rate is rarely the problem. The surprise comes from token counts that were guessed instead of measured, and from tokens nobody remembered to count.

This guide gives you a repeatable way to estimate cost before you ship. The rates in the examples are illustrative — always plug in the current numbers from the pricing page.

The formula

Providers price input (prompt) tokens and output (completion) tokens separately, per million tokens:

cost per request = input_tokens  × input_rate  / 1,000,000
                 + output_tokens × output_rate / 1,000,000

Output usually costs several times more than input, so a request with a short prompt and a long answer can cost more than one with a long prompt and a short answer. Estimate both sides separately.

Step 1: measure tokens, do not guess them

A rough rule for English text is about four characters per token, as OpenAI's tokenizer guide explains — but other languages, code and structured data tokenize differently. The reliable approach is to run a sample of real requests and read the usage object every response returns. Record the input and output token counts for at least a few dozen representative requests, then use their averages (and the 90th percentile for worst-case planning).

Step 2: count the hidden tokens

The tokens you see in your user's message are only part of the bill. Make sure your sample includes:

• System prompts and instructions, sent with every request.
• Tool and function definitions, which are serialized into the prompt.
• Conversation history: chat apps usually resend earlier turns, so input grows with every turn.
• Retrieved context in RAG pipelines — often the largest part of the prompt.
• Reasoning tokens: reasoning models produce internal tokens that are typically billed as output even though you do not see them.
• Retries: a failed attempt that already consumed tokens may still be billed, so add your observed retry rate.

Step 3: turn one request into a monthly number

Take an illustrative workload: a support assistant handling 2,000 requests a day, averaging 1,500 input tokens and 400 output tokens per request, on a model priced at $0.25 per 1M input and $1.25 per 1M output tokens.

input  per request: 1,500 × $0.25 / 1,000,000 = $0.000375
output per request:   400 × $1.25 / 1,000,000 = $0.000500
cost per request:                              = $0.000875
per day   (× 2,000):                           = $1.75
per month (× 30):                              = $52.50

At an official list price of $5 input and $25 output per 1M tokens, the same workload costs $0.0175 per request, or $1,050 a month. That gap — not the model choice — is usually the largest lever on an LLM budget.

Step 4: compare pay-as-you-go with a token plan

A prepaid token plan sells a fixed allowance of tokens for one model. On zcloud, input and output tokens draw the allowance down equally, so the right comparison is a blended rate: your workload's PAYG cost divided by its total tokens.

blended PAYG rate = $0.000875 / (1,500 + 400) tokens × 1,000,000 ≈ $0.46 per 1M tokens
plan rate         = $2 / 16,000,000 tokens × 1,000,000            = $0.125 per 1M tokens

With these illustrative numbers the plan is cheaper per token, and because output tokens are the expensive side of PAYG, plans favor output-heavy workloads the most. The monthly workload above uses 2,000 × 30 × 1,900 = 114,000,000 tokens, which at $0.125 per 1M is about $14.25 of plan allowance. Run the same calculation with the real rates of the model you use; the pricing page shows a worked PAYG-vs-plan example computed from the live catalog.

Step 5: add a margin and set a cap

Treat the estimate as a baseline, not a promise. Add headroom for traffic growth and prompt changes, then make spend observable:

• Track the usage each response reports, per feature and per customer.
• Alert when daily spend exceeds your estimate by a set percentage.
• Use prepaid balances or plans as a hard ceiling. On zcloud, when neither a plan nor PAYG balance covers a request, the API returns 402 insufficient_balance instead of running up a bill.

Quick checklist

• Rates come from the current price list, not from memory.
• Token counts come from measured usage, not character estimates.
• System prompts, tools, history, retrieved context and reasoning tokens are included.
• The monthly estimate uses averages; the worst case uses the 90th percentile.
• PAYG is compared with a plan using a blended rate.
• Spend alerts and a prepaid ceiling are in place.

Ready to try your own numbers? Compare per-model rates on the pricing page, and if you are moving existing code, follow the OpenAI-compatible migration checklist.

FAQ

Why is output more expensive than input? Generating tokens one at a time is more compute-intensive than reading a prompt, and providers price output accordingly. That is why answer length matters so much for cost.

Do cached prompts cost less? Often, yes. Many models bill repeated prompt prefixes at a reduced rate. See prompt caching for how cached tokens are reported.

Is a token plan always cheaper? No. It is cheaper when one model carries most of your traffic and you use the allowance. For mixed or irregular usage across many models, a PAYG balance is simpler. Compare blended rates with your own workload.