Why does our estimate keep coming in low?

Probably because it was built from a word count on ordinary prose and applied to something else. Formatting, code, identifiers and unusual names all pack badly, and those are common in exactly the documents an organisation wants to process in bulk.

Can we just multiply words by a fixed number?

For a rough sense, yes. For a budget, no. The ratio changes with the language, the subject matter and the formatting, so a rule of thumb is least accurate on the unusual material that is most likely to be worth automating.

How should we get a real figure?

Use the tokeniser that the system you are actually using applies, on a genuine sample of your own material rather than on a paragraph of clean prose chosen because it was to hand. Most providers offer a way to do this, and it takes a few minutes.

Glossary

Tokenisation

Cutting text into the chunks a model actually reads, which are neither letters nor words and are what you are billed and limited by.

In plain terms

Chopping text into pieces before the model sees it. The pieces are not words and not letters, they are somewhere in between, and they are the unit everything is priced and limited in, which is why estimating from a word count is always a little wrong.

Why it matters

Because every limit and every price is expressed in a unit nobody can count by looking. Budgets, context limits and cost estimates are all built on it, and the gap between what a person counts and what the system counts is not a constant you can multiply by.

How it works

The pieces are chosen for compression rather than meaning. Common sequences become one piece and rare ones are broken up, so an everyday word may be a single unit while an unusual name becomes several.

That is why the mismatch is uneven. Ordinary prose in a well-represented language packs efficiently; specialist vocabulary, unusual names, code and identifiers pack badly, so two documents of identical length can differ substantially in what they cost.

Languages are not treated equally, and this is worth knowing before it appears on an invoice. Text in a language less represented in the material the tokeniser was built from breaks into more pieces, so the same meaning costs more to send and takes more of the available room.

Whitespace and punctuation are not free. Formatting, indentation and repeated separators all occupy space, which is why a heavily formatted document can be considerably more expensive to send than its readable content suggests.

Different tools count differently, so a figure from one is not a figure for another. Any estimate worth relying on has to come from the tokeniser the system you are using actually applies, and most providers offer a way to check.

The practical consequence is to measure rather than estimate. A word count multiplied by a rule of thumb is fine for a rough sense and unreliable for a budget, and the difference matters most on exactly the material that is unusual enough to be worth automating.

Same length, different cost

The pattern in the right-hand column is not a coincidence. Text packs efficiently when it resembles what the tokeniser was built from, which is broadly ordinary writing, and everything an organisation finds worth automating tends to be unlike ordinary writing in some specific way: it has part numbers, or legal citations, or tabular structure, or terminology from a trade. So the material that most justifies the effort is reliably the material where a word-count estimate is furthest out, and the direction of the error is always the same one. The practical habit is small and worth adopting early: before committing to a volume, run a genuine sample of your own documents through the tokeniser the system uses, rather than a paragraph of clean text chosen because it was to hand. It takes a few minutes, it produces a number you can actually budget against, and it is the difference between a forecast that holds and one that has to be explained.

Seen in the wild

A long document costing more than its word count suggested because of formatting.
ChatGPT
Code and identifiers packing far less efficiently than prose of the same length.
Claude Code
Checking the count with the tokeniser the model actually uses rather than estimating.
Hugging Face

Common misconceptions

People assume

A token is roughly a word.

In fact

It is a chunk chosen for compression, so a common word can be one and an unusual name several. The relationship is not a fixed ratio, which is exactly why a rule of thumb fails on the material that matters.

People assume

The same text costs the same in any language.

In fact

Text in a language less represented in the tokeniser's source material breaks into more pieces, so the same meaning costs more to send and occupies more of the available room. It is a property of the tokeniser rather than of the language.

Questions

Why does our estimate keep coming in low?: Probably because it was built from a word count on ordinary prose and applied to something else. Formatting, code, identifiers and unusual names all pack badly, and those are common in exactly the documents an organisation wants to process in bulk.
Can we just multiply words by a fixed number?: For a rough sense, yes. For a budget, no. The ratio changes with the language, the subject matter and the formatting, so a rule of thumb is least accurate on the unusual material that is most likely to be worth automating.
How should we get a real figure?: Use the tokeniser that the system you are actually using applies, on a genuine sample of your own material rather than on a paragraph of clean prose chosen because it was to hand. Most providers offer a way to do this, and it takes a few minutes.