Tokens: the atom of everything

1,547,701,404 tokens. That's what my Claude Code transcripts for this blog's pipeline record across 7,426 API requests (subagent runs not included), counted on August 12, 2026. When I decomposed where the money went, the slot my instinct said to shrink, the model's output, turned out to be 16% of what it would have cost at Opus 5 API rates. The other 84% was in the two cache slots I had been counting for months. (At Opus 5.5's rates, 22% and 78%.)

A token is a model-specific unit with a price attached, and the price swings 50× or more depending on what the machine did with it. Ten or more for cached versus fresh, five for output versus input, and the first is the one you control. Get the unit wrong and you optimize the wrong thing. I did.

What a token actually is

A token is a fragment of text, usually smaller than a word, drawn from a fixed menu that was frozen when the model was built. The model never sees your words. It sees a sequence of ID numbers pointing into that menu, and nothing in them marks where one word ends and the next begins.

The menu comes from the tokenizer, the program that does the splitting. The classic recipe is byte-pair encoding: start from the individual bytes of an enormous pile of text and repeatedly merge whichever adjacent pair occurs most often, for tens of thousands of rounds. Common words end up as one token. Rare ones split into several. "The" is one token. "Anthropomorphize" may come out as three or four fragments shared with other words. That's the generic recipe; Anthropic hasn't published the details of Claude's.

Your text has more than one token count

The token count belongs to the tokenizer. Change the model and the same paragraph is a different number of tokens.

Anthropic's own docs show this. Per its published model documentation, 1 million tokens is roughly 555,000 English words on Claude 4.7 and later, and roughly 750,000 on the generation before. Anthropic says the newer tokenizer produces roughly 30% more tokens from the same text; the word counts work out closer to 35%, and both are round approximations.

First, tiktoken gives the wrong count. It's OpenAI's tokenizer library, and a lot of tooling reaches for it to estimate "the" token count as though there were one. It's calibrated closer to the older ratio, so on current Claude it should undercount. I haven't measured how far. The right tool is Anthropic's count_tokens endpoint, which counts your request under the tokenizer of the model you'll actually call. It's free, and Anthropic doesn't promise it's exact.

Second, retire the "about 4 characters per token" folk rule. Anthropic publishes about 2.5 million Unicode characters per million tokens for Claude 4.7 and later (every model in the table below except Haiku 4.5), so a token is about 2.5 characters. The folk rule assumes 4, which is 60% too generous per token, so any budget built on it lands nearly 40% under. Anthropic's own pricing FAQ (4 characters) and glossary (3.5) don't reflect the current tokenizer. If you need a heuristic, use 2.5 characters per token, or 1.8 tokens per word, and name the models it applies to.

The price list

A token is a unit of price, and the price list is short. Anthropic's current models as of September 2026, largest to smallest, per million tokens:

