You own the AI feature. You also, whether the org says so out loud or not, own its margin. And when someone asks you the one question that matters — does this feature make money at the price we charge? — you can't answer it. Not because you're bad at spreadsheets. Because the only number you have is a blended provider invoice that lumps your feature in with six other teams' calls.
Cost per successful task is the metric that fixes that. It's the AI-native version of unit cost, and once you can measure it, feature pricing, model selection, and kill/scale decisions stop being arguments and start being arithmetic.
Why cost-per-call is the wrong unit
The instinct is to measure cost per API call. It's the number that's easiest to pull, so it's the number people quote. It's also misleading, for two reasons.
First, a call is not a task. Your "summarize this ticket" feature might make one call on a good day and four on a bad one — a retry after a timeout, a re-prompt after a bad JSON parse, a fallback to a bigger model when the small one hallucinated. Every one of those calls costs money. Only the last one produced the thing the user asked for. If you divide spend by successful outcomes, the retries are baked into the cost of the task — which is exactly where they belong, because that's what the task actually costs you to deliver.
Second, a call that failed still shows up on the bill. A truncated response, a moderation refusal, an agent that looped and gave up — the tokens were metered, the money is gone, and the user got nothing. Cost-per-call quietly hides this. Cost-per-successful-task surfaces it as margin you're losing, which is the only frame that makes anyone fix it.
So the unit is: total spend attributed to this feature, divided by the number of tasks it completed successfully. Retries and failures are in the numerator, not swept under the rug.
Blended bill vs. per-task attribution
The gap between what your finance system shows you and what you need is a gap in resolution. Here's what each view lets you actually decide:
| | The blended provider bill | Per-task attribution | |---|---|---| | Resolution | One org-level total per provider | Per feature, per task, per customer | | Retries & failures | Invisible — folded into the total | Counted against the task that caused them | | "Is this feature profitable?" | Can't tell — it's not a line item | Cost per successful task vs. price you charge | | "Which customer is underwater?" | No customer dimension exists | Per-customer cost vs. per-customer revenue | | "Cheapest model that still works?" | No success signal to compare against | Cost and success rate, per model | | Decision it supports | "AI is expensive this month" | Price it · pick the model · kill or scale |
The blended bill answers one question — how much did we spend? — and it answers it a month late. Per-task attribution answers the questions a PM is actually paid to answer.
How you actually get the number
You don't get per-task cost by parsing an invoice. You get it by attributing every AI call at the moment it happens, along five dimensions the Token Ledger records on every request: WHO made the call (person or agent), HOW MUCH budget it drew, WHY it ran (the project and task), WHERE it ran, and WHEN.
The one that unlocks unit economics is WHY. When a call carries a tag that flows from your app — a feature name, a Jira epic, an end-customer ID — through the gateway and onto the ledger row, you can slice spend the same way you slice your roadmap. The PM hub walks through the mechanics: the engineer issues a session key tagged with feature, task, and customer, and every commit that key generates inherits those tags. No one hand-labels anything at month-end.
Once the tag is on the row, "cost per successful task for the ticket-summarizer feature, for Customer X, last month" is a filter — not a forensic project. Pair the spend rows with your own success signal (the app already knows whether the task completed) and you have the numerator and the denominator in the same place.
The unit-economics worksheet
Here's the actual worksheet. Fill in the left column from the ledger and your product analytics; the right column falls out.
Inputs (per feature, per plan tier, per month):
- A — Attributed spend. Sum of all AI cost tagged to this feature. Includes retries and failed calls. Pull from the ledger filtered on
feature = X. - B — Successful tasks. Count of tasks the feature completed for real. Pull from your product analytics.
- C — Price per unit. What the customer pays that maps to one task — either a per-task price or (plan revenue ÷ tasks the plan includes).
- D — Tasks per active customer. Median and p95. The p95 is the one that hurts you.
Outputs:
- Cost per successful task = A ÷ B. Your true unit cost. If B counts only successes but A includes the failures, this number already prices in your retry tax.
- Margin per task = C − (A ÷ B). Positive means the feature makes money at the margin. Negative means every task you serve loses money — growth makes it worse.
- Margin per plan = (C × tasks included) − (A ÷ B × tasks the customer actually runs). Run this at median D and again at p95 D. A flat $49/mo plan can be comfortably profitable at the median and deeply underwater on your heaviest 5% of users — and heavy users are exactly who churns last, so they accumulate.
Worked shape: if a feature's attributed spend is $8,400 across 42,000 successful tasks, unit cost is $0.20. A plan that bundles "unlimited" usage at $49/mo breaks even at 245 tasks — fine for the median user at 60, a loss for the p95 user at 900. That single row tells you the plan needs a fair-use cap or a usage tier. You could not have seen it in the blended bill.
What the number lets you decide
Price the feature. Once you know cost per successful task and the p95 usage per customer, you can see whether your plan is underwater on heavy users before they show up as a margin surprise. The fix is usually a fair-use ceiling or a metered tier, and now you can size it.
Choose the model. Cheapest-per-token is a trap; cheapest model that still succeeds is the real target. With per-model success rates next to per-model cost, you can see when a cheaper model's higher retry rate erases its price advantage — the retries push its cost-per-successful-task above the "expensive" model you were trying to avoid. Test in the playground, then let the ledger confirm it in production.
Decide kill or scale. A feature with a healthy margin per task and rising volume is a scale decision. A feature that's negative at p95 and can't be capped is a pricing or a kill decision. Either way you're deciding on unit economics, not on a vibe about whether "the AI bill feels high."
Model your feature's unit cost
The blended invoice will never tell you whether your feature earns its keep. Per-task attribution will — and it's the difference between owning a margin you can defend and owning one you can only apologize for.
Start with the worksheet above against last month's numbers, sketch the model choice in the playground to see which model succeeds most cheaply, and see the PM hub for how the per-feature, per-task, per-customer tags get onto every row in the first place. The metric is only as good as the attribution underneath it — and that's the part we built.