The model invoice is only one input
An AI feature can look affordable when the estimate starts with one prompt and one response. Real workflows are rarely that tidy. A request may retrieve documents, call tools, generate a draft, retry an incomplete result, and wait for someone to review it.
Each step uses resources. Some appear on an infrastructure invoice. Others appear as operator time, support work, or a customer repeating the task because the first result was not useful. Looking only at the model call can hide the actual cost of the feature.
The unit I want to understand is a useful completed task. That connects spending to what the product promises instead of treating every generated response as equivalent value.
Define the outcome before calculating its cost
For a document assistant, a useful outcome might be an accepted draft grounded in the selected source material. For an extraction feature, it might be a record that meets the required validation and is accepted into the next workflow. For a support assistant, it might be a resolved question or a complete handoff.
The definition needs enough precision to distinguish success from activity. A fluent answer that cannot be used should not count the same as a verified result. A draft that requires a person to rewrite nearly everything should remain visible in the measurement.
This is adjacent to quality evaluation, but it answers a different question. Evaluation asks whether the behavior meets the requirement. Unit economics asks what it costs to produce that behavior consistently at the expected volume. The two inform each other without being interchangeable.
Follow the whole request
A practical cost model should account for the major steps in the workflow. Depending on the product, those may include ingestion, indexing, retrieval, inference, tool execution, storage, review, and support.
Some costs happen once and benefit many requests. Others recur every time. Keeping those separate makes the estimate more useful. Reindexing a knowledge base should not be mistaken for the cost of one answer, but it still belongs in the operating picture.
Imagine an assistant that drafts project summaries. It makes three generation attempts for some requests, retrieves several documents, and requires a reviewer to check the references. The draft is only one output. The actual work includes every attempt and the time needed to accept the result.
Tracing those steps helps the team identify whether the expensive part is context size, repeated generation, slow tools, or extensive human correction. Without that detail, optimization becomes guesswork.
Use illustrative numbers carefully
Suppose a hypothetical batch has 100 requests and produces 80 accepted results. The batch uses $12 in model and tool costs and $40 in review effort. The direct workflow cost is $52, or $0.65 per accepted result.
Those figures are illustrative assumptions, not provider pricing or a forecast. Their purpose is to show the denominator. Dividing only model costs by incoming requests would suggest $0.12 per request and conceal both review effort and unsuccessful work.
The calculation still needs a consistent scope. Engineering investment, ongoing support, and shared infrastructure may belong in separate views of total cost. The team should document what each view includes so that a small direct cost is not presented as the entire business case.
Averages need a workload distribution
Two requests can have very different costs. A short summary of one document is different from reconciling a folder of long, conflicting files. A common question may finish in one pass while an unusual case triggers several tools and retries.
I would group representative work into a few meaningful categories and measure them separately. Look at ordinary requests, larger requests, and expensive exceptions. Then estimate how frequently each category occurs under expected use.
This helps reveal whether the feature's economics depend on an unrealistic mix. If the product attracts more complex work over time, an estimate based on short demonstration prompts can become misleading. The operating limits should reflect the work the product invites people to submit.
Optimize the expensive step without breaking the outcome
A cheaper model is one possible improvement. It is not the only one. Better document selection can reduce unnecessary context. A deterministic operation can replace generation for a well-defined transformation. A reusable intermediate result can avoid repeating the same work when its inputs remain valid.
Each improvement should be checked against the accepted outcome. Saving on inference while increasing review time may raise the overall cost. A fast answer that omits necessary evidence can move work onto the operator. More aggressive reuse can produce stale results unless the validity rules are explicit.
I prefer to compare total effort for the same task definition. That keeps cost optimization connected to product quality and gives the team a fair way to choose between alternatives.
Limits should explain the product promise
Cost limits eventually become product behavior. The system may need limits on document size, request volume, tool calls, or repeated attempts. People should understand these boundaries before investing time in a task the application cannot finish.
A useful limit provides a next step. Split the document set, narrow the question, or hand the case to a reviewer. A hidden cutoff that returns a partial answer as though it were complete undermines the entire measurement.
AI unit economics gives the team a way to discuss sustainability with evidence. Define useful completion, count the work needed to reach it, understand the distribution, and test improvements against the same outcome. Then the feature's cost reflects the value people actually receive.