The Unit Economics of a Feature

The Unit Economics of a Feature is the arithmetic that decides whether the thing you have built can exist at the volume you want. It is not the price of a model call. It is the fully loaded cost of getting one user to one acceptable outcome, including the attempts that failed, the minutes a human spent checking, and the cleanup after the ones that got through wrong.

Key takeaways

• Cost per call is the wrong denominator. Users buy outcomes, so the unit is cost per successful interaction, where success means the user got something they accepted.
• The number has five lines: generation, support calls such as embeddings and checks, retries and rework, human time, and the residue of failures that reached a user.
• Human review is usually the largest line and the one nobody puts in the model, because it is paid in salary rather than in API spend and lands on a different budget.
• Epoch AI's March 2025 analysis found inference prices falling steeply but unequally, and a measured past decline is not a forecast. A feature whose economics work only at next year's prices has no economics today.
• Every feature needs a ceiling with an alarm and a defined behaviour at the ceiling, because unbounded per-interaction cost plus unbounded volume is how a bill becomes an incident.

Read this after Chapter 6, which produced the routing table this chapter prices, and before Chapter 8, which spends a different scarce resource on the same interaction. Chapter 12 uses this number as one of the signals for cutting a feature.

The finance business partner asks what the AI feature costs per customer. The team quotes a token price and multiplies by an average request.

The number they give is under a penny. Everyone relaxes.

Four months later the same feature is the third largest line in the cloud bill, and the operations lead has hired two people whose job is checking its output. Neither of those facts appeared in the original arithmetic, because the original arithmetic counted one call on the happy path.

Cost per call is the wrong denominator

The mistake is not underestimating the price of a token. It is choosing a unit that does not correspond to anything a user wants.

A user does not want a model call. They want an invoice posted, a reply sent, a document classified correctly. Between the request and that outcome there may be one call or nine, a retrieval step, two verification checks, a retry after a failed check, an abandonment and a second attempt, and a human glance.

Counting calls also creates a perverse incentive. A team optimising cost per call will cheerfully move to a cheaper model that needs two attempts to get one usable answer, and report a saving. The dashboard improves. The bill does not.

There is a second reason the denominator matters. Cost per successful interaction is comparable to the value of the interaction, which is the only comparison that decides whether a feature should exist. Cost per call is comparable to nothing.

Cost per successful interaction is the number to hold

The definition needs to be tight enough that two people computing it get the same answer.

Cost per successful interaction is the total cost of everything the system and the organisation spent, over a period, divided by the number of interactions in that period where the user received an output they accepted. Accepted means committed, sent, saved or acted on. Not generated.

Two boundary rules keep it honest. Failed interactions do not get their own denominator, so their cost lands on the successes, which is the point: a feature that succeeds half the time costs twice what its happy path suggests. And abandoned interactions count as failures, because the user paid for the wait and got nothing.

That is the whole definition. It fits in a sentence and almost nobody computes it.

The five lines a real interaction has

Working through the lines in order stops the estimate collapsing back to a token price.

Generation is the first and usually the smallest: prompt tokens plus output tokens for the calls on the intended path, at the prices you are actually charged, on the models the routing table selects. For retrieval-heavy features the prompt side dominates.

Support calls are the second. Embeddings for retrieval, the vector search itself, a reranking pass, a guardrail classifier, a verification call against a second model. These are individually cheap and collectively often larger than generation, because there are several per interaction and they run whether or not the interaction succeeds.

Retries and rework are the third. Any attempt that did not produce an accepted output still cost money, so this line is where a low success rate converts into a high unit cost.

Human time is the fourth, and it is the one measured in minutes rather than tokens. Review of a draft, correction of a field, handling of an escalation from Chapter 5. Convert it at a loaded hourly rate and put it in the same table as the tokens, because a decision made on tokens alone will always choose the option that shifts work onto people.

Failure residue is the fifth. What the failures that reached a user cost: the reversal, the support conversation, the compensating action, occasionally the credit. This is the hardest line to estimate and the one that makes the difference between a feature that is cheap and a feature that is cheap to run.

A worksheet you can fill in this afternoon

Written as a table, the estimate becomes something a finance partner can argue with, which is the goal.

Two habits make the worksheet useful rather than decorative. Fill it in per action rather than per feature, because the classification step and the drafting step have wildly different profiles and averaging them hides both. And date it, next to the prices you used, so that next quarter's version is a comparison rather than a fresh guess.

Retries and failures are the line nobody models

This line deserves its own section because it is where the arithmetic changes by a factor rather than a percentage.

Suppose a step succeeds seventy per cent of the time and you retry once on failure, with the retry succeeding at the same rate. You now pay for 1.3 attempts per interaction, and roughly nine per cent of interactions still fail after both. Those nine per cent consumed two attempts and produced nothing, so their cost lands on the ninety-one that worked.

The compounding across a pipeline is the part that surprises people. Four steps at ninety-five per cent each give you about eighty-one per cent end to end, and the failures do not distribute evenly across the cheap steps. A failure at step four has already paid for steps one through three.

That is the arithmetic case for cheap checks early. A verification that costs a hundredth of the generation and catches a bad input before three expensive steps run is not a quality feature, it is a cost feature.

This is also where a ceiling belongs. Every feature needs a per-tenant and per-period spend cap, an alarm well below it, and a defined behaviour on reaching it, which is normally the degraded state from Chapter 6 rather than an error. Unbounded cost per interaction multiplied by unbounded volume is how a bill becomes an incident.

