What a token is and why it sets your bill
A token is a chunk of text, about four characters of English, and an LLM API bills every token it reads and every token it writes at separate rates.
A token is the unit the invoice counts
A token is a piece of text a language model reads or writes, roughly four characters of English, and it is the unit an LLM API bills in. Providers publish one price per million input tokens and another per million output tokens. Your bill is the count of each, divided by a million, times its rate. Words, requests and minutes never appear on the invoice. Tokens do.
Every token price on record here is quoted in that same unit (models priced: 467; providers: 16). The token price table lists them by model, with the page each rate was read from and the date it was read.
That shared unit is the useful part. A per-million rate lets you compare sellers without knowing anything else about them. It also hides how many tokens your own traffic produces, which is the half of the sum nobody publishes for you.
Why four characters is only a rule of thumb
A tokenizer splits text into pieces it has seen often. Common English words usually come through whole, and a long or rare word gets cut into several parts. The rough rule of four characters per token holds for ordinary prose and breaks quickly outside it.
Code can cost more tokens than its length suggests, because indentation, brackets and variable names may split into many pieces, and deeply nested JSON likewise. Text in languages other than English can take more tokens for the same meaning, and long strings of digits get chopped into short runs.
Each model family ships its own tokenizer, so the same paragraph can come out at a different count depending on the model. Before trusting an estimate, run a sample of your real prompts through the tokenizer for the model you plan to use and read the number it returns.
Two meters run on every call
Input tokens are everything you send: the system prompt, the instructions, any documents you paste in, and in a chat, the whole conversation so far. Output tokens are what the model writes back. On models that reason before answering, the tokens spent thinking may be billed as output even when you never see them; the seller's documentation says which.
Output is commonly priced higher than input, sometimes by a wide margin, so a workload that writes long answers behaves differently on the bill from one that reads long documents and replies in a line. The direction matters as much as the total.
Image and audio inputs can be converted into tokens as well, at a count set by the seller for each picture or second of sound. For a product that accepts screenshots or voice, those inputs belong on the input side of the estimate, and their count depends on the seller's own method rather than on any character rule.
From tokens to a monthly figure
The sum has two halves. Take requests per month times average input tokens per request, divide by a million and multiply by the input rate. Do the same with average output tokens and the output rate. Add the two halves. That is the list-price month before any cached or batch discount.
Worked through for a help-desk assistant: each request carries a fixed system prompt, the customer question and a few retrieved help articles as input, and returns an answer as output. The retrieved articles are likely to be most of the input side. The answer length drives the output side, and a rule that keeps answers short can move the bill more than trimming the question.
The LLM cost calculator does this sum for every seller of a model at once, using the published rates. It takes monthly input and output token totals, so the work left to you is the per-request estimate.
Where the count grows without anyone choosing it
Chat is the usual surprise. Every new turn resends the earlier turns as input, so a conversation that runs long costs more per message at the end than at the start. Nobody decided to pay for that. It falls out of how a stateless API is called.
System prompts drift the same way. A team adds a rule, then an example, then a format reminder, and every request in production carries the extra text. Logging the token counts the API returns with each response, and looking at them weekly, catches this before the invoice does.
Agents are the third case. Each step of a task sends the instructions, the tool descriptions and the history so far, then appends one more action. A task that takes many steps pays for its opening instructions once per step. Counting the steps an agent takes on a typical task is the first number to find.
Reading the counts the API sends back
Every response from a token-priced API includes a usage block: input tokens, output tokens, and on sellers that cache, the cached portion. That block is the bill in miniature. It is also the only count that matches what the seller will charge, because it comes from the seller's own tokenizer.
Store it. A table with the time, the feature, the model and those token counts answers the usual finance questions about the LLM line. It shows which feature is growing, which prompt got longer last week and which model is carrying the spend.
The counts also settle arguments about estimates. A product manager who thinks the average question is short and an engineer who thinks the retrieved context is long can both look at the same column. Whoever was wrong learns it from a log instead of from an invoice at month end.
What we could not answer
- ⚑We hold rates, not tokenizers, so nothing here says how many tokens a given text becomes on a given model.
- ⚑Whether reasoning tokens are billed as output varies by seller and is not a field we record.
What this rests on
infratoapp, “What a token is and why it sets your bill”, read 27 October 2026. models with a token price on record: 467. https://www.infratoapp.com/blog/what-a-token-is-in-llm-pricing
Questions people ask about this
How many characters is one token?
For ordinary English prose, roughly four characters, or a little under one word. The ratio changes with the text: code, structured data, digits and many languages other than English produce more tokens for the same length. Each model family uses its own tokenizer, so count with the one you will actually call.
Are input and output tokens priced the same?
Usually not. Providers publish a separate rate per million input tokens and per million output tokens, and output is commonly the higher of the two. A workload that writes long answers is therefore weighted differently on the bill from one that reads long documents and replies briefly.
Do I pay for the system prompt on every request?
Yes. The system prompt is part of the input on every call, so its length is multiplied by every request you send. Where a seller offers a cached input rate, a repeated prefix such as a fixed system prompt may be billed lower, but only where that rate is published.
These render as FAQPage structured data · answers are filled from the same live figures
Read next
Input and output tokens carry separate per-million rates, output is commonly dearer, and a blended rate only means something for one fixed mix of the two.
A cached input rate bills a repeated prompt prefix for less, but only where the seller publishes one; everywhere else the same tokens pay the full input rate.
A large context window is a limit, not a charge; the charge is every token you actually place in it, billed as input on every call that carries it.