The economics of a prediction

The shape of the bill. Cost equals requests times cost per request, and cost per request equals input tokens times the input price plus output tokens times the output price, both per million. Nothing in that expression is paid when no request arrives. Economists call a cost with that property purely variable, and a cost per additional unit a marginal cost; here the two are the same number, c, and c does not change with volume until a volume discount is negotiated, which the public list does not carry.

Why the output price matters more than it looks. Output tokens are priced five times the input tokens on every one of the three models named tonight: 25 against 5, 10 against 2, 5 against 1. A request that reads 1,200 tokens and writes 300 pays more for the 300 than for the 1,200. A feature that writes long answers is a dear feature even if it reads almost nothing, and that is visible only if you split the request into its two token counts before pricing it.

The date on the list. The prices above are list prices as published on 25 September 2026. They have moved before and will move again; the map that feeds these pages records that Claude Sonnet 5's price was introductory earlier in the year and is now standard. Every cost you compute from a list carries the list's date, and a break-even computed on a stale list is a stale break-even.

Shapiro and Varian 1998, Information Rules, is the reported source of the modern version: an information good is expensive to produce and cheap to reproduce, so its cost structure is almost all fixed, competition drives the price toward the near-zero marginal cost, and the only defence is to differentiate, version, and lock in. Software companies built their margins on that sentence for three decades: the thousandth user of a spreadsheet costs the vendor a few cents of bandwidth.

Inference breaks the sentence at the word reproduce. A prediction is not reproduced; it is produced, every time, from tokens through a model on hardware that draws power. The thousandth request costs as much as the first. The fixed cost of training is still enormous, so the story is half right, but the half that is wrong is the half a finance team lives in: a cost of goods sold line that rises with usage, and a gross margin that can fall as the product succeeds. Software margins assumed volume was free. Inference margins have to be earned per request.

The three bills. 27,000, 10,800 and 5,400 dollars a month for the same constructed 2,000,000 requests, a factor of five between the dearest and the cheapest. That factor is the reason model choice is a cost decision before it is a quality decision: if the cheaper model does the job as well on your evaluation set, the difference is margin. If it does not, the difference is the price of quality, and it is now a number rather than a feeling.

What the bill is not. It is not the cost of the feature. It is the marginal cost of the feature's requests. The engineers who built it, the evaluation harness, the on-call, the retrieval index the requests read from: all of those are fixed costs that the API bill does not carry and that an honest cost per request has to be spread over the volume, which is the utilisation question of Part 3.

Where the workload came from. It is invented. Real workloads have a distribution of input and output lengths, not a point, and the mean of a distribution is what the bill charges; a tail of long conversations can dominate. The first thing to do with a real product is to pull the token counts from the logs and replace the two constants with two means and two 95th percentiles.

Caching. Cache reads are listed at about a tenth of the input price. If 1,000 of the 1,200 input tokens are a system prompt and a shared context that every request repeats, a constructed share and a plausible one, the input cost of a Claude Opus 5 request falls from 0.006 to 0.001 for the 200 fresh tokens plus 0.0005 for the 1,000 cached, 0.0015 in total, and the request from 0.0135 to 0.009. Over the constructed month that is 18,000 instead of 27,000. The list also prices cache writes; add that line from the list before you count the saving. Caching is the rare cost lever that cuts c itself rather than N.

Latency. A request that takes four seconds instead of one is not dearer on the bill, and it is dearer to the business: a user who waits leaves, an agent that waits blocks the request behind it, a batch that waits ties up the machine. Latency is a cost with no line on the invoice, which is why it needs its own number, measured, next to c. The two trade against each other: a smaller model is cheaper and faster, a cached prefix is cheaper and faster, a longer output is dearer and slower. When a lever moves both the same way it is not a trade-off, and those are the levers to pull first.

The division. Rent costs c times N a month; own costs F. Set them equal and N star is F over c. With c at 0.0135 for Claude Opus 5 at the list prices and an invented F of 40,000 dollars a month, N star is 40,000 over 0.0135, about 2,962,963 requests a month. The constructed workload is 2,000,000, under N star, so on those numbers renting Opus 5 at 27,000 a month beats owning at 40,000. Raise the volume past 2.96 million and the flat line wins; halve F to 20,000 and N star halves to about 1,481,481, which the workload clears.

Why F is a slider and not a number. The fixed cost of owning depends on hardware you have not priced, a hosting contract you have not signed, an on-call rota you have not staffed, and a utilisation you have not measured. Any single figure would be a guess dressed as a fact. So the page carries none. It varies F across a range and shows the break-even as a function of it, and the honest output is a table, not a point: at F of 20,000, 40,000 and 80,000, N star for Opus 5 is about 1.48, 2.96 and 5.93 million requests a month. Your F comes from your quotes, and the division is the same.

The cheaper model moves the break-even the other way. Renting Claude Haiku 4.5 costs 0.0027 a request, so N star at F of 40,000 is about 14.8 million requests a month. The cheaper the rented model, the more volume owning needs to justify itself. If a smaller model passes your evaluation, owning is usually not the next question; it is the answer to a question you no longer have.

Capacity. A flat F is flat until the box is full. Past its capacity a second box is needed and F steps up, so the own line is a staircase, not a line, and the break-even arithmetic holds only on the first step. If your volume sits just past N star, the first extra step can put you back on the rent side.

Peak against mean. Owning has to be sized for the busiest hour, not the average one; renting charges the average. A workload with a sharp daily peak needs a bigger box than its monthly mean suggests, which raises F and moves N star out. The quantity that decides this is the ratio of peak to mean load, and it is measurable from a week of logs.

The people. Hardware is the visible part of F. The team that patches, upgrades, monitors and answers the pager at three in the morning is the part that is left out of a quote and turns up in the salary line. Put it in F before the division, or the break-even is a marketing number.