Because a model does not compute requests, it computes tokens. Prefill handles the input, decoding produces the output. The bill multiplies each one by its rate, and the energy follows the same split.
A "request" bundles together volumes that vary by a factor of 100 between two calls to the same model. So an emission factor per request ages badly, and always towards under-estimation.
What a token actually is
A model reads neither letters nor words. It reads integer identifiers produced by a subword split. Frequent sequences become a single token, rare ones break into pieces, so no word is ever out of vocabulary.
One token is worth roughly 4.9 characters in English and 4.3 in French. The computation, the bill and the footprint are all counted in this unit, the only one of the three measurable end to end.
The split is produced by an algorithm called BPE, which iteratively merges the most frequent pairs of symbols in a large corpus until it reaches the target vocabulary size. What comes out is an ordered list of merge rules, applied deterministically.
Keep one consequence in mind for everything that follows: the tokenizer is a statistical artefact of the corpus it was built on. What was frequent there costs little, the rest costs a lot. Nobody decided that one language would cost more than another. The corpus produced that.
Why the request is a bad denominator
Three reasons, worst first.
A request has no size. Two calls to the same model can differ by a factor of 100 in tokens handled. A ten word question and the analysis of a hundred page report are both "a request".
Tokens per task are rising structurally. Reasoning models write drafts and agents send the whole history back at every turn. Contexts are getting longer too. A factor calibrated on the average volume of a 2024 request is calibrated on an object that no longer exists.
The gap always runs the same way. Tokens per task go up, energy per token comes down. A per-request factor lumps both movements together and loses the only one that is stable.
A per-token factor stays comparable, on one condition
The condition is easy to state and almost never met: you have to say which token you are talking about.
| Token class | What it is | Relative cost |
|---|---|---|
| Fresh input | text the model has never seen, handled in prefill | reference, 1 |
| Cache read | prefix already handled, reused | about 0.08 |
| Output | every generated token | about 35 |
| Reasoning | internal draft, billed as output | 35, and often the majority |
The relative costs in this table are measured at batch size one. In production, at large batch, the gap between input and output narrows, and nobody publishes a reference value for that regime.
Taking coding agent sessions from claude-carbon as the base, the breakdown gives a counter-intuitive result: output accounts for 0.73% of the volume and 48.5% of the carbon, while cache reads make up around 90% of the volume for 22.7% of the carbon.
A dashboard with a single token counter is wrong by a factor of 5 to 10 depending on the rate it applies to cache reads. The error stays invisible until you break the volume down, which is what makes it expensive.
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 is not a stable physical unit
A limit to know about before building on it. 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.
With the text unchanged and the price per token unchanged, the bill and the count both move by 30% because the split changed. Carbon tracking in tokens therefore has to version the tokenizer exactly as it versions the model.
Not a reason to go back to the request. Just a reason to date your factors, like an electricity emission factor.
What this changes in practice
For a carbon inventory, the activity data to ask for is not a request count or an invoiced amount, but a usage export in tokens, broken down, by model and by period. The APIs of all three major providers give it, and it is the only data that does not go stale.
If all you have is the invoice, say so and bound the scope of the result. The monetary factors available were built on digital services whose cost structure has nothing to do with a model API, where the price bakes in margin, contractual latency and commercial positioning. MISSING DATA on the size of the bias: no publication compares a monetary factor against a token measurement on the same usage. That work gets done at a client who has both.
Next chapter: at identical volume, the number of tokens depends on the language you write in.
FAQ
Should you count requests or tokens to measure AI usage?
Tokens. A language model bills, computes and consumes per token, never per request. Two calls to the same model can differ by a factor of 100 in tokens handled, which makes an emission factor per request unverifiable and unstable over time.
Why does a per-request emission factor age badly?
Because the number of tokens consumed per task rises structurally, driven by reasoning models, agents and longer contexts, while energy per token falls. A per-request factor lumps those two opposing movements together and loses the only stable one, so it under-estimates more and more, with no signal.
Do all tokens cost the same?
No, and the gap is large. An output token costs about 35 times an input token in energy measured at batch size one, and a token read from cache about 0.08 times. On an agent session, output accounts for less than 1% of the volume but nearly half the carbon. A single counter is wrong by a factor of 5 to 10.
How many characters does a token represent?
Around 4.9 characters in English and 4.3 in French on current tokenizers, so roughly 1.23 tokens per word in English and 1.44 in French. These values depend on the tokenizer in use and do not hold for code or for languages written in non-Latin scripts.
Is the token count of a text stable over time?
No. Anthropic states that the tokenizer introduced from Claude 4.7 onwards produces about 30% more tokens for the same text. Carbon tracking in tokens therefore has to version the tokenizer used, exactly as it dates its electricity emission factor.