AI Feature Unit Economics: Cost per Task, Quality, and Margin

A feature that looks profitable on a per-call spreadsheet can lose money in production. The spreadsheet counts requests. Production counts attempts, failures, and the human who cleans up after them.

Most teams price an AI feature against the wrong unit. They estimate cost per API call, multiply by expected volume, subtract from price, and call the result margin. That number survives exactly until the first model update, the first long-context input, or the first customer who pastes a 40-page document into a field designed for a paragraph.

The unit that actually decides whether a feature makes money is cost per successful task. Everything below is a working model for computing it, adjusting it for quality, and testing whether the resulting margin survives contact with real usage.

The Unit That Actually Decides Margin

Per-call cost is an input price, not a product cost. It tells you what you paid for one attempt. It says nothing about how many attempts were needed, whether the attempt produced something the customer accepted, or what a human had to do afterward.

Start by defining a task: the smallest unit of work the customer would recognize as done and worth paying for. Not a token. Not a request. Not a generation. A task is "this support ticket is answered correctly," "this invoice is extracted into the right fields," "this code change passes review." If you cannot describe the task in a sentence a customer would agree with, you do not yet have a unit to measure.

With that defined:

Cost per successful task = total cost of all attempts and interventions ÷ number of tasks that actually succeeded

The numerator includes every attempt, including the ones that failed and were retried. It includes human review, escalation, and the support contact that followed a bad output. The denominator counts only successes, judged by an evaluation you trust.

Here is why the distinction bites. Suppose a cheap model costs $0.002 per attempt and succeeds 60% of the time. A more expensive model costs $0.010 per attempt and succeeds 95% of the time. Ignoring retries, the cheap model looks five times better. But the cheap model needs roughly 1.67 attempts per success, so its cost per success is about $0.0033. The expensive model needs about 1.05 attempts, so its cost per success is about $0.0105. The gap narrows from 5x to roughly 3x — and that is before you price the human review that the 40% failure rate generates. Add even a small amount of human time per failure and the cheap model can lose outright.

The arithmetic is not the hard part. The hard part is the assumption underneath it: success must be defined by an evaluation you trust, not by the model's own confidence. A model that says it completed the task is reporting a probability distribution over tokens, not a verified outcome. If your success signal comes from the model, your denominator is fiction.

One Worked Model, End to End

The formula above is easy to nod at and hard to run. So run it once with explicit numbers, then reuse the same variables everywhere else in this article.

Assume a document-extraction feature. Price is $0.50 per successful extraction, billed per task. In a pilot month you process 10,000 submitted documents.

Variable	Value	Notes
Submitted tasks	10,000	Customer-recognizable units
First-pass success rate	70%	Measured on a labeled set
Automatic retries	1	Applied to first-pass failures
Retry success rate	50%	Of the 3,000 first-pass failures
Escalation rate	15%	Of final outputs, sent to human review
Cost per attempt	$0.004	Blended model and context cost
Human review cost	$0.30	Per escalated task
Support cost	$0.02	Per submitted task, allocated

Walk the arithmetic in order.

Attempts. 10,000 first attempts, plus 3,000 retries, equals 13,000 attempts. Inference cost is 13,000 × $0.004 = $52.

Final successes. First-pass successes are 7,000. Retries recover 50% of the 3,000 failures, or 1,500. Final successes are 8,500, a final success rate of 85%.

Escalations. 15% of 8,500 final outputs go to review: 1,275 tasks. Review cost is 1,275 × $0.30 = $382.50.

Support. 10,000 submitted tasks × $0.02 = $200.

Total cost. $52 + $382.50 + $200 = $634.50.

Cost per successful task. $634.50 ÷ 8,500 = $0.0746.

Gross margin per successful task. $0.50 − $0.0746 = $0.4254, or about 85%.

Now look at what that table actually says. Inference is 8% of total cost. Human review is 60%. The model bill — the number most teams forecast first — is the smallest line in the model. If you had priced this feature off per-call cost, you would have estimated $0.004 per task and concluded you had a 99% margin. You would have been wrong by an order of magnitude, and the error would have been invisible until review labor showed up on a payroll report.

This is the spine of the article. Every section below changes one of these variables and asks what happens to the bottom line.

Where the Real Cost Hides

A per-call estimate captures one line of a much longer bill. Before you trust any margin number, fill in each of these with your own figures.

