A cheap AI request can still produce an expensive feature. A user may need several calls to get a usable result, or a person may have to correct the output before the task is actually done. If you price the feature using only the cost of one API call, you can miss much of what it takes to deliver value.
A more useful measure is cost per successfully completed task: the total cost of running the feature across a group of tasks, divided by the number that were completed to your standard. It counts the work spent on failures as well as successes.
Define what “completed” means
Before estimating cost, decide what outcome counts as a completed task. “The model returned a response” is usually not enough. The user might need a usable product description, a correctly categorized receipt, or a draft they can publish with little or no editing.
Write down a practical completion rule. For example: “The user accepts the result without requesting a retry or making a substantial correction.” The right rule depends on the feature. What matters is applying it consistently so that you can compare costs over time.
This definition also helps avoid a misleading metric. A feature can have low cost per request but poor cost per completed task if many responses are rejected, retried, or manually repaired.
Calculate cost per successful AI task
Use this formula:
Cost per successful task = total cost of all attempts and corrections ÷ number of successfully completed tasks
Include the costs incurred across the whole workflow, not just the first model call:
- Model usage for successful and unsuccessful attempts
- Any additional model calls made during retries or follow-up steps
- Tools or services used as part of the task
- Human time spent correcting or completing the result
AI providers may charge according to different usage units for models and tools. For example, model pricing can distinguish between input and output tokens, and tool use can have its own pricing. A response that looks short to a user may therefore not tell you the full cost of producing it. Check the usage details and current pricing for the services your feature actually uses.
A simple example
Suppose 100 users start a task. The workflow generates:
- 100 first attempts at $0.04 each: $4.00
- 24 retry attempts at $0.04 each: $0.96
- Other model or tool usage: $2.00
- Human corrections: 12 minutes at an assumed $30 per hour: $6.00
The total is $12.96. If 82 tasks meet your completion rule, the cost per successful task is:
$12.96 ÷ 82 = about $0.16 per successful task
These figures are only illustrative. The useful point is that the cost of all 124 attempts and the correction time are divided by 82 completed tasks—not by 100 initial requests, or by 124 model calls.
The example includes human time even if a founder or employee currently does the corrections without recording a cash expense. That time still represents work the product may need to support, automate, or price for as usage grows.
Track both cost per task and cost per user
Cost per successful task is useful for judging whether the feature can deliver its intended outcome economically. But it does not, by itself, tell you what an average user will cost.
For a rough user-level estimate, multiply the average number of tasks a user starts during a period by the average cost per started task:
Estimated AI cost per user = tasks started per user × average cost per started task
Use cost per started task here because some user-initiated tasks will fail and still incur costs. For example, a feature that completes most tasks cheaply may still be costly per user if people use it frequently or make many attempts.
It is helpful to report both measures:
- Cost per successful task shows the cost of delivering the outcome.
- Cost per started task or per user shows the likely usage burden, including unsuccessful work.
If usage varies widely, a single average may hide the risk. Compare typical users with heavy users, or examine a range of usage levels, before deciding on a limit or subscription allowance.
Build a lightweight cost record
You do not need an elaborate financial model to start. For each user task, keep a record that lets you connect provider usage to the outcome. Useful fields include:
- A task identifier and whether it met your completion rule
- The number of model calls and retries
- The usage and cost reported for those calls
- Any tool or service usage tied to the task
- Whether a person intervened, and roughly how much time it took
Provider dashboards and usage records can help you inspect request-level usage and aggregate costs. Where possible, connect those records to your own task identifiers; a monthly provider bill alone may not tell you which feature or outcome generated the cost.
Start with a small, representative batch of real tasks. Calculate the totals, then repeat the measurement after meaningful changes to the workflow, model, or product. The purpose is not to predict every future bill precisely. It is to discover whether your estimate is missing a cost category or assuming too many tasks succeed on the first try.
Use the result to inform pricing and limits
Cost per successful task gives you a floor for thinking about pricing, not a price by itself. The amount a customer will pay, how often they use the feature, and your other costs also matter.
As a basic check, compare the AI feature’s variable cost with the revenue you expect from the customer or usage unit. If you have a target gross margin, the portion of revenue left for variable costs is limited: at a 70% target gross margin, for instance, 30% of revenue remains to cover variable costs before fixed expenses. AI usage is only one part of that budget; payment fees and other per-use costs may need to fit there too.
If costs rise sharply with repeated attempts or heavy usage, consider whether a usage limit, credit allowance, or separate price for the feature is needed. If the economics work only when nearly every task succeeds on its first attempt, test that assumption rather than building your price around it.
The practical rule is simple: price the outcome you deliver, but measure every attempt it takes to deliver it. That gives you a more useful estimate than the price of a single API call—and a better basis for deciding whether the feature belongs in your product’s business model.