LLM API Pricing Explained: How to Estimate Your Bill

LLM API pricing looks simple on a price list, two numbers per model, and becomes hard to predict once real traffic arrives. The bill depends on how many tokens go in, how many come out, how much of the input repeats, and how much hidden reasoning the model does before it answers. This guide explains each part, shows where the numbers come from with measurements we took on 16 October 2026, and works through a monthly estimate you can repeat with your own figures.

How LLM API pricing works

Almost every text model is priced per million tokens, with separate prices for input and output. Input is everything you send: the system prompt, the conversation so far, tool definitions, retrieved documents and the new message. Output is everything the model generates.

Three things about tokens matter more than the exact definition:

• Tokens are not words. Each lab uses its own tokenizer, so the same text can be a different number of tokens on different models. Code, non-English text and long numbers often take more tokens than plain English prose.
• Your request is bigger than your message. On Kimi K3, the three-word message "Reply with OK" was counted as 88 input tokens. Templates and formatting count too. Read the usage field in each response instead of estimating from the text you typed.
• Output usually costs several times more than input. On the BoostRail catalog, Claude Sonnet 5's output price is five times its input price, and DeepSeek V4.1 Flash's is four times. Workloads that generate a lot of text feel this most.

The four token types on a bill

A modern LLM bill has up to four lines, even when the price list shows two numbers.

Reasoning tokens are easy to miss. When we asked Kimi K3 to "Reply with OK", the visible answer was two characters and the response reported 98 output tokens, because the model reasoned before answering. With a budget of 16 tokens, the same request returned no text at all. Reasoning models need room in max_tokens, and that room is billed as output.

Cache writes are priced differently by each provider. Anthropic's own API, for example, charges more than the input price to write to its cache and a tenth of it to read, according to its prompt caching documentation. On BoostRail, cache writes carry no surcharge: the first pass bills at the normal input price, and later cache reads bill at the cache-read price published for each model, where the model's route supports caching.

Why agents cost more than chat

A chat turn sends one message and gets one answer. An agent turn sends the whole working context again: instructions, tool definitions, files it has read, command output and every earlier step. In Claude Code 2.1.295, a one-word reply still sent 20,751 input tokens. A long session repeats a prefix like that dozens of times per task.

Two consequences follow:

1. Input dominates. For coding agents, input tokens are usually many times the output tokens, so the input price and the cache-read price decide most of the bill.
2. Cache share decides the rest. If most of each request is a repeated prefix that hits the cache, the effective input price drops close to the cache-read price. If the prefix changes every turn, nothing is cached and every token bills at the full input price.

The cost calculator has three usage profiles built on this, and explains why the cache share matters more than the headline price. For the coding-specific side, see Claude Code with Other Models.

Worked example: estimating a monthly bill

Take the calculator's middle profile, roughly one developer using a coding agent every day: 30M input tokens and 6M output tokens a month, with 70% of the input served from cache. That splits the input into 21M cached tokens and 9M uncached tokens.

Prices from the BoostRail catalog on 16 October 2026, in USD per 1M tokens:

The formula is the same for every model: uncached input × input price, plus cached input × cache-read price, plus output × output price, each divided by one million.

So the same month of work costs about $5.33 on DeepSeek V4.1 Flash and about $78.09 on Claude Sonnet 5. Without caching, the Sonnet month would be $114.00, because all 30M input tokens would bill at the full input price. The gap between models is large, and so is the gap between a cache-friendly setup and one that is not.

Two cautions keep the estimate honest. The token counts are the hard part: measure a week of real usage from the usage fields before you trust a monthly figure. And a cheaper model that needs more turns to finish a task can cost more per task than its price suggests, so compare cost per finished task, not cost per token.

Other charges that can appear

• Images and video. Image inputs are counted in tokens on most text models. Video generation is usually priced per second of output instead, by resolution; see the video models page.
• Context caps. Some models on BoostRail accept inputs up to a stated cap at a single flat rate. Larger inputs return a context_length_exceeded error before any charge.
• Interrupted streams. A streaming request closed before it completes is billed for the usage the provider reports, which can include reasoning tokens. The exact rule is in the pricing FAQ.
• Failed requests. On BoostRail, when every route for a model fails, the request is not charged. Your own retries are new requests and are billed if they succeed.
• Top-up fees. Card top-ups carry a 5.5% processing fee with a $0.80 minimum; USDT top-ups carry 1% with a $0.10 minimum. Pay-as-you-go use has no monthly subscription.

How to bring the bill down

• Keep the prompt prefix stable. Put fixed instructions and tool definitions first and changing content last, so repeated requests share a cacheable prefix.
• Route by task. Send planning and hard reasoning to a strong model, and bulk summarising, classification and simple edits to a cheap one. The DeepSeek V4 Pro vs Flash post walks through one such split.
• Choose the reasoning effort. Many reasoning models accept a lower effort setting (reasoning_effort on Chat Completions). On a coding prompt we tested, low cut GLM-5.3's output from 29,570 tokens to 3,348.
• Set max_tokens on purpose. Enough for reasoning models to finish, not so much that a runaway answer gets expensive.
• Cap spending per key. BoostRail keys can carry a daily or monthly spend limit; requests past it return key_spend_limit_exceeded instead of growing the bill. See Errors and failover.

Frequently asked questions

Is a token the same across models?

No. Each lab has its own tokenizer, so the same text produces different token counts on different models. Compare models on the usage they report for the same request, not on the price list alone.

Why is output more expensive than input?

Generating a token takes more compute time than reading one, because output is produced one token at a time, and labs price output accordingly. Prices in the catalog show output at several times the input price for most models.

How are reasoning tokens billed?

As output. The model's thinking is counted in the output tokens of the response, even when only the final answer is shown. A short answer from a reasoning model can therefore bill far more output tokens than its visible length.

What is the cheapest way to run a coding agent?

Use a cache-friendly setup, a low-priced model for routine steps, and a strong model only where it changes the result. Then measure cost per finished task over a week; the catalog price alone does not tell you that.

Where can I see what each request cost?

In the BoostRail console. It records the usage and the price applied to every request, which is the number that reaches your balance.