Every request is billed as the sum of two parts: the tokens that go in and the tokens that come out. Both are familiar, but most surprises in an LLM bill come from the output side — and from reasoning tokens you never even see.
Tokens are not characters
Before the input/output split makes sense, it helps to pin down what a token is. A token is a chunk of text — usually a word, part of a word, or a piece of punctuation — that the model's tokenizer carves out of your input. As a rough rule of thumb, one token is about four characters of English, so a 1,000-word prompt is somewhere in the neighborhood of 1,300 tokens. Exact counts vary by model and tokenizer, which is why your own usage log is more reliable than any estimate.
Input vs output tokens
- Input tokens — your prompt, any system instructions, conversation history, and retrieved context.
- Output tokens — the model's reply, including any reasoning it produced internally.
Providers price these separately for a reason: output generation is the expensive part. Producing one output token typically requires evaluating the model across your full input context, so output is priced several times higher than input.
Why output dominates your bill
Because output costs more per token, the total cost of a request depends heavily on how long the model's answer is — not just how long your prompt is. A verbose model writing 2,000-token answers will cost far more than a terse one writing 300, even if the prompts are identical.
The practical takeaway: watch output length before you watch prompt size.
Why estimates are approximate
Two things make "tokens" slippery in practice. First, tokenizers differ between models, so the same sentence is not the same number of tokens everywhere. Second, your prompt may repeat across a conversation — every historical turn is re-sent on each new message, so a long chat is re-billed for its full history with every reply. That is why a chat that "feels short" can bill like a long document: the input silently compounds with each turn.
A worked example
Say a model prices input at $0.15 per million tokens and output at $0.60 per million. A request with a 2,000-token prompt and a 500-token answer costs:
- Input: 2,000 × 0.15 / 1,000,000 = $0.00030
- Output: 500 × 0.60 / 1,000,000 = $0.00030
The answer is as expensive as a prompt four times its length. Scale that to thousands of requests a day and the output side dominates your total.
Reasoning tokens hide in the input
Reasoning models produce a long internal chain of thought that is not part of the visible reply. Depending on the provider, those tokens are billed as output or shown as an extra input field. Either way, a reasoning pass can silently multiply the cost of a single answer. Before adopting a reasoning model for a task, check its actual token usage on a real request — not the benchmark page.
How Mappace bills
On Mappace you pay exactly the underlying model's rate. There is no subscription, no minimum, and no markup on token usage.
- Top up any amount; every request deducts only the tokens you actually used.
- The gateway reserves a small buffer before each call to guard against streaming overshoot.
- After the response, it bills the real token count and returns the remainder.
That means the number on your bill always traces back to the provider's public price — you are never paying a mystery surcharge.
Estimate before you spend
Because prices are per model and transparent, you can predict a request's cost by multiplying your expected input and output tokens by each model's rates. See the exact cost of every request in your usage analytics, or check live per-token prices in the model catalog.