A token is a chunk of text, not a word
When you send text to an LLM, the model doesn't read it as words or letters. It first breaks the text into tokens: small chunks that are usually somewhere between a single character and a full word. Common short words like "the" or "is" are often one token each. Longer or less common words frequently split into two or more pieces. The word "tokenization" itself, for example, commonly breaks into something like "token" and "ization" as two separate tokens.
This matters because every model prices its API by the token, not by the word or the character. So the actual size of your bill depends on how your specific text happens to break apart, not on how long it looks to you.
Why word count is a rough guide, not a real answer
A widely used rule of thumb is that English text averages around 4 characters per token, or roughly 1.3 tokens per word. That's a reasonable estimate for typical sentences, but several things push the real number higher:
- Uncommon words and names tend to split into more pieces than everyday vocabulary
- Code, JSON, and structured data tokenize less efficiently than plain prose, symbols and indentation count too
- Non-English languages often use noticeably more tokens per word than English, since most tokenizers are trained predominantly on English text
- Numbers and punctuation-heavy text (prices, dates, IDs) fragment more than you'd expect
This is also why two different models can report different token counts for the exact same input, each provider trains its own tokenizer, so the same sentence gets sliced differently depending on which model you're calling.
Input tokens and output tokens aren't priced the same
Almost every provider charges a different rate for what you send (input) versus what the model generates back (output), and output is typically priced several times higher than input. That means a short prompt that produces a long, detailed answer can cost meaningfully more than a long prompt that gets a short reply. When you're estimating a budget, the expected length of the response usually matters more than the length of your question.
Why this is worth estimating before you build
Per-request costs look tiny in isolation, fractions of a cent, easy to shrug off. But they scale linearly with usage, and usage has a habit of growing faster than expected once a feature ships. A cost that looks negligible at 100 requests a day can turn into a real budget line at 10,000. Estimating token usage and comparing model pricing before you commit to one is a cheap way to avoid an expensive surprise a few months in.