Token economics

Read these first

• Tokenization

What you will know

• Record the current input and output price of a model you use, per million tokens

  Prices vary by model, provider, cached-input policy, and billing tier, so a stale number can invalidate an otherwise correct estimate.

• Calculate the cost of a single request before sending it

  Include both the measured prompt size and a bounded completion budget; uncapped generation makes the estimate optimistic.

• Measure input and output token spend across a representative agent trace and identify which turns drive the bill

  Long tool results, repeated context, and verbose intermediate responses can outweigh the final answer even when one completion looks cheap.

• Estimate the monthly cost of a feature from its expected traffic

  Use request volume, retries, failure paths, concurrency assumptions, and token distributions rather than only an average happy-path request.

• Run the same prose and a representative code sample through the target tokenizer, compare token counts, and account for the difference

  Whitespace, punctuation, identifiers, and non-English scripts can fragment differently, changing both context limits and billed usage.

Chapters

1. 1

   Input and output token prices

   Hosted chat models bill the prompt and the completion at different rates, with output typically three to five times the input price, because prefill is a compute-bound pass over the whole sequence and decode is a memory-bound loop that produces one token at a time. This chapter works the arithmetic on two features whose costs invert the intuition, sets out the price note to keep in code — ratios, cached-input rates, batch tiers, billing tier, a pinned model version and a date — and marks where the ratio stops predicting anything about your bill.

   Read chapter
2. 2

   Token cost of a single request

   Cost per request is prompt tokens times the input price plus completion tokens times the output price, and the two terms are obtained differently: the prompt is a string you hold, so its token count is a measurement, while the completion does not exist yet and can only be bounded by a maximum output setting. This chapter works the arithmetic, gives the price grid for prompt and completion sizes you are likely to send, and shows how to choose a cap from a logged distribution, handle truncation, and avoid the retry configuration that costs more than no cap at all.

   Read chapter
3. 3

   Reasoning models and thinking tokens

   A reasoning model generates an internal chain of intermediate tokens before it writes the answer. Those tokens are billed at the output rate and usually stripped from the response, so a request whose prompt and visible answer are unchanged can cost eleven times as much across effort settings. This chapter shows where they appear in the usage block, why a maximum output setting does not bound them the way you expect, how to price them from sampled traffic rather than from answer length, and where cost per request is the wrong comparison to make.

   Read chapter
4. 4

   Token ratios by content class

   Five hundred words of Python does not cost what five hundred words of English costs: indentation, punctuation clusters, split identifiers and repeated syntax fragment into more pieces, and a script the vocabulary covers poorly fragments further still. This chapter measures characters per token for six content classes, converts each into a price per thousand requests and a context-window capacity, gives the ten-line measurement and the continuous-integration guard that stops the ratio drifting, and separates the repairs that work from the ones that look like they should.

   Read chapter
5. 5

   Stateless APIs and conversation history

   A model API holds no session: the conversation is an array your client owns, and every call sends the whole of it — system prompt, tool definitions, every earlier user and assistant turn, and every tool result those turns produced. The same tokens are therefore billed again on each turn, which is why a multi-turn feature's bill is dominated by input rather than by the answers it writes. This chapter traces one conversation's usage, itemises the four components estimates routinely omit, and separates the changes that reduce those tokens from the ones that only move where they are stored.

   Read chapter
6. 6

   Quadratic input growth in agent loops

   An agent resends the whole conversation on every call, so a base prompt is billed once per turn while appended tool results accumulate underneath it — total input is n·P + Δ·n(n−1)/2, which is quadratic in turn count. This chapter works the arithmetic against the naive multiple, gives the per-call usage log that turns a stream of requests into a trace grouped by conversation, reads a real twelve-turn coding-agent run where one early file read is 37 percent of the bill, and ranks the available interventions by which term they act on.

   Read chapter
7. 7

   Prompt caching and prefix stability

   Cached input bills at roughly a tenth of fresh input, and the discount is earned by a byte-identical prefix matched from the first token forward. Any volatile byte that sits early — a timestamp, a request ID, tools serialised from an unordered collection, a per-user string — invalidates everything after it silently. This chapter prices a real agent run with and without the discount, lists the prefix-breakers in order of how often they occur, gives the assembly order and the cross-process test that catches them, and marks the workloads caching cannot help.

   Read chapter
8. 8

   Forecasting monthly spend

   Multiplying a representative request by expected volume is the standard way to underestimate a feature, because a user action is a branching process rather than one call: guard classifiers, schema-validation retries, timeouts that bill for partial generations, rate-limit retries and user-initiated regenerates all add expected cost. This chapter builds the forecast as a request tree with measured branch probabilities, shows why the mean of a skewed cost distribution is the number to use, prices the batch tier and the adoption ramp, and separates a forecast from the controls that bound spend.

   Read chapter
9. 9

   Diagnosing a production cost trace

   Cost per request is already normalised for volume, so more traffic cannot explain a jump from $0.02 in staging to $0.31 in production. Three candidates account for nearly every occurrence: real inputs far larger than fixtures, loops running more turns before they terminate, and a prompt cache that hits in staging and misses in production. This chapter gives each one's signature in a per-call usage log, the query that reads all three from one trace, the denominator checks worth doing first, and the replay harness that makes the comparison possible next time.

   Read chapter
10. 10

    Pricing from a usage distribution

    Token usage per user is heavy-tailed: the mean sits near the 88th percentile, the top one percent of users can be a third of spend, and half the seats cost under fifty cents a month. This chapter computes the distribution from a usage log, compares three pricing structures by what each one is exposed to, shows why the per-account distribution matters more than the per-seat one, and sets out what to hand a finance team — a shape, a price anchored near a high percentile, a bound, and an explicit note about which half of the estimate is a guess.

    Read chapter