The median seat is not the seat that costs you money

The first per-seat cost query was run because a board deck needed a number, and the number it produced was $2.10 — median model spend per seat per month, a seat being one licensed user and the unit this product is sold in, against a list price of $29. Somebody wrote "93% margin on inference" in the deck and nobody objected, because the median is the statistic people reach for when they want to describe a typical customer and it is a reasonable thing to want.

The same query, grouped differently, showed the mean was $4.85. A mean more than double the median means the distribution is not merely spread out, it is dominated by a small number of large values, and the mean is the one that multiplies by seat count to produce the invoice. Total model spend across 4,180 seats was $20,273 that month, and if the median had described the fleet it would have been $8,778.

Reading the whole distribution instead of a point on it#

Sorting seats by monthly model cost and reading the percentiles gives a picture no single statistic conveys.

The top 1% of seats — 42 of them — average $118 and consume $4,956, which is 24% of all model spend. The top 5% consume 39%. This is the ordinary shape of usage in a product where the amount of work a customer can ask for is not bounded by the contract, and it is the reason a flat price is an underwriting decision rather than a pricing decision. You have sold an unlimited-usage policy at a fixed premium, and the thing an insurer does next, which software companies routinely skip, is to price the tail explicitly and cap it.

The comparison with underwriting is worth pushing one step further, because insurers solved this problem a long time ago and their solutions have direct analogues. They do not price a policy from the expected loss alone; they add a risk load proportional to the variance of the loss distribution, they write policy limits so a single claim cannot be unbounded, and they buy reinsurance for the part of the tail they will not hold. A flat software seat has none of those. It is a policy with an expected loss of $4.85, no limit, no risk load, and no reinsurance, sold at a premium set by looking at the median claim.

Building the distribution correctly takes some care about what a seat is. Licensed seats that never log in should be counted, because they pay and cost nothing, and excluding them inflates every percentile; service accounts should be separated out rather than treated as seats, because their cost is generated by a schedule rather than a person and mixing them in makes the human distribution look heavier than it is. On this fleet, 18% of licensed seats had zero sessions in the month, and pulling them out of the denominator would have moved the median from $2.10 to $2.80 and told you nothing new.

Where a seat stops paying for itself#

The per-session cost stack from chapter 3 has a per-seat analogue. Non-model cost of goods on this product runs about $4.30 per seat per month: $1.90 of support contacts, $1.40 of escalation review, $0.60 of retrieval infrastructure and $0.40 of allocated platform. That leaves $24.70 of a $29 seat available to absorb model spend before the seat costs more than it brings in, and the contribution column below is that headroom after the seat's actual model spend has come out of it.

The crossover is at $24.70 of model spend, which on this distribution sits at about the 97.6th percentile, so roughly 100 seats are individually unprofitable. Collectively they consume $8,900 of inference while paying $2,900 of subscription, destroying about $6,000 of gross profit a month, which the other 4,080 seats quietly cover. Fleet margin is still 68.5%, and the deck is still positive, and none of that changes the fact that a hundred seats are being served at a loss and nobody has been asked whether that is intentional.

Some of it may well be intentional. A design partner using the product hard while a case study gets written is a marketing expense wearing a subscription. The distinction that matters is whether the loss is a decision someone made or a consequence of a pricing structure that cannot see the difference.

How far the tail has to move#

The useful question is not whether the current distribution is affordable, since it obviously is, but how much it has to change before it is not. That is a sensitivity analysis: moving one input at a time and recording how far it has to travel before the conclusion changes. It needs the fleet mean rather than any percentile, because margin is a fleet-level quantity.

SEATS = 4_180
PRICE = 29.00
OTHER_COGS = 4.30

BODY_MEAN = 3.68     # mean model cost of the bottom 99% of seats
TAIL_SHARE = 0.01    # fraction of seats in the heavy tail
TAIL_MEAN = 118.00   # mean model cost of a tail seat

def fleet_margin(body_mean=BODY_MEAN, tail_share=TAIL_SHARE,
                 tail_mean=TAIL_MEAN, context_mult=1.0, cache_hit=0.91):
    # falling cache hit rate raises input cost on the cached prefix
    cache_mult = (1 - cache_hit * 0.9) / (1 - 0.91 * 0.9)
    scale = context_mult * cache_mult
    mean_cost = ((1 - tail_share) * body_mean + tail_share * tail_mean) * scale
    revenue = SEATS * PRICE
    cogs = SEATS * (mean_cost + OTHER_COGS)
    return mean_cost, (revenue - cogs) / revenue

