AI Feature Unit Economics: Gross Margin Per Request

Q: What is gross margin per request for an AI feature?

Gross margin per request is the profitability of a single invocation of an AI feature, computed as (allocated revenue per request minus fully-loaded cost-of-goods-sold per request) divided by allocated revenue per request. It is the unit-economics number that decides whether an AI feature is a viable business, and it differs sharply from cost per request, which most teams track instead. Cost per request is an infrastructure metric that tells you what you spend; margin per request puts revenue next to that cost and tells you whether each unit clears a floor you can defend. The reason the distinction matters is that you can hit an aggressive efficiency target — cutting cost per request by 40% — and still sell every request below what it costs to serve, because you never modelled the revenue side of the same unit. Modelling margin per request forces you to attribute both cost and revenue to the same atomic action, which is the only way to see that a feature is structurally unprofitable before it becomes a structural problem in the P&L.

Q: Why do AI features lose the most money on the most engaged users?

Because AI features invert the economics of classic software. In traditional SaaS, marginal cost is near zero, so a power user who runs a feature a thousand times a month is pure upside — they cost almost nothing extra and they stay subscribed. In an AI feature, every single request burns input tokens, output tokens, retrieval, reranking, and orchestration overhead, which is real cost-of-goods-sold that lands the moment the user acts. Under a flat monthly price, revenue is fixed while that cost scales linearly with usage, so the heaviest user is also the largest loss. A customer making three thousand requests a month on a twenty-dollar plan can consume a hundred and fifty dollars of cost, a deeply negative gross margin on that account, while the median user making forty requests looks wonderful. The blended average hides a bimodal disaster: a healthy mean margin can mask a long tail of negative power-user accounts that grows faster than the profitable middle, which is exactly why teams are surprised when a successful, high-engagement feature turns out to be dragging the whole product underwater.

Q: Why is counting only the input token price a costly mistake?

Because output tokens are priced three to five times higher than input tokens on every major provider, and they usually dominate the cost stack, so a cost model built on the prompt price alone understates true cost-of-goods-sold by multiples. A worked example makes it concrete: at an illustrative three dollars per million input tokens and fifteen dollars per million output tokens, a request with a four-thousand-token prompt and an eight-hundred-token answer costs about one and a half cents in input and one and a half cents in output — the output half, from far fewer tokens, matches the input half because of the price asymmetry. Worse, the raw model call hides several more layers: a retrieval query and a reranking pass, an embedding call to index context, a guardrail or moderation call, retries on transient failures, and fixed platform overhead amortised per request. The fully-loaded cost is easily two to six times the naive token-price estimate. Pricing a feature off the input token rate therefore prices you into a loss you will not detect until the bill arrives, which is why serious unit-economics work always starts by building fully-loaded cost attribution per request, per feature, and per customer.

Q: Which pricing model is best for an AI feature in 2026?

There is no universally correct pricing model; the right one matches your cost structure and buyer, and the job is to make revenue variance track cost variance. Flat or per-seat pricing has the lowest buyer friction but no cost-tracking at all, so on an unbounded-usage feature it structurally guarantees margin erosion as usage grows — it only works when usage is genuinely bounded. Usage-based or metered pricing tracks cost directly and holds margin per unit, but unpredictable bills create real buyer friction and suit infrastructure-like features and developer audiences. Credit or token systems abstract the meter into a costed unit and fit consumer and prosumer products. Outcome-based pricing charges for a measurable result and absorbs cost variance, which is powerful when the outcome is clear and attributable. The pattern that has become the default for serious B2B AI features in 2026 is the hybrid: a seat or platform fee for the low-friction floor buyers want, a generous included quota sized so the median user never sees the meter, and metered overage above it so the power user who would have been a large loss instead pays for the marginal cost they impose. The quota is the margin guardrail; the overage is the release valve.

Q: What COGS levers lower cost per request without changing the price?

