LLM API pricing per million tokens: how to estimate what a feature will cost

The two prices on every model

Every chat model on the pricing page shows an input price and an output price, both expressed in US dollars per million tokens. Input covers everything you send: system prompt, conversation history, retrieved documents, tool definitions. Output covers everything the model writes back, including tool call arguments. The two rates differ because generation is sequential and occupies the GPU far longer per token than reading a prompt does. Across the catalog the median paid output price is 3.1× the median input price.

Prices are per million tokens for readability, but the maths works per token: a $0.50 per million input rate is $0.0000005 per token. A request with 2,000 input tokens at that rate costs one tenth of a cent before any output is counted.

What a token is, and why the count varies by model

A token is a chunk of text from the model's vocabulary: roughly four characters of English, or about three-quarters of a word. Code, non-Latin scripts and long numbers tokenize less efficiently, so the same text can be 20–40% more tokens on one model than another. Because providers meter against their own tokenizer, the only reliable count is the usage block in the response: prompt_tokens and completion_tokens. Log both for a week of real traffic before you estimate anything.

The cost-per-request formula

With real averages in hand the estimate is arithmetic:

cost_per_request = (avg_input_tokens × input_price_per_M
           + avg_output_tokens × output_price_per_M) / 1,000,000

monthly_cost = cost_per_request × requests_per_month

Worked example for a support-reply drafting feature: a 900-token system prompt plus 1,100 tokens of ticket context is 2,000 input tokens; the draft averages 350 output tokens. On a model priced at $0.40 in and $1.20 out, the request costs (2,000 × 0.40 + 350 × 1.20) ÷ 1,000,000 = $0.00122. At 200,000 drafts per month that is about $244. Switching the same feature to a $2.00 / $8.00 model lifts it to roughly $1,360 a month for the identical traffic, which is why model choice is the first lever.

Live prices: the cheapest paid chat models right now

The table below is generated from the live catalog each time this page is served, so the figures are the current rates rather than the ones on the day the article was written.

Every model id in the table can be called through the same OpenAI-compatible endpoint; FastInfra routes each request to the lowest-priced healthy upstream for that id, so the quoted price is the ceiling you pay, not an estimate.

Why the output ratio matters more than the rate card

Two features with the same request volume can differ tenfold in cost purely because of how much the model writes. Classification returns a single label (a handful of output tokens); summarisation returns a paragraph; code generation returns hundreds of tokens. When you compare models, weight the output price by your feature's output share. A model that is cheaper on input but pricier on output can lose for a generation-heavy workload and win for retrieval-augmented question answering where prompts are long and answers short.

Three controls bound the output side: a sensible max_tokens (a hard cap), explicit length instructions in the prompt ("answer in two sentences"), and stop sequences for structured outputs so the model does not continue past the field you need.

Hidden costs to include

• Retries. A 2% retry rate on timeouts or validation failures is a 2% cost increase; retries after partial streams can double the cost of that request.
• Conversation history. Each turn re-sends the full history as input. A ten-turn chat sends the first message ten times; summarise or truncate history after a few turns.
• Tool definitions. JSON schemas for twenty tools can add 2,000+ input tokens to every call. Send only the tools relevant to the step.
• Evaluation traffic. Nightly eval runs are real tokens; budget them separately so they do not hide inside the product figure.

How FastInfra pricing works in practice

Credits are prepaid; usage is deducted after each successful response and shown per API key in the console so you can attribute spend to a product surface. There is no monthly minimum and no platform fee on top of the per-token rate. Free-tier models (12 of the 785 ids today) bill nothing and are the right default for prototypes and for fallback when a paid model returns 402. For sustained high-volume inference on one model, compare the per-token total against renting a GPU Cloud pod billed per minute; the break-even depends on utilisation, which the next guides in this cluster cover.

A repeatable estimation checklist

Run this once per feature and again whenever the prompt or model changes:

1. Log prompt_tokens and completion_tokens from the usage block for at least a thousand real requests.
2. Take the mean and the 95th percentile of each; the mean drives the bill, the p95 drives your max_tokens ceiling.
3. Look up the candidate model ids in the model catalog and copy the input and output rates.
4. Compute cost per request for each candidate and multiply by monthly volume; add 3–5% for retries and evaluation traffic.
5. Run your evaluation set and divide monthly cost by the success rate to get cost per successful task; pick on that number.
6. Set a balance alert in the console and revisit when the rate limit tier or traffic profile changes.

The checklist takes an hour the first time and minutes afterwards. Teams that skip step one and estimate tokens by eye are routinely wrong by a factor of two or three, usually because they forget conversation history and tool schemas. More estimation and cost-control guides are collected in the LLM pricing guides cluster.