Desk Log: Counting Tokens on a Scrap of Paper

Shift note: start with one sentence

Write this sentence on a scrap of paper: Send the report. Before opening a tokenizer or an API console, count its words. There are three. Now count its characters, including spaces and the period. There are sixteen. Neither count tells you its token count.

A token is a unit of text used by a model. Depending on the tokenizer, it can represent a whole word, part of a word, punctuation, or text that includes a space. The tokenizer is the system that converts text into those units. Tokens are not simply another name for words.

Four pencil marks explain the idea

For this exercise, pretend our sentence is split into four pieces: “Send”, “ the”, “ report”, and “.”. Notice the leading spaces inside the second and third pieces. Put one pencil mark beneath each piece. You have counted four pretend tokens.

This is an invented split for learning, not a verified token count. A real tokenizer may divide the sentence differently. The point is to practice counting pieces without assuming that every word produces exactly one token.

Try three small changes on the same paper:

• Insert “updated” before “report” and sketch where another piece might appear.
• Replace “report” with a long technical identifier and mark several possible breaks inside it.
• Add a second exclamation mark and note that punctuation can affect the count too.

Do not try to establish exact counts from these guesses. You are building an intuition: changes in wording, punctuation, spacing, and spelling can change tokenization. A technical identifier might split into several pieces even when it looks like one word.

The same text needs the right tokenizer

Next, take the original sentence to a tokenizer tool documented for your chosen model, if one is available. Compare its result with your pencil marks. If the tool displays token boundaries, inspect the spaces and punctuation rather than just the total.

If you switch between Gemini 2.5 Flash and Claude Haiku 4.5, do not assume that either uses the same splits or counts. Use each provider’s documented counting method where available. A generic tokenizer can help explain the concept, but it is not automatically an authoritative meter for every model.

For an API request, inspect the returned usage fields as well. Their names and treatment of cached input, reasoning, and other categories vary. Read the documentation before treating a displayed number as the complete billable total.

The request contains more than your last sentence

Your visible message is often only part of the input. Instructions, conversation history, tool definitions, and tool results may also contribute. An application can quietly send a long conversation even when the latest question is short.

Make a second paper ledger with hypothetical counts: 1,200 input tokens and a planned allowance of 300 output tokens. That gives you a planning total of 1,500 tokens. It does not establish a price: input and output may have different rates, and other billing categories may apply.

A context window is the model’s working token budget for a request. Its exact rules, including how output and reasoning fit, depend on the model. An output limit is a ceiling, not a promise that the answer will use that many tokens.

End the exercise with a small measured request

Send one short request, record its reported usage, and change only one thing before repeating it. Adding a paragraph of history is a useful test. Keep the model fixed so that switching tokenizers does not muddy the comparison.

If your next step is trying several model families through one pay-as-you-go relay desk, Relay365 is a practical option. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Create an account when you are ready to run that small comparison, and check current model pricing first.

Keep the paper beside the console. The hand count teaches the idea; the model-specific counter and API usage record supply the measurements.