(Dated deliberately, because prices change. Every price in this post was checked against Anthropic's live docs in late September 2026.)

Output costs exactly 5× input on all four, and on every other model on Anthropic's price list, the retired ones included.

Why output costs 5×

Reading your prompt and writing the reply are two different computations, and they load the hardware differently. When your prompt arrives, the model processes all of it at once, in a single parallel pass called prefill. That's one large parallel computation, which is what GPUs do best. Generating the reply, called decode, works nothing like that. To produce each token the model reads all of its weights (many gigabytes of numbers) from memory again. Every output token is its own sequential pass, and for most of it the chip is waiting on memory.

The roofline survey of large language model (LLM) inference (Yuan et al., 2024) models that gap. A roofline analysis measures arithmetic intensity, operations per byte read from memory, to tell whether a chip is limited by arithmetic or by memory. High means computing; low means waiting. On Llama-2-7b, a small open model, on an A6000 workstation GPU (one request at a time), the compute-bound layers run at 1,024 to 1,215 operations per byte during prefill and about 1 during decode. That's not what Claude runs on, but the shape is structural. Most of prefill is compute-bound; all of decode is memory-bound.

So the modeled gap is about a thousandfold and the price gap is 5×. Batching likely accounts for much of the difference: providers run many users' decode steps together and share one read of the weights across all of them. What survives is a real structural asymmetry, and it's what you're paying for. But a ratio that comes out at exactly 5.000 across a whole lineup is a pricing decision.

One token, four prices

The provider bills you for what it had to do with the token, and an input token can have four different things happen to it. The extra prices come from prompt caching. Agents and chat apps re-send the same long prefix (the stable block at the front of every request: system prompt, tool definitions, conversation so far) every turn, so providers let you cache the processed form. Re-reading a cached prefix costs a tenth of the input rate on most models, and less on the newest: a twentieth on Opus 5.5, a fortieth on Fable 5.1. Writing it in costs a premium, 1.25× for a cache that lives 5 minutes and 2× for one that lives an hour.

Put the whole ladder together, the four input prices plus output, for Opus 5 (since superseded by Opus 5.5, but the model most of the census below ran on, and the rate I priced all of it at), per million tokens:

The bottom two rungs depend on how you structure a turn. Wording doesn't move them. Send a prefix fresh and it's $5 per million; read it from cache and it's $0.50. That 10× is under your control. The write premium above them pays for cache lifetime, once, so the reads stay cheap, and that turns out to be a choice too. $25 at the top is the model writing the text. Bottom to top is 50×, and on Opus 5.5 the cache-read rung drops to $0.20, so the spread is 100×.

Where the cost would have gone

I looked at mine. I parsed every transcript this project has produced in Claude Code (Anthropic's command-line coding agent), de-duplicated the API responses (each response repeats its usage counts on several lines, so a naive sum inflates the totals), and summed the four counters the API reports on every request: input, cache write, cache read, output. 7,426 requests, 1.55 billion tokens, counted on August 12, 2026. Measured in my setup, one person's agent-heavy workload, not a benchmark. I ran this on a subscription, so the dollars are what the same work would have cost on the API at Opus 5 list rates, not an invoice. The shares depend on the model: Opus 5.5 and Fable 5.1 cut the cache-read rate, so at Opus 5.5 rates output is 22% and the two cache slots 78%.

Cache writes are 2.46% of tokens and more than a quarter of the money, because every write in the parent transcripts used the 1-hour cache at its 2× rate, which I checked in the transcripts. And fresh, full-price input, the thing the pricing page leads with, barely exists.

Output has three different shares depending on what you count, and only one is about money. Output is 0.55% of raw tokens. It's 3.6% on the metric my own tooling used, which weights each input slot by its price multiplier but counts output at 1×. And it's 15.8% of cost.

The formula was built to compare cache traffic before and after a change. Correct for its original job, where output is roughly constant on both sides and the weight cancels. Reused as a cost decomposition, it understated output's share of spend by more than a factor of four, and I only caught it while building this census.

Cache reads dominated mine because an agent re-sends its entire history every turn. I wrote that mechanism up in The Context Tax. I've seen the same mechanism at its worst in a different system: a single Jira (ticket tracker) query for five rows of tickets returned about 22 KB of JSON, and our orchestrator, the long-lived agent driving the work, re-read it on every status check for the rest of the session (observed in our setup, not a controlled benchmark).

Short of moving to a model with a cheaper cache-read rate (Opus 5.5 charges 60% less per read), the only setting that changes a cache slot's price is the write rate, and it applies to about a third of them at Opus 5 rates (half at Opus 5.5's). Every cache write in my corpus paid the 1-hour rate at 2× input, and the 5-minute cache does the same job at 1.25×. Had those writes gone short, that slot would have cost 37.5% less, about 11% off the total at Opus 5 rates (about 15% at Opus 5.5's), for an API user who opted into the 1-hour cache. That's the best case. It assumes every read still hits, and a five-minute cache is exactly the thing that stops hitting when a turn runs long.

I had taken it for granted that the cache lifetime wasn't mine to set. Claude Code picks it by default from how you sign in, and CLAUDE_CODE_PROMPT_CACHE_TTL sets it outright. On a subscription, the main conversation gets the 1-hour cache while you're inside your plan's usage; an API key defaults to five minutes; FORCE_PROMPT_CACHING_5M=1 forces five minutes regardless. My census prices subscription traffic at API rates, so the 1-hour default accounts for about 11 of those 28 points of the bill at Opus 5 rates, from a default I never went looking for. On a subscription, that saving, if any, shows up as usage headroom.

The read slot is harder. At Opus 5 rates it's the majority of the bill (at Opus 5.5's, about 39%, level with writes), and no setting changes its rate on a given model. Cache reads shrink only when you carry less history per turn, which is architectural, and which is why it got its own post. Hand back conclusions instead of payloads, and let a subagent (a separate run with its own throwaway context) do the big reads.

Two limits. The count is exact for what it covers but not exhaustive. It misses subagent traffic, which doesn't land in the parent transcript at all, and a subagent starts from an empty context and writes its whole prefix into cache from scratch, so the cache-write share above is probably a floor. And a chat product with short prompts and long answers could easily be output-dominated. Which slot dominates is a property of your workload, and you don't know yours until you decompose it.

What to do on Monday

1. Count with count_tokens, not an estimator. Characters-divided-by-four undercounts Claude 4.7 and later by nearly 40%, per Anthropic's averages; the real count runs about 60% higher. The endpoint is free.
2. Decompose before you optimize, and weight output at 5× when the question is money. Every API response reports its four counters. Sum each across a week, multiply by the slot's price, and look at the result before touching anything. My instinct said shorten the output. My table said 16% (22% at Opus 5.5).
3. Know which cache lifetime you're on. If your turns land inside five minutes, the 5-minute cache writes at 1.25× instead of 2×. On an API key you're already on five minutes unless you opted into an hour; if you did, check that your turns actually need it. On a subscription, shortening it may free usage headroom, and only if your reads still land inside five minutes. In Claude Code, CLAUDE_CODE_PROMPT_CACHE_TTL sets it outright.

Next in the series: why the top rung is where the model's strangest behavior comes from.

Price the slot, not the text.

FAQ

How many tokens is a word?
There is no fixed answer; the count depends on the model's tokenizer. Per Anthropic's published approximations (as of September 2026), Claude 4.7 and later average about 1.8 tokens per English word (about 2.5 characters per token), while the generation before averaged about 1.3. For an exact count, call the count_tokens endpoint with the model you'll actually use.

Is output five times more expensive to produce, or is that a markup?
Some of each. Producing output is a different operation. Prefill reads your whole prompt in one parallel pass, while every output token needs its own sequential pass that re-reads the model's weights out of memory. Published roofline analysis (Yuan et al., 2024) puts the compute-bound layers of prefill above 1,000 operations per byte of memory traffic and decode at about 1, for one request at a time. Batching likely recovers much of that gap in practice, so the exact 5× that holds on every current Claude model is best read as a pricing convention tracking a real physical asymmetry, not as a measurement of it.

Should I shorten prompts or outputs to cut my AI bill?
Decompose your bill by slot first. In my measured workload (1.55B tokens of Claude Code transcripts, August 2026, priced at Opus 5 rates), output was 15.8% of cost while the two cache slots were 84%, so shortening output would have attacked a sixth of the bill. That's one workload's answer.