Traditional software has a comforting cost structure. You build it once, and each additional user costs almost nothing to serve: the marginal cost of one more login is effectively zero. That near-zero marginal cost is the reason software companies scale to high gross margins, and it shaped how finance thinks about product economics for a generation. Generative AI features do not work that way. Every time a user invokes an AI feature, it makes a model call that costs real money, so the product now has a cost of goods sold that scales directly with usage.
This is the shift finance has to internalize before it can govern AI spend. The question is no longer only “what did it cost to build?” but “what does it cost every time someone uses it, and is that less than what the use is worth?” That is a unit-economics question, and it is one finance has always known how to answer for physical products; it simply has not had to ask it of software before. The teams that thrive with AI are the ones that started asking it early, because the alternative is discovering the answer after a feature has scaled to a margin-destroying volume.
What goes into the cost of an AI feature
To build unit economics you first need an honest number for what one use of a feature costs to serve. For a generative AI feature, that cost of goods is more than the headline model price. It is the sum of the input tokens sent (the prompt, the conversation history, and any retrieved context), the output tokens generated, and, for reasoning models, the internal reasoning tokens billed but never shown. If the feature uses retrieval, add the cost of the embedding calls and the vector database queries that support it. If it runs as an agent, add every step in the loop, not just the first call.
Two properties of this cost make it easy to underestimate. First, the expensive half is usually the output, which is priced several times higher than input across the major providers, so a feature that generates long responses costs far more than its request count suggests. Second, context is re-billed on every turn because the APIs are stateless: a multi-turn feature pays repeatedly to re-send its own history. A realistic per-use cost has to be measured from actual token telemetry, not estimated from a single happy-path example, because the average real conversation is longer and heavier than the demo.
The encouraging half of the picture is that this cost is falling. Stanford’s AI Index has documented the price of a fixed level of model capability dropping by more than one hundredfold in roughly eighteen months, as providers release cheaper models and cut prices. A feature that is margin-negative at today’s prices may be comfortably profitable in a year without any change to the code. But that is a reason to measure and monitor unit cost over time, not a reason to ignore it, because usage typically grows faster than price falls, so the total you must cover keeps climbing even as each call gets cheaper.
Cost is only half the ratio
Unit economics is a comparison, and the cost side is the easy half. The hard half is putting a defensible number on the value each use delivers, because that is what tells you whether the feature should exist at its current price. The right value measure depends on how the feature earns.
For a feature customers pay for directly, the value is revenue attributable to it: the price of the tier it unlocks, or the incremental subscriptions it drives. Here the discipline is straightforward: if a feature is included in a flat-price plan but its per-use cost scales with heavy users, a small number of power users can turn a profitable plan margin-negative. Finance should look at the distribution of usage, not the average, and specifically at whether the heaviest users are covered by what they pay. Flat pricing on top of metered costs is a known way to lose money on your best customers.
For an internal feature, an AI tool that makes employees more productive rather than one customers buy, the value is the labor time it saves, valued at loaded cost, minus the time people spend supervising and correcting it. This is the same framing that applies to any productivity tool, including the one many finance teams have already had to evaluate: a per-seat AI assistant is only worth its price if the hours it saves, net of oversight, exceed the subscription. The measurement is harder than revenue attribution, but the principle is identical: value has to be estimated, not assumed, and a feature that saves ten minutes a week for a handful of people does not justify a cost that scales with an entire organization’s usage.
The pricing trap finance should watch for
The most dangerous structure in AI product economics is the mismatch between how you charge and how you are charged. If a company pays its model provider per token but charges its own customers per seat or per flat monthly fee, then its cost is variable while its revenue is fixed. Usage growth, normally the best news a software business can get, becomes a margin problem, because every additional interaction adds cost without adding revenue.
This is not hypothetical. As AI features have scaled, the industry conversation has shifted noticeably toward usage-based and hybrid pricing precisely because flat pricing over metered costs does not hold up. The finance response is not necessarily to reprice everything to pure consumption (flat pricing has real commercial advantages), but to know the exposure. That means modeling the heaviest plausible users against the plan they are on, setting fair-use limits where a small cohort could break the economics, and building the pricing with the cost of goods in view rather than discovering the mismatch after launch.
Making it an operating discipline
Unit economics for AI is not a one-time analysis to run before launch and file away. Model prices change, usage patterns shift, features get more capable and more heavily used, and the cheaper models that make a feature profitable arrive on their own schedule. The organizations that keep AI features margin-positive treat it as an ongoing measurement, and a few practices make that possible.
Instrument cost per use from day one. Attribute token spend to individual features so you can compute a real, current cost per use rather than a stale estimate. A feature whose cost you cannot isolate is a feature whose economics you cannot manage. The same allocation discipline that makes a cloud bill legible is what makes AI margins legible.
Track the ratio, not just the cost. The number that matters is value per use over cost per use. Cost falling is good; cost falling while value per use falls faster is not. Reviewing both sides together keeps the conversation about whether the feature earns its keep, rather than only about cutting spend.
Watch the distribution. Averages hide the users and the runs that break the economics. The heaviest tenth of usage is where margin-negative features reveal themselves, and it is where the levers, fair-use caps, tier design, and model routing for the expensive cases, actually apply.
The question “does this AI feature pay for itself?” is answerable. It just requires finance to bring the unit-economics thinking it already uses for products with real marginal costs to a category of software that used to have none. The teams that ask it early ship AI that scales profitably. The teams that ask it late find out from the invoice.
CostDefender attributes AI and cloud spend to the features that generate it, so finance can build unit economics on measured cost, not estimates, and verify that every optimization reaches the bottom line. See how it works →