print(fleet_margin())                                  # $4.82, 68.7%
print(fleet_margin(context_mult=1.4))                  # $6.75, 62.0%
print(fleet_margin(cache_hit=0.55))                    # $8.34, 56.5%
print(fleet_margin(tail_share=0.04))                   # $8.25, 56.8%
print(fleet_margin(tail_share=0.04, context_mult=1.4,
                   cache_hit=0.55))                    # $19.86, 16.7%

Each scenario is a thing that has actually happened to somebody. Context growing 40% is a product decision — attaching the full document instead of three retrieved chunks, or raising the agent's turn budget. Cache hit rate falling from 91% to 55% is a deploy that put a variable line above the cached prefix, which chapter 2 showed costs nothing to introduce and is invisible without the hit-rate metric. The tail growing from 1% of seats to 4% is what happens when a feature that made automation easy ships and the customers who wanted it find it.

The combined scenario is the one to carry into a pricing conversation: three individually survivable changes take fleet margin from 68.7% to 16.7%, below the company's cost of serving anything else, and no single one of them would have triggered an alarm. The absolute break-even is a mean of $24.70, or 5.1× today's, which sounds like enormous headroom until you notice that the p99 seat is already 12.6× the mean and the maximum seat is 70×. Headroom measured against the mean is not headroom against the mechanism generating the tail.

The distribution is not stationary, and tenure shows it#

A single month's percentiles describe a snapshot, and the more consequential question is which way the snapshot is moving. Grouping seats by how long they have existed rather than by cost separates two effects that a fleet-wide percentile mixes together: seats get more expensive as their owners learn what the product can do, and the fleet gets cheaper as new seats dilute the old ones.

Mean cost per seat at thirteen months is 5.9× what it is in the first two, and the p95 seat in the oldest cohort costs $27.60, which is already past the $24.70 break-even. Nothing in the fleet-level $4.85 reveals that, because a third of seats were sold in the last two months and are still cheap. If the company stopped growing tomorrow and the existing seats simply aged, the fleet mean would drift towards the mature cohort's $10.90 without a single customer changing their behaviour, and margin would fall from 68.5% to about 47.6%.

This is the specific way growth flatters unit economics on a consumption-driven product. Rapid new-seat acquisition holds the average down while the cost base underneath it compounds, so the metric looks stable through exactly the period when it is deteriorating fastest, and it turns over when growth slows. Reporting cost per seat by cohort, alongside the fleet number, is what makes the deterioration visible while there is still time to price for it.

The monitoring that follows from this is a small set of numbers on the same weekly cadence as revenue: fleet mean cost per seat, the p95 and p99 of the seat distribution, the count of seats above the break-even threshold, and the mean for the oldest cohort. The threshold count is the one that should have an alert on it, because it converts a distributional question into an integer that a human can act on — a jump from 100 to 160 unprofitable seats in a week is a specific event with a specific cause, where a mean drifting from $4.85 to $5.20 is indistinguishable from noise.

The mistake that makes flat pricing feel safe#

The tempting argument is that heavy users are a fixed population: some customers are power users, they were always going to be power users, and their behaviour is now measured and stable. This treats the tail as a property of people, which would make it bounded, because a person can only spend so many hours a day using a product. A human at a keyboard generating $340 of model spend in a month is working extremely hard at it.

The tail is not generated by people working hard. It is generated by workflows, integrations and scheduled jobs, which have no equivalent ceiling and can multiply their consumption by ten with a configuration change nobody tells you about. That is why a sensitivity analysis on a flat price should never be presented as a range with an upper bound derived from history — the maximum observed seat is a fact about last month's integrations, not a limit.

What sensitivity analysis will not settle#

It quantifies exposure and it does not identify the exposed. Everything in this chapter is computed on the seat distribution, which is the right unit for margin arithmetic and the wrong unit for action, because seats do not sign contracts and cannot be called. Two tenants with identical seat counts and identical mean cost per seat can be entirely different problems: one with cost spread evenly across forty users doing ordinary work, another with thirty-nine idle seats and a single service account driving the whole bill.

A second gap is that the analysis prices exposure and says nothing about willingness to pay, which is what actually determines whether a fix is available. A seat costing $61 a month may be a customer getting $600 of value and delighted to pay $99, or a customer getting $12 of value from a workflow they configured badly and who would churn at any price increase. Cost data cannot distinguish those, and the response to each is opposite. Any pricing change derived from this distribution needs a second pass through the value side before it becomes a proposal.

The sensitivity also assumes the shape of the distribution is stable and only its parameters move, which understates the risk in one specific way. Distributions like this one get their tail from a mechanism, and the mechanism can change discontinuously — a customer wires the API into a nightly job, and their cost per seat goes from $3 to $200 in one deploy of theirs, with no gradual ramp for a dashboard to catch. Finding those accounts before the invoice does means ranking tenants rather than seats, and looking at the shape of their requests rather than the size of their contract.