Unit Economics of an AI Feature

Software companies are used to a marginal cost of approximately zero. A feature with inference in it has a real, per-use, variable cost, and that turns gross margin from a constant into a function of how much each customer uses the product.

What belongs in cost of goods

Gross margin is revenue minus the cost of serving that revenue, divided by revenue. The discipline is in deciding what counts as variable. For an AI feature the honest list is longer than “tokens”:

• Inference — the model calls themselves, including retries, verification passes and the failed attempts you paid for.
• Embeddings — at ingest and on any re-embedding.
• Vector storage and query — priced per GB-month and frequently per query, and it grows with the customer’s corpus rather than with their usage.
• Log, trace and artefact storage — request and response bodies are large and are kept for support and evaluation.
• Moderation, safety and PII scanning — a per-request cost sitting on both sides of the model call.
• Human review — if any share of output is checked by a person, that is by far the most expensive line here and it belongs in COGS, not in operating expenses.

Everything on that list is enumerated more carefully in the hidden-costs inventory. Leaving them out is how a feature reports a 95% margin and delivers a 70% one.

Margin is a distribution

The standard mistake is computing margin for the average user. Usage is heavy-tailed, so the average user is a fiction and the interesting behaviour is at the top of the distribution. Compute it at three points instead.

With assumed figures — a $20/month plan, $0.012 per request, and non-inference variable costs scaling roughly with usage:

                requests   inference   other    total   margin
median  (p50)         60      $0.72     $0.15    $0.87    95.7%
heavy   (p90)        400      $4.80     $0.60    $5.40    73.0%
extreme (p99)      3,000     $36.00     $2.00   $38.00   -90.0%

margin = (20.00 - total) / 20.00

The p99 user costs nearly twice what they pay. That is not a rounding error and it is not visible in any average. It is also not necessarily a problem yet — the question is how many of them there are and whether that share is growing.

There is a second reason to look at the tail specifically, which is that it is the part of the distribution an adversary controls. A negative-margin user who arrived organically is a pricing question; a negative-margin user who arrived because your free trial is a convenient way to get inference is an abuse question, and the two need different responses. Look at whether the extreme profile correlates with anything — signup age, payment method, a single integration — before deciding it is a product design problem.

The blended number, and what it hides

Blended margin is total revenue minus total cost over total revenue. Continuing the same assumed example with 1,000 subscribers distributed 900 / 90 / 10 across the three profiles:

revenue = 1,000 * 20            = $20,000
cost    = 900*0.87 + 90*5.40 + 10*38.00
        = 783 + 486 + 380       = $1,649

blended margin = (20,000 - 1,649) / 20,000 = 91.8%

Ninety-two percent, which looks like a healthy SaaS business, while 1% of customers are served at a 90% loss. Both statements are true simultaneously and the second one is the one that matters, because the mix is not fixed. Run the same arithmetic with the extreme profile at 5% instead of 1%:

cost = 860*0.87 + 90*5.40 + 50*38.00
     = 748 + 486 + 1,900 = $3,134
blended margin = (20,000 - 3,134)/20,000 = 84.3%

Seven and a half points of margin from a four-point change in the share of one profile. Track the profile mix as a metric, not just the blended number, and be aware that marketing a feature to power users moves it deliberately.

The fair-use ceiling, computed

Once margin is a function of usage, the usage at which it hits your target is computable, and it is the honest basis for a fair-use limit — a number derived rather than picked.

max_requests = R * (1 - m_target) / c

  R         revenue per user per period
  m_target  the gross margin you are willing to accept
  c         fully loaded variable cost per request

R = $20, m_target = 0.70, c = $0.012:
  max_requests = 20 * 0.30 / 0.012 = 500 per month

And the break-even, where margin reaches zero:
  R / c = 20 / 0.012 = 1,667 requests per month

Those two numbers — 500 and 1,667 — are the entire basis for a plan design. Set the included allowance below the first, price the overage above c, and you have a plan that cannot produce a negative-margin customer. Which of the available plan shapes you use to express that is a separate decision.

One caution about publishing the limit: a cap stated in requests is meaningful to you and meaningless to a user, who does not know what a request is. Translate it into product units — documents, questions, hours of audio — and make sure the translation is stable, because if one “document” can secretly be forty requests, the cap does not do what the arithmetic says.

Fixing a bad margin

Only four things can move it, and they are worth naming in order of how often they are the right answer.

• Reduce c. Everything in this cluster. It is the only lever that does not require asking a customer for anything, and it is usually far from exhausted — most first-version prompts and model choices have substantial headroom.
• Bound usage. Allowances and overage, derived from the ceiling above. Changes the shape of the distribution rather than its cost.
• Raise R for heavy users. A higher tier that correlates with the usage that drives cost. This is what plan design is for, and it is the answer when the heavy users are also the ones getting the most value.
• Serve the tail differently. Route the heaviest usage to a cheaper model, batch it, or make it asynchronous. The p99 user often has a different tolerance for latency than the p50 one, and that tolerance is worth money.

What is not on the list: hoping the price of inference falls. It may well, and it is not a plan. Build the model with today’s c, and treat any decline as upside rather than as an assumption.