Retries and re-prompts. Cost scales with attempts, not requests. In the worked model, retries added 3,000 attempts and $12 — small, because the retry rate was modest and the per-attempt cost was low. Change either assumption and the line grows. A feature with a 50% first-pass success rate and three retries is paying for far more attempts per success, and the hard inputs cluster at the top of your usage distribution.

Repeated deterministic inputs. A surprising share of real traffic is the same input arriving again. Hashing the input and caching the output — or caching embeddings on an input hash — removes a class of spend that looks like retry cost but is not. This is one of the cheapest wins available, and it is routinely missed. The same input should not pay twice.

Context growth. Long or stacked context inflates per-attempt cost faster than most forecasts assume. Teams that "just add the whole document" or "just stack the last ten turns" discover the cost curve bends upward precisely when usage gets serious. Context is not free storage; it is a per-attempt tax that compounds with every retry.

Non-per-run costs. These never appear in a per-call estimate: re-embedding after a data or model change, a vector store that jumps a pricing tier past some row count, evaluation runs, monitoring, and the engineering time to keep the pipeline alive. They are real, they are recurring, and they are the ones that blow forecasts.

Human review and escalation. In the worked model this was the dominant cost. Treat it as a line item, not an exception. If 15% of outputs get reviewed by a person at even a few minutes each, that labor can dwarf the inference bill. The moment review becomes permanent, you are not running an AI feature with a safety net. You are running a human workflow with an AI pre-filter.

Support burden. Tickets, refunds, and manual cleanup generated by low-quality outputs are a cost of the feature, not a cost of the company. Attribute them. A feature that saves $2,000 in inference but generates $5,000 in support contacts is not a cheaper feature.

Build this as a checklist you fill in with your own numbers rather than a formula someone hands you. The categories are stable; the values are yours.

Quality Is a Cost Multiplier, Not a Feature

It is tempting to file quality under "reliability" and cost under "finance." That separation is the mistake. Success rate is the divisor in the unit economics. A small quality drop can erase a large cost advantage, because it multiplies both the attempts in the numerator and the interventions attached to each failure.

Distinguish two kinds of success. Task success is whether the output met the spec. User-perceived success is whether the customer believed it did. The second drives churn and support load, and the two diverge more often than teams expect. An output that is technically correct but confusing generates a ticket anyway.

Large-scale usage studies offer directional signals here, not benchmarks for your workload. Anthropic's economic research, for example, reports task success rates that differ substantially between conversational and API usage patterns — higher in multi-turn settings where users can clarify and correct, lower in single-shot API calls. That is a useful research signal about how interaction shape affects success. It is not a number you can drop into your model, because your task, your inputs, and your users are different.

The only quality number that counts is one you measured on your own inputs. Build a small labeled set from real traffic — a few hundred examples is a reasonable starting heuristic, not a universal sample-size rule — and measure pass rate against a definition of success you wrote down in advance. Re-measure after every model or prompt change. A quality gate is the rule that decides whether an output is good enough to ship to the customer; an escalation threshold is the rule that decides when a task goes to a human instead. Both belong inside the cost model, because they determine how many tasks land in the denominator and how much human time lands in the numerator.

Model selection and routing tradeoffs are their own decision, covered elsewhere. Here the only question is narrower: how does quality enter the margin calculation? It enters as the divisor and as the escalation rate. Nothing else.

From Cost per Task to Margin per Customer

Now convert unit cost into a margin statement you can defend.

Gross margin per task = price per task − cost per successful task, where cost includes review and support.

Be precise about what this number is. It is task-level contribution margin — the money left after the variable costs of producing one successful task. It is not business profitability. Fixed engineering salaries, sales and marketing, compliance, payment processing, baseline cloud costs, refunds, and customer acquisition cost all sit outside this model, and any of them can turn a healthy task margin into an unprofitable account. The unit economics tell you whether the feature can pay for its own production. They do not tell you whether the company makes money.

The average is not the number that matters. The usage distribution is. Heavy users and edge-case inputs set your true cost floor. If your 90th-percentile input costs ten times the median, your blended margin is a story you tell yourself while the top decile quietly loses money. Model the distribution, not the mean.

Watch how pricing structure shifts who absorbs variance:

• Per task passes cost variance to the customer and protects your margin, but punishes you on quality — every failure is a visible charge for nothing.
• Per seat gives you predictable revenue, but a single heavy user can invert the economics of an entire account.
• Per outcome aligns price with value and hides your cost structure, but you absorb every retry and every escalation.

