Tokens and cost
Models read tokens, not words, and you pay per token. The same message can cost several times more depending on the language, the content and the tokenizer.
- Tokens
- 0
- Characters
- 0
- Words
- 0
- Characters per token
- –
Same text, three tokenizers
| Tokenizer | Tokens | vs o200k |
|---|
Each colour is one token. A dashed box is one character that needed several tokens.
What it costs
Per-request and monthly cost at list price, cheapest first. Input defaults to the token count above.
| Model | $ per 1M in / out | Per request | Per month |
|---|
List prices as of , standard tier, text only, from . Token counts here use OpenAI's public tokenizers. Anthropic and Google use their own, so treat their rows as estimates. Batch and caching discounts not included.
How it works
- o200k_base and cl100k_base are OpenAI's published tokenizers, run exactly in your browser. WordPiece is the tokenizer of the small embedding model on the Embeddings page.
- Newer tokenizers have bigger vocabularies, so Japanese and Tamil take fewer tokens on o200k than on cl100k, Tamil by a wide margin. Hex strings like wallet addresses get no such help on either.
- A low WordPiece count on Japanese or Tamil is not good news. The table counts the [UNK] tokens: words outside the embedding model's vocabulary, which it cannot read at all.
- Prices live in one JSON file with the date and source. Updating them does not touch code.
In production I would
- Count tokens with each vendor's own counting API before committing to a budget, not with a proxy tokenizer.
- Strip or shorten things models do not need, such as long hashes, signatures and quoted email chains, before the call.
- Route by difficulty: a cheap model for triage and summaries, a stronger one only for the hard cases.
- Track cost per resolved ticket, not cost per call. That is the number finance cares about.