Chapter 2 of 17 · 9 min read

Why count tokens instead of requests?

In short

Measuring the footprint of AI needs a unit. The request does not work: a ten-word question and the analysis of a long report count as one each. The token tracks what the machine computes and what you pay, as long as you separate tokens read, re-read and written.

In this chapter6 sections
  1. What a token is
  2. Why the request is a poor measure
  3. Not all tokens use the same energy
  4. The token count depends on the tokenizer
  5. What this changes in practice
  6. FAQ

Because tokens are what the model computes, what the provider bills and what the electricity is spent on. A "request" can hold ten words or a hundred page report. As a unit of measurement, it says almost nothing.

What a token is

Tokensubword unit, text fragment

A piece of text, often part of a word. The model cuts everything you send it into tokens before reading it, and it writes its answer token by token.

In French, a token averages 4.3 characters, against 4.9 in English (measured on OpenAI's o200k tokenizer). Claude's recent tokenizers cut finer and produce more tokens for the same text.

The split is learned once and for all, on a very large corpus of text. Frequent letter sequences become a single token, rare ones are cut into several pieces. The most widespread algorithm is called BPE.

So a language well represented in that corpus costs fewer tokens than a rare one. Nobody set a price per language. The corpus chosen by the model's designers ends up doing the same thing anyway.

Why the request is a poor measure

First, a request has no fixed size. A simple chat exchange comes to about 1,150 tokens, 1,000 read and 150 written. A single step of a Claude Code session sends the model 126,180 tokens of context at the median, according to the 2,676 sessions analysed by TraceLab. Both count as "one request", with a factor of 110 between them.

Second, the average size of a request moves, and fast. Reasoning models write drafts before answering, agents send the whole history back at every turn, and contexts are getting longer. Meanwhile, energy per token is falling: Google reports a 33-fold drop in the energy of its median Gemini request in one year (Google, 2025).

A per-request factor mixes these two movements. When it changes, you cannot tell whether requests got bigger or machines got more efficient, and you cannot even tell which way it is wrong. Counting in tokens separates the two.

Not all tokens use the same energy

A per-token factor can be compared from one tool to another, on one condition: saying which token you mean. There are four kinds.

Kind of tokenWhat it isEnergy, relative to input
Fresh inputtext the model reads for the first time1, the reference
Cache writetext read then set aside for later turns1 (billed slightly higher)
Cache readtext already read, taken back from the cacheabout 0.08, a value chosen between 0.05 and 0.20
Outputevery token the model writes, reasoning drafts includedabout 35

The ratio of 35 is measured when the machine handles only one request at a time. In production it handles dozens together and the gap narrows, but nobody publishes a value for that regime. The TokenClimate methodology uses a ratio of about 21 for Claude, taken from the estimates of Jegham et al.. The price follows other ratios: output is billed at 5 times input, cache reads at 0.025 to 0.1 times depending on the model at Anthropic (price list as of 10 October 2026).

These gaps change how a volume reads. On 17.4 billion tokens of coding agent sessions measured by claude-carbon between January and August 2026, computed with this methodology, output is 0.73% of the volume and 48.5% of the carbon. Cache reads are about 90% of the volume and 22.7% of the carbon.

On an agent session, output is 0.73% of token volume and 48.5% of the carbon

A dashboard that adds up all tokens at the same rate is therefore badly wrong. On this profile, if it counts everything at the input rate, it shows 3.3 times too much. If it only gets the cache wrong, it shows 3.6 times too much.

This formula has a known limit. It does not count the rereading of the whole context for every written token, a cost that grows with the length of the conversation. On an agent it weighs heavily, and the real figure is higher: chapter 12 puts a number on it.

Question

A team consumes 1 billion tokens a month. Which piece of information do you most need to turn that into a footprint?

Choisissez une réponse pour voir l'explication.

The token count depends on the tokenizer

The same text does not always give the same number of tokens. Anthropic writes it on its pricing page:

Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer that contributes to their improved performance on a wide range of tasks. This tokenizer produces approximately 30% more tokens for the same text. The exact increase depends on the content and workload shape. Claude Sonnet 4.6 and earlier models use the previous tokenizer.

For the same text, the count goes up by about 30% depending on the content, and the bill with it if the price per token does not move. If you start from the tokens actually billed, there is nothing to correct: the count already reflects the split of the model used. The gap matters mostly when reading a trend. After a model change, the same work can show more tokens without any change in usage.

What this changes in practice

For a carbon inventory, ask for the usage export in tokens, broken down by model, by kind of token and by period. Anthropic provides it to organisation accounts through its Usage API.

A figure taken from the invoice alone, multiplied by a monetary factor, stays fragile. Those factors were built on digital services whose cost structure has nothing in common with a model API, where the price includes margin and commercial positioning. MISSING DATA on the size of the gap: no publication compares a monetary factor with a token measurement on the same usage. That work can only be done at a client who has both.

Next chapter: for identical content, the number of tokens depends on the language.

FAQ

Should you count requests or tokens to measure AI usage?

Tokens. The model's computation, the provider's bill and the electricity used all depend on the number of tokens handled. A simple chat request is about 1,150 tokens, a coding agent step more than 100,000: a per-request factor cannot compare the two.

Why does a per-request emission factor age badly?

Because the average size of a request is rising, driven by reasoning models, agents and longer contexts, while energy per token is falling. A per-request factor mixes these two movements: its error changes in size and even in direction with nothing to flag it.

Do all tokens use the same energy?

No. An output token uses about 35 times an input token when the machine handles one request at a time, and the TokenClimate methodology uses about 21 for Claude. A token reread from the cache counts as about 0.08 times an input token. On a coding agent session, output is less than 1% of the volume and nearly half the carbon, and a single counter is wrong by a factor of 3.3 to 3.6.

How many characters does a token represent?

On OpenAI's o200k tokenizer, about 4.9 characters in English and 4.3 in French, so roughly 1.23 tokens per word in English and 1.44 in French. The tokenizer of Claude Opus 4.7 and later models produces about 30% more. These values hold neither for code nor for languages written in non-Latin scripts.

Is the token count of a text stable over time?

No. Anthropic states that the tokenizer introduced with Claude Opus 4.7 produces about 30% more tokens for the same text, depending on the content (0 to 35% depending on content, per the April 2026 announcement). If you start from the tokens billed, the count already reflects the split of the model used. The gap matters mostly when comparing two periods separated by a model change.

The whole course as a PDF

All seventeen chapters in one file, to read offline or pass around a team. The three annexes come with it.

One-click unsubscribe. No spam.

Back to the course