UgurKeser.art

The unit economics of an AI feature in a commerce tool

The unit cost of an AI feature is not simply the price of one model response.

Uğur Keser4 min read

The unit cost of an AI feature is not simply the price of one model response. A commerce workflow can include retrieval, repeated calls, external tools, human review and recovery from failures. The useful economic unit is usually a completed customer task of acceptable quality, not a raw request.

This article proposes a cost model for evaluating a feature. It uses no current vendor price assumptions and makes no claim about realized margins. Actual rates, contracts and workloads must be measured in the intended environment.

Choose the billable and useful units separately

The provider may charge for tokens, requests or another resource. The product may sell a subscription or a completed audit. The customer cares about a useful result. These units should be connected explicitly rather than treated as interchangeable.

For example, one completed catalog review may require several model calls and a correction pass. If a failed attempt consumes resources but does not produce a usable review, its cost still belongs in the feature economics. Dividing only successful-call spending by total attempts can understate the true cost.

Build a per-task cost ledger

Cost component What to measure
Model inference Input, output and repeated calls under the actual configuration
Retrieval and storage Indexing, queries and retained artifacts required by the task
External tools Paid lookups or processing invoked during completion
Human review Time needed to accept, correct or reject the result
Failure recovery Replays, support and remediation caused by unsuccessful work
Shared infrastructure A reasonable allocation with assumptions shown

Keep variable costs distinct from development investment and general overhead. Both matter to the business, but mixing them makes it harder to understand how cost changes with usage.

Model the distribution, not only the average

A short product description and a large multilingual catalog can consume very different resources. Segment by task size and complexity. Inspect high-cost cases and the share of total usage they represent. A small number of repeated or unusually large jobs can dominate spending.

Define input limits, retry limits and task budgets before broad release. OWASP describes uncontrolled inference consumption as a source of service degradation and economic exposure. Its unbounded-consumption guidance supports treating resource control as a product requirement.

Include quality in the denominator

A cheap output that requires extensive correction may be more expensive than a slower output with fewer errors. Record accepted tasks, corrected tasks, rejected tasks and abandoned tasks. Decide which outcomes count as customer value and avoid counting a generated file as success merely because it exists.

The offline merchandising evaluation guide provides an example of quality gates. The economic review should use the same acceptance definition, otherwise the product and finance views are evaluating different units.

Stress-test the commercial model

Examine scenarios for longer inputs, higher retry rates, supplier price changes and heavier-than-expected customers. Ask whether a fixed subscription, included allowance or usage-based structure can absorb those patterns. Do not assume unused capacity from light customers will always subsidize the heaviest users.

Customer-facing limits should be understandable and connected to a real unit of work. A hidden limit that appears only after a customer depends on the feature can damage trust. Cost controls should therefore be designed with the user experience rather than added as surprise errors.

Review actual cohorts of usage

After a limited pilot, compare expected and observed cost per accepted task. Separate introductory setup work from recurring use. Check whether review effort declines because quality improved or because reviewers became less thorough.

The agent cost and latency guide extends the model to multi-step workflows. A defensible unit-economics view tells the team which tasks are useful, what they cost in full and which uncertainty could change the pricing or scope decision.