The model catalog and prices are the most volatile part of any book about such a product, and it is most honest to say so directly. What matters here is not the specific numbers but how billing works: how cost is computed, what it is made of and what makes the same request more or less expensive. Those rules change slowly, unlike the figures themselves, and knowing the rules outlives several generations of the price list.
Cost is usually quoted per million tokens and split across several columns: input tokens, writing to the cache, reading from the cache and output tokens. That structure is useful in itself: it explains why a long context grows more expensive faster than the task grows and why a repeat call over the same material costs less than the first. Understanding the structure, you can read any price list even if its numbers differ, and you see at once which column governs your scenario.
The cache deserves separate examination, because its economics do not reduce to the word cheaper. A write costs more than ordinary input, a read an order of magnitude less. So the cache has a break-even point: it wins when the same material is used many times and loses on a single call, where you pay the write premium and get not one cheap read. From which follows a practical consequence: a long coherent session over the same code saves money, while a dozen scattered short requests across different files does not.
Models with an extended context are noted separately. Most often the extended window costs the same per token with no long-context surcharge; on part of the catalog input beyond the threshold is billed at double, and for individual models the base rate itself is raised. That matters more than it seems: a task that accidentally crossed the boundary costs fundamentally differently from the same task that stayed inside it, and the difference appears as a jump rather than gradually. Which is why the discipline of a narrow context is about money as well as about the quality of the answer.
| Component | What it means | What to do about it |
|---|---|---|
| Input tokens | Everything sent in the request: context, files, history | Keeping the context narrow is both quality and money |
| Cache write |
| The first storing of material for reuse |
| Justified when the same material is used repeatedly |
| Cache read | A repeat call over what is already stored | Cheaper than input tokens; long coherent work benefits |
|---|
| Output tokens | Everything the model wrote in reply | Long reports cost money; ask for a compact summary |
|---|
| Extended context | Models with an enlarged window | A higher base rate and a possible multiplier beyond a threshold |
|---|
| Model footnotes | Hidden by default, a reasoning variant, doubling beyond a threshold | They determine the bill rather than the table's heading |
|---|
There is a class of notes that is easy to skip: a model hidden by default, a variant with extended reasoning counted differently, cost doubling beyond a threshold, a temporary promotion on some models. It is exactly those footnotes that determine the actual bill rather than the table's heading. When choosing a model for regular automation, they are what to read first: a one-off experiment survives any footnote, whereas a daily run multiplies it by the number of invocations.
It is also important to understand that a price table is not a bill. The actual amount is changed by plan credits, discounts, the mode of work and which model ultimately served the request under automatic routing. Two people with the same model name in the interface can pay differently, and the difference is explained not by the price per million tokens but by the terms of their subscriptions. So the only reliable source about your expenses is your own usage accounting rather than a public table.
The practical conclusion for planning: a budget is computed not from the price per million tokens but from the cost of a typical task. Take a dozen real runs, look at the actual usage of each and multiply by the expected frequency. Such a calculation survives price changes and gives a clear unit for a conversation with finance - the cost of reviewing one change rather than abstract tokens.
And the main rule for working with this reference: before a budget or procurement decision, open the live pricing page and the current catalog in your account. The numbers in a book are a dated snapshot useful for understanding the structure and the orders of magnitude. They cannot be leaned on for expense planning, and the book does not claim otherwise.
The engineering conclusion is simple: understand the mechanics of billing and verify the numbers. Then a price change stops being a surprise: you know which of your scenarios are sensitive to input tokens, which to output ones and where the cache saves you. The same knowledge answers the question of what to do when the bill grows: look not for a cheaper model but for the component that grew.
The typical failures are predictable. Planning a budget from the price per million tokens instead of the cost of a typical task. Skipping the footnote about doubling beyond a context threshold. Treating the cache as always profitable and paying for writes where no read will follow. Taking a public table for a bill without looking at your own usage accounting. Hard-coding a model into automation from yesterday's snapshot. And comparing models by price without comparing them by result on the same set of tasks.