Name the tradeoff rather than defaulting to one. Free tiers, trials, and "unlimited" plans deserve special suspicion: each one converts a variable cost into a fixed-price liability. Unlimited usage on a metered backend is a bet that your heaviest users will be average. They will not be.

One honest note on external evidence: public disclosures from large AI platforms show real infrastructure scaling pressure on gross margins — Microsoft's 2025 annual report, for instance, attributes a decrease in cloud gross margin percentage partly to scaling AI infrastructure, offset by efficiency gains. That is a signal about the cost curve at hyperscale. It does not transfer to your product's numbers, and you should not cite it as if it does. Your margin comes from your measurements.

Forecast Before You Build, Then Let Production Correct You

You cannot know the real numbers before you ship. You can still avoid building blind.

Start with a per-run estimate. Apply a complexity multiplier for retries and context growth — practitioners who have done this repeatedly tend to budget several times the naive per-call figure, precisely because the hidden costs above are so common. Compare the result against the price the customer will actually pay. If the multiplied cost already exceeds the price, stop. The feature does not need a prototype to fail.

Then cap the initial population. Run the feature on a limited input set, measure real cost and real success, and widen only when the numbers hold. This is forecasting with data instead of guesses, and it is the single highest-leverage step in the process.

Instrument four things from day one:

• Cost per successful task
• Success rate
• Escalation rate
• Support contacts per hundred tasks

Add margin per active customer once you have enough accounts to see the distribution. Re-run the numbers after every model, prompt, or pricing change — the cost line and the quality line move independently, and either one can flip the conclusion.

Define the kill or redesign threshold in advance. A decision made under sunk-cost pressure is not a decision; it is a rationalization with a deadline. Treat the first forecast as a hypothesis. Production data is the only evidence that counts.

Reading the Numbers: Which Lever to Pull

A launch gate is only useful if it tells you what to fix. The same failing margin can come from four different causes, and each one has a different lever. Diagnose before you act.

Symptom	Likely cause	Lever
Inference dominates total cost	Too many attempts, oversized context, or an expensive default model	Reduce retries, compress context, route easy inputs to a cheaper model
Review dominates total cost	Quality gate too loose, or task scope too broad	Tighten the gate, narrow the task contract, improve the prompt or model
Support dominates total cost	Outputs are correct but confusing, or failures reach the customer	Change UX and error handling, add pre-send validation, set expectations
Tail accounts break margin	Usage distribution is heavy-tailed and pricing is flat	Change packaging, add limits, move heavy users to per-task pricing

The worked model earlier had a review-dominated cost structure. The right response there is not to shop for a cheaper model — inference was 8% of cost. The right response is to raise first-pass success or narrow the task so fewer outputs need a human. Pulling the wrong lever is how teams spend a quarter optimizing the smallest line on the spreadsheet.

Failure Modes That Break the Model

The unit economics rarely collapse all at once. They erode through specific, watchable failure modes.

Non-linear scaling. A small pilot looks healthy, then context growth or a storage tier change bends the cost curve. The signal: cost per task rising while request volume stays flat.

Silent quality drift. A model or prompt update quietly lowers success rate. The cost line does not move until support tickets rise weeks later. The signal: success rate on your labeled set dropping after a change you did not re-measure.

Permanent temporary review. Human review starts as a safeguard and becomes payroll. The signal: escalation rate flat or rising over months with no plan to reduce it.

Caching that hides a correctness bug. Returning stale outputs for repeated inputs looks like a cost win until a customer notices the wrong answer. The signal: cache hit rate high, and a correctness complaint on a repeated input.

Pricing locked before the cost curve was understood. You shipped a price that leaves no room to reprice without churning customers. The signal: margin per task trending toward zero while you have no lever to pull.

Each of these has an early observable. Put the observables on a dashboard and you will catch the erosion while it is still cheap to fix.

What to Learn Next

The skills worth building follow directly from the model. Evaluation set construction gives you a trustworthy denominator. Cost instrumentation gives you a trustworthy numerator. Routing and cascade design — sending easy inputs to a cheap model and hard ones to an expensive one, with explicit quality gates — determines the cost floor this model measures. Serving architecture, batching, and caching set that floor lower or higher.

Each of those skills maps to one variable in the worked model. Learn them in the order that matches your current bottleneck, not the order they appear in a syllabus.

Here is the operating rule I would hold to: do not scale a feature whose cost per successful task you cannot state from measured data, and whose margin does not survive your worst realistic usage pattern. The demo proves the feature is possible. The unit economics prove the feature can pay for its own production. Measure the second before you scale the first.