Review is a cost in a currency you cannot buy more of

Human review is the line most likely to be missing and the line most likely to dominate, and it behaves differently from every other line in the table.

Compute is elastic. You can buy ten times more of it this afternoon at roughly ten times the price. Attention is not: a reviewer capable of judging your output has to be recruited, trained and retained, and doubling the review capacity is a quarter of work rather than a configuration change.

So a drafting feature has two unit costs, one in currency and one in minutes, and the second one sets the ceiling on volume. Chapter 3 made this point about interaction shape. This chapter is where you put a number on it, and the number is usually uncomfortable.

The practical consequence is that reducing review time per item is worth more than reducing token cost per item, in most features I have looked at. Shortening the thing a reviewer has to check, linking each claim to its source so verification is a glance, and batching related items into one pass all attack the expensive line.

Falling prices are a measured past, not a budget

The standard rebuttal to any cost concern is that inference is getting cheaper, and the data behind that rebuttal is real and needs quoting precisely.

Epoch AI's analysis of LLM inference price trends, published on 12 March 2025, found that the price of reaching a given capability milestone fell by between 9x and 900x per year depending on the milestone, with a median of about 50x per year. Reaching GPT-4's level on GPQA Diamond fell about 40x per year. For milestones first reached after January 2024, the median was around 200x per year. Their benchmarks were MMLU, GPQA Diamond, MATH-500, MATH Level 5, HumanEval and Chatbot Arena Elo, with pricing from Artificial Analysis and Epoch's own database.

Read the caveat as carefully as the headline. Epoch notes that the fastest declines in that range occurred in the most recent year, so it is less clear those will persist. That is a measurement over a past window, not a forecast, and it was measured in March 2025.

Two things follow for a budget. A feature whose economics work only at next year's prices has no economics today, because the decline is not contractual and your finance plan is. And the decline is per capability milestone rather than per model, so you capture it by moving a step down to a cheaper model that has since become good enough. That is a routing change somebody has to make. It does not arrive on its own.

An arXiv position paper published in June 2025 argues that small language models are more economical for the repetitive specialised invocations agentic systems mostly make. Take that as a reason to revisit the routing table quarterly.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact. The prices are assumptions for the arithmetic, not quoted figures.

A contract review feature retrieves clauses, summarises risk, and a lawyer approves the summary. Assume generation costs four pence per interaction and support calls two pence. The team quoted six pence.

The loaded number is different. Retrieval quality means roughly one interaction in five is retried, adding a little over a penny. About eight per cent are abandoned by the lawyer as not useful, and their cost lands on the successes. Review takes six minutes at a loaded rate of sixty pounds an hour, which is six pounds. And one summary in fifty gets a correction after approval, costing about twenty minutes of somebody's time.

Cost per successful interaction is therefore a little over six pounds and eighty pence, of which the model is roughly one per cent. Every cost conversation the team had been having was about the one per cent.

The decisions that followed were all about review. Every risk claim now links to the clause it came from, which cut checking time. Summaries are capped in length. Low-value contract types skip the feature entirely. None of that involved changing the model, and it moved the number more than any model change could have.

The objection: nobody models cost per interaction for a database query

The objection is fair as an observation about ordinary software and wrong as a conclusion.

Nobody models the unit cost of a database query because it sits orders of magnitude below the value of the interaction, it does not vary by input, and it does not consume human attention. A model call fails all three tests. It can be a material fraction of the revenue on a transaction, its cost varies with input length and retry count, and it frequently drags a person's minutes along behind it.

The closer analogy is outbound telephony, payment processing or physical shipping, all of which product teams model per transaction as a matter of course. Nobody finds that strange. The cost is visible, variable and attached to the unit of value.

Where the objection has force is in proportionality. A feature used forty times a day needs a rough number and a spend alarm rather than a worksheet. The worksheet earns its keep at volume, and writing it early matters because the volume decision gets made before anyone has looked.

Chapter summary

Cost per call is the wrong denominator because a user buys an outcome rather than a call, and a team optimising per call will happily adopt a cheaper model needing two attempts and report a saving the bill never shows. The unit is cost per successful interaction: everything spent over a period divided by the interactions where the user accepted an output, with accepted meaning committed, sent, saved or acted on, and with failed and abandoned interactions loading their cost onto the successes rather than earning their own denominator. Five lines make it up. Generation, meaning prompt and output tokens on the intended path. Support calls, meaning embeddings, search, reranking, guardrails and verification, which are individually cheap, collectively often larger than generation, and charged on failures too. Retries and rework, which is where a low success rate converts into a high unit cost, since four steps at ninety-five per cent give about eighty-one per cent end to end and a late failure has already paid for the early steps. Human time, converted at a loaded hourly rate so that decisions made on tokens alone stop shifting work onto people. And failure residue, meaning reversals, support contacts and compensation. Review is the line that usually dominates and the one paid in a currency you cannot buy elastically, so shortening what a reviewer must check is generally worth more than cheaper tokens. Epoch AI's March 2025 analysis found capability milestones getting cheaper by between 9x and 900x per year, median around 50x, with the caveat that the fastest declines are recent and may not persist, which makes it a measured past rather than a budget line. And every feature needs a spend ceiling, an alarm below it, and a degraded behaviour at it.

Money is one scarce resource per interaction. Time is the other, and users notice it directly rather than at the end of the quarter. Chapter 8 is Latency Budgets and Perceived Speed.