Estimating tokens before launch, with no traffic yet
Four characters per token is accurate enough to be dangerous. It holds for English prose, which is what everyone tests it on, and it quietly falls apart on the three things production systems are actually full of: code, JSON and languages that are not English. If your first budget was built on that ratio, it is probably wrong in the same direction every time, which is the worst kind of wrong because the error compounds with volume rather than cancelling out.
The two rules worth carrying in your head are roughly four characters per token and roughly 1.3 tokens per English word. They agree with each other and with reality on ordinary paragraphs. Then the exceptions.
Code tokenises at closer to 2.5 to 3 characters per token, because indentation, brackets, operators and camelCase identifiers all fragment. A 200-line Python file is not 200 lines of prose. JSON is worse still: every key is repeated on every object, and quotes, colons, braces and commas are all tokens carrying no information for the model. A 40-field API response can spend a third of its tokens on punctuation. Non-Latin scripts break the character rule from the other direction. Chinese packs far more meaning per character but each character often costs one or two tokens, so the character count collapses while the token count does not. Russian, Hindi and Thai routinely need two to three times the tokens of the equivalent English sentence, which means a multilingual product has a per-request cost that varies by language even when the work is identical.
None of that is a reason to guess more carefully. It is a reason to stop guessing.
Build a sample, not an average
The single highest-value hour before launch is spent assembling 200 real inputs and counting them. If you are replacing a manual process, the inputs already exist: export 200 real tickets, documents or transcripts, run them through the tokeniser for the model you intend to use, and keep the whole distribution rather than the mean. If the product is genuinely new, write 30 by hand, ask two colleagues for 30 more each, and then deliberately hunt for the pathological cases, the 400-message thread, the customer who pastes an entire error log, the document that is mostly a table. Those are not outliers to be excluded. They are the reason your forecast will be wrong.
Count with the tokeniser belonging to the model you actually intend to ship, because counts are not portable between vendors. The same 10,000-word document can differ by 10% or more between two providers' tokenisers, and on a multilingual or code-heavy corpus the gap is wider. If a provider does not publish a tokeniser you can run locally, make one cheap call per sample and read the token counts straight out of the usage block in the response: 200 calls on Claude Haiku 4.5 at these sizes costs under a dollar and gives you the vendor's own arithmetic rather than your approximation of it. Remember that anything non-textual has a token price too, so if the feature accepts screenshots or PDFs, price those attachments explicitly rather than treating them as free context.
Paste a handful into the token estimator to sanity-check the shape before you script the full run.
What you get back is a distribution, and the two numbers that matter are not the ones people quote. The median is close to useless for cost because these distributions are always right-skewed: the mean is what multiplies out to the bill, and the mean sits well above the median. In the sample below the median transcript is 1,900 tokens and the mean is 2,600, so budgeting from the median under-forecasts by 27% before anything else goes wrong.
The 95th percentile does two other jobs. It tells you whether you have a context-window problem, and it explains where the mean came from. If the top 5% of transcripts average 11,000 tokens, they contribute 0.05 x 11,000 = 550 tokens to that 2,600-token mean, meaning one request in twenty accounts for 21% of your entire input spend. That is a fact worth knowing before you launch, because truncating or summarising just that tail is a 20% cost reduction that touches 5% of users.
A worked estimate: support summarisation
The spec: when an agent closes a conversation, a button produces a 120-word summary for the CRM. Nothing else.
From the sample of 200 real transcripts, the mean is 2,600 tokens and the 95th percentile is 6,800. The system prompt, with the format instructions and two worked examples, is 420 tokens. A 120-word summary at 1.3 tokens per word is 156 tokens, and formatting overhead takes it to about 180.
Mean input is therefore 2,600 + 420 = 3,020 tokens, with 180 output. On Claude Haiku 4.5 at $1.00 input and $5.00 output per million:
- input: 3,020 x $1.00/1,000,000 = $0.00302
- output: 180 x $5.00/1,000,000 = $0.00090
- per call: $0.00392
At 12,000 summaries a month that is 12,000 x $0.00392 = $47.04. The 95th-percentile request costs 7,220 x $1.00/M + $0.0009 = $0.00812, a little over twice the average, which tells you the tail is a nuisance rather than a crisis here. Run the same figures against a larger model in the LLM API cost calculator before you settle: the whole feature at $47 a month means model choice should be decided on summary quality, not price.
The four omissions
The system prompt. It is charged on every single call, and it is the part of the input nobody counts because it is not user data. Here it is 420 tokens across 12,000 calls, so 5.04M tokens and $5.04 a month, which is 11% of the bill for text that never changes. Let it grow to 2,000 tokens with a dozen few-shot examples and it becomes 24M tokens and $24 a month, half the total. This is also the part that caches best: Haiku 4.5 cached input is $0.10 per million, a 90% reduction on the fixed prefix.
Conversation history. In any multi-turn feature you resend the entire conversation every turn, so cost grows quadratically with turn count. Take a 400-token system prompt, 120-token user messages and 220-token replies. Input at turn n is 180 + 340n tokens, so ten turns bills 1,800 + 340 x 55 = 20,500 input tokens for a conversation in which the user typed 1,200 tokens. That is seventeen times the naive count, and it is the single most common reason a chatbot forecast comes in low by an order of magnitude.
Tool-call round trips. One user question that triggers three tool calls is four model calls, not one, and each carries the full history plus every tool result so far. Tool results are usually JSON, usually verbose, and frequently larger than anything the user wrote: three 2,000-token API responses add 6,000 tokens to the final call and appear in every intermediate call after they arrive. Count round trips per user action in the spec, then multiply.
Reasoning tokens. On a reasoning model the hidden thinking is billed at the output rate, and there is a lot of it. A visible 180-token answer sitting behind 1,500 reasoning tokens bills as 1,680 output tokens. At GPT-5.6 Terra's $12.00 per million output, that is 1,680 x $12.00/M = $0.02016 against the $0.00216 you would have forecast from the visible answer alone, roughly nine times. If your estimate has a reasoning model in it and no reasoning-token line, the estimate is not finished.
Add those four to the worked example above and the honest per-call figure moves substantially, which is the point: the transcript was never the expensive part. Count what the model receives and emits, not what the user sees.
All figures in this guide come from the price index, last verified 15 August 2026. Every entry links to the vendor page it was read from — see the price index and the methodology.