The three highest-leverage engineering levers are caching, routing, and batching, and each widens margin invisibly to the customer, which makes them safer than a price increase that risks churn. Prompt caching is the largest reliable win for retrieval-augmented and agentic features: if your requests share a long stable prefix — a system prompt, a tool schema, a document reused across a session — caching that prefix cuts its input cost by up to about ninety percent on a cache hit, though silent invalidators can quietly zero your hit rate if you are not careful. Model routing sends the easy majority of requests to a cheaper model class and reserves the frontier model for requests that genuinely need it, often a three-to-five-times cost reduction on the routed fraction with no perceptible quality loss. Batching runs latency-tolerant work on batch tiers at roughly half the synchronous price, so anything that does not need a token in two hundred milliseconds should not pay the synchronous premium. Beyond those, model-efficiency techniques — quantisation, distillation, and speculative decoding — compound to cut inference cost substantially. The discipline is to treat cost per request as a controllable number with a named owner rather than a fact of nature.

Q: Why does "we’ll fix margin at scale" fail for AI features?

Because scale fixes margin only for fixed-cost software, and AI features are variable-cost. In a classic software business, most cost is fixed engineering and infrastructure, so as you add users the cost per user falls and margin improves — scale genuinely is a margin strategy. In an AI feature, the dominant cost is per-request cost-of-goods-sold that scales linearly with usage, so adding users does not amortise a fixed cost; it multiplies a variable one. If each unit is sold below cost, more volume means you lose more money faster, not less. Waiting for scale to rescue a negative unit margin is therefore precisely backwards: the loss compounds with the growth you were counting on to fix it. The correct sequence is to make the unit economics work first — through pricing that tracks cost and COGS levers that lower it — and only then pour volume into a unit that already clears its margin floor. Volume is an amplifier, and it amplifies whatever sign the unit margin has. The only legitimate version of running negative at scale is a deliberate, time-boxed decision with a number and an exit criterion, not a hope that the arithmetic reverses on its own.

Q: How do you measure contribution margin per customer for an AI product?

You measure contribution margin per customer by attributing fully-loaded cost-of-goods-sold to each customer at the request level and placing their allocated revenue next to it, then summing over the billing period. This requires an attribution architecture as a prerequisite: you must be able to tag every request — its input and output tokens, retrieval and reranking calls, guardrail and retry calls, and amortised overhead — to the customer and feature that caused it. For multi-tenant systems this is the per-tenant profit-and-loss problem, where cost attribution has to be fair across tenants and robust to noisy neighbours; for autonomous or agentic features it extends to per-agent, per-task, and per-tool-call attribution so spend maps to the action that triggered it. Once you can attribute cost, you compute each customer’s COGS for the period, subtract it from the revenue you can allocate to them, and rank customers by contribution margin. This is where the bimodal truth appears: you can finally name the specific accounts running negative margin instead of hiding them inside a healthy blended average, and pricing and packaging conversations become evidence-based rather than guesses.

Q: When is it acceptable to run an AI feature at negative gross margin?

It is acceptable when negative margin is a deliberate decision with a number and an exit criterion, not an accident you discover later. There are legitimate reasons to run below cost: a loss-leader feature in a land-grab where you are buying market position, or an early-stage feature you are deliberately subsidising to learn what real usage even looks like before you have the data to price it. In both cases the negative margin is a financed investment with a defined purpose, a budgeted size, and a condition under which it ends or converts to a sustainable model. The failure mode is never simply "we ran a feature at negative margin" — it is "we ran a feature at negative margin and did not know," where a hidden negative power-user tail compounds silently through a growth phase until it is a structural hole in the business. The discipline that separates the two is visibility: you must be at the maturity stage where you can compute margin per request and contribution margin per customer, so that any decision to run negative is a choice made against real numbers, with an owner watching the trajectory and a plan to turn it positive.

Satyam Kumar

Volver al Blog

ai

AI Feature Unit Economics: The Gross Margin Per Request Nobody Modelled (2026)

By Satyam KumarSeptember 2, 202613 min read

ai unit economics gross margin per request ai feature pricing llm cost optimization cost per request contribution margin usage-based pricing token cost prompt caching model routing finops for ai ai product strategy saas gross margin inference cost ai cogs margin guardrails

AI Feature Unit Economics: The Gross Margin Per Request Nobody Modelled (2026)

Frequently Asked Questions

Compartir este artículo

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Arquitecto de IA y Cloud. Ayudando a equipos a construir sistemas que escalan a millones.

LinkedIn GitHub

AI Feature Unit Economics: The Gross Margin Per Request Nobody Modelled (2026)

Frequently Asked Questions

Compartir este artículo

Comments

Leave a comment