Bytes, characters, tokens: which one gets billed and how do they relate?

**LLM APIs bill per token**, never per byte or per character. A token is a unit the model's tokenizer produces by splitting your text into chunks, then mapping each chunk to an integer in the model's vocabulary. The same text, run through different tokenizers, will produce different token counts. For English prose, a useful rule of thumb is about 3 to 4 characters per token. A typical English word is one or two tokens. A 1,000-character English email is roughly 250 tokens. This is why providers can give back of the envelope estimates like '1 page is about 500 tokens' for natural-language prose. The ratio breaks down when the content is not English prose. Code uses lots of punctuation, identifiers, and indentation that the tokenizer was not trained to compress well; a 1,000-character Python file might tokenize to 350 tokens or more. Minified JSON has the same problem. Non-Latin scripts (Hindi, Arabic, Japanese, Chinese) tokenize much worse: a single character might consume several tokens because the underlying UTF-8 bytes get split into small pieces. The only reliable way to count tokens is to run the model's own tokenizer over your exact string. OpenAI provides the `tiktoken` library; Anthropic provides a `count_tokens` API; Hugging Face Transformers exposes any tokenizer via `AutoTokenizer`. Treat any character-based estimate as a rough guide, never as a billing prediction.

**LLM APIs bill on tokens**, and the byte to token ratio is a property of the tokenizer and the content, not a fixed conversion. Every modern LLM uses a BPE-family tokenizer (byte-pair encoding or a close variant like SentencePiece or WordPiece), trained on a specific corpus to greedily merge frequently-occurring byte sequences into vocabulary entries. The practical implications fall out from how BPE training works. Common English words and word-pieces in the training corpus get their own tokens, so English compresses well: roughly 3 to 4 characters per token, or about 250 tokens per 1,000 characters. Less-common patterns decompose into multiple tokens. The result is that token count depends on what you wrote, not just how long it is. Three examples drive this home: - **English prose (1,000 chars)**: ~250 tokens. - **Minified JSON (1,000 chars)**: ~350-450 tokens. Quotes, braces, and short keys do not compress. - **Hindi or Japanese text (1,000 chars)**: ~700-1,200 tokens. The tokenizer was trained on mostly-English text, so non-Latin characters often decompose into raw UTF-8 byte tokens. Different models use different tokenizers. `cl100k_base` is GPT-4 / GPT-3.5 / text-embedding-3. `o200k_base` is GPT-4o / GPT-4o-mini / o1 / o3, with a larger vocabulary (200k vs 100k) that compresses better for code and non-English. Llama 3 uses a 128k-token SentencePiece vocabulary. Claude 3 / 4 use their own proprietary tokenizer. The same string can have very different token counts across these models. The operational implication is that you cannot estimate cost reliably from character or byte count alone. The OpenAI tiktoken library, Anthropic's `count_tokens` endpoint, and Hugging Face's `AutoTokenizer.encode()` are the only authoritative count sources. Production cost models always run the actual tokenizer; estimating from character count introduces 20-40% error on mixed workloads.