Cost-Per-Completed-Task: The Unit That Will Make or Break Agentic AI-as-a-Service

If you sell agents and you can only track one number, track this one. Here's why it matters, how to compute it without fooling yourself, and where the definition quietly breaks.

Table of Contents

• Why GaaS Needs a Native Unit at All
• What Cost-Per-Completed-Task Actually Means
• The Denominator Problem: What Counts as "Completed"
• Building the Numerator: Everything That Loads Into Cost
• Worked Example: A Support Agent's Real CPCT
• How CPCT Connects to Pricing and Margin
• Where the Metric Breaks
• Putting CPCT to Work as an Operator
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

Why GaaS Needs a Native Unit at All

Every category gets the metric it deserves. SaaS got MRR and ARR because the product was a seat you rented by the month, predictable, recurring, easy to forecast. The business model and the unit of measurement were the same shape. That tidiness is exactly what agentic AI-as-a-Service doesn't have.

A GaaS product doesn't sell access; it sells completed work. A customer doesn't care that they have a license to your sales-development agent, they care that 40 qualified meetings landed on the calendar this month. And the cost of producing those 40 meetings is wildly non-uniform. One prospect gets booked after a single clean model call. Another triggers a research loop, three tool calls, a retry because the first email draft hallucinated a wrong title, and a human reviewer who kicks it back once. Same "task," radically different cost.

That variance is the whole problem. When your cost-of-goods-sold moves per transaction and your customer pays per outcome, the old units stop describing the business. You can't build a defensible price, a margin model, or a forecast on a metric that ignores the thing driving your costs. The category needs a unit anchored to the task, and specifically to the completed task, because incomplete work is cost you can't bill for. (The companion question of what replaces MRR for revenue reporting is its own discussion; here we're after the cost side.)

What Cost-Per-Completed-Task Actually Means

Cost-per-completed-task is the total cost to produce one successfully completed task, averaged across all tasks of a given type over a window:

CPCT = (Total fully-loaded cost of all attempts) ÷ (Number of tasks that reached an accepted outcome)

Read that formula twice, because the two halves don't share a population. The numerator includes the cost of every attempt, the wins, the retries, the abandoned runs, the ones a human had to finish. The denominator counts only the successes. That asymmetry is the entire point. CPCT deliberately makes failed and abandoned work expensive, because in reality it is. If your agent burns compute on ten attempts and only seven get accepted, the cost of those three failures is real money, and it gets amortized across the seven that worked.

This is what separates CPCT from the naive number most teams quote, which is cost-per-task-attempt or, worse, cost-per-API-call. Those flatter you. They divide spend by a big denominator that includes garbage, and they make your economics look healthier than they are. CPCT is intentionally pessimistic in the right direction: it charges you for reliability you didn't deliver.

The "completed" qualifier also forces a definition of done, which is where most of the rigor lives.

The Denominator Problem: What Counts as "Completed"

Here's the trap. "Completed" sounds objective and almost never is.

Consider a customer-support agent. Did it complete the task when it sent a reply? When the ticket was marked resolved? When the customer didn't reopen it within 72 hours? When a CSAT survey came back positive? Each of those is a defensible definition, and each produces a different, sometimes dramatically different, CPCT, because each shrinks or grows the denominator. Define "completed" as "sent a reply" and your denominator is huge and your CPCT looks fantastic. Define it as "resolved without reopen and CSAT ≥ 4" and the denominator shrinks, costs concentrate, and your true CPCT might be 3x higher.

There's no universal right answer, but there is a right principle: completion should be defined as the outcome the customer is paying you for, verified as closely as you can afford to verify it. If a customer buys "resolved tickets," then a reply that gets reopened tomorrow is not a completed task, it's a failed attempt that you'll pay to retry. Folding reopens back into the numerator (as additional attempt cost) and out of the denominator (because they weren't really done) is what keeps CPCT honest.

This is also where CPCT quietly diverges from a related metric, agent success rate. Success rate asks "what fraction of attempts succeeded?" CPCT asks "what did each success cost me, including the failures?" They move together but they are not the same lens, and conflating them hides money. A high success rate with expensive failures can still produce an ugly CPCT.

The practical move: pick a completion definition, write it down, and never change it silently. The moment your "completed" definition drifts, your CPCT time series becomes uncomparable and every trend you're tracking turns into noise.

Building the Numerator: Everything That Loads Into Cost

A CPCT that only counts the obvious model tokens is a CPCT that lies. The numerator has to be fully loaded, which in practice means assembling costs most teams track in separate places (or don't track at all):

• Primary inference, the tokens for the model calls that did the work. The visible cost everyone starts with.
• Thinking / reasoning tokens, for reasoning models, the internal chain can dwarf the output. As model providers' own pricing pages make clear, reasoning tokens are billed, and they're often the single largest line for a hard task.
• Retries and self-correction, every re-attempt after a bad output. One task can quietly become many model calls when the agent loops on a failure, which is its own line of inquiry worth tracking closely.
• Tool calls and external APIs, search, code execution, a CRM write, a payment lookup. Each has a cost, and they stack across a multi-step workflow.
• Sub-agent fan-out, when an orchestrator spawns helpers, each child run is real spend that belongs to the parent task.
• Retrieval, memory, and context, vector queries, memory reads/writes, and the unglamorous cost of stuffing a large context window on every call.
• Idle and orchestration overhead, long-running agents that hold state, poll, or wait. This cost is easy to hide and easy to forget; it doesn't show up as a clean per-call charge.
• Human-in-the-loop labor, if a person reviews, corrects, or rescues the task, their loaded time is part of cost-of-goods-sold. Pretending review is free is one of the most common ways GaaS margins get overstated.

Two of these deserve a flag because they're routinely excluded and routinely large: human review and idle compute. A "fully autonomous" agent that needs a human to clean up one task in five has a CPCT that includes a fifth of a reviewer's salary, amortized. Leave that out and your unit economics are fiction.

Worked Example: A Support Agent's Real CPCT

Numbers make this concrete. Say a support agent handles a batch of 1,000 incoming tickets over a week. We define "completed" as resolved without reopen within 72 hours.

Of the 1,000 attempts: - 700 resolve cleanly on the agent's own. - 150 require a retry loop (the agent self-corrects after a bad first answer). - 100 get escalated to a human, who finishes them. - 50 are abandoned or get reopened and never reach a clean resolution.

So completed tasks = 850 (700 clean + 150 retried-then-resolved). The 100 human-finished ones, let's say the human resolves 90 of them, push completions to 940; the other 10 join the 50 as failures. We'll use completed = 940 for the denominator.

Now the fully-loaded numerator across all 1,000 attempts: - Inference + thinking tokens, all attempts: $0.18 average × 1,000 = $180 - Retry overhead (the 150 loops cost roughly 2.3x a normal run): add ~$39 - Tool calls (knowledge-base search, CRM lookups): $0.04 × 1,000 = $40 - Human review labor: 100 escalations × 6 min × $0.60/min loaded = $360

Total cost ≈ $619. CPCT = $619 ÷ 940 ≈ $0.66 per completed task.

Notice what dominates. The model tokens everyone obsesses over are about $220 of the $619. The human labor, the line teams love to leave out, is $360, the largest single contributor. If you'd computed CPCT as "inference ÷ all attempts" you'd have quoted $0.18 and lost money on every customer. The honest number is nearly four times higher, and it's the one that should anchor your price.

How CPCT Connects to Pricing and Margin

Once you trust your CPCT, pricing gets clearer than it's ever been in this category. Gross margin per task is simply:

Per-task gross margin = (Price per completed task − CPCT) ÷ Price per completed task

If you charge $2.00 per resolved ticket and your CPCT is $0.66, you're running ~67% gross margin on that workload, healthy, with room for the variance that consumption businesses always carry. Charge $0.90 and you're at ~27%, which is a SaaS founder's nightmare dressed up as an AI company. The metric tells you, before you sign the contract, which deals are worth doing.

CPCT is also what makes per-outcome pricing even thinkable. You cannot price by outcome unless you know what an outcome costs you, including the outcomes that failed on the way. And it's the metric that should sit at the center of any GaaS economics dashboard, because it's the join point between the engineering levers (caching, model choice, retry policy, autonomy caps) and the business levers (price, margin, retention). When margins compress, CPCT tells you whether the fix is technical (the agent got chattier) or commercial (you underpriced).

For a category that still can't agree on its revenue metric, having a defensible cost metric is leverage. Analysts at firms like a16z have argued that AI-native businesses need new unit-economics frameworks rather than borrowed SaaS ones, and CPCT is exactly that kind of native unit, built from the workload up, not retrofitted from a seat-based world.

Where the Metric Breaks

CPCT is the right core unit, but it is not a magic number, and pretending otherwise is how you get burned.

It's an average, and the tail is brutal. A $0.66 mean CPCT can hide a long tail of tasks that each cost $15 because they triggered a runaway loop. If your pricing is flat per task and your cost distribution has a fat tail, the average lies to you about your worst customers. You need the distribution, not just the mean, the p95 and p99 CPCT often matter more for survival than the average does.

"Completed" is gameable. Any team compensated on CPCT will, consciously or not, drift the completion definition toward whatever makes the number look good. This is Goodhart's law in a tracksuit. Lock the definition and audit it.

It's volatile through no fault of yours. When model providers change inference pricing, and they do, sometimes weekly in either direction, your CPCT moves even though your agent didn't change a line. Budgeting against a moving COGS is a genuinely hard problem, and CPCT inherits all of it. Falling token prices, counterintuitively, haven't reliably lowered agent bills, because agents got more capable and chattier at the same time.

Shared infrastructure muddies attribution. When one pool of agents serves many customers, splitting the cost fairly per completed task is a real accounting challenge, not a rounding error. Get attribution wrong and your per-customer CPCT, and therefore your per-customer margin, is fiction.

None of these break the concept. They mean CPCT has to be reported with a distribution, a frozen definition, a cost-basis date, and an attribution method. Treat it like a financial metric, because it is one.

Putting CPCT to Work as an Operator

If you're standing up CPCT tracking from scratch, the sequence that works:

1. Pick one task type and one completion definition. Don't try to compute a blended CPCT across a coding agent and a support agent on day one. Per-workload first.
2. Instrument the full numerator. Tag every cost, inference, thinking, tools, sub-agents, retrieval, human time, to a task ID. If you can't attribute a cost to a task, you can't trust your CPCT.
3. Report the distribution, not just the mean. Mean, p50, p95, p99. The tail is where the money leaks.
4. Stamp every CPCT with a cost-basis date. When provider prices shift, you want to know which CPCTs are comparable.
5. Wire CPCT to pricing and to alerts. A sudden CPCT spike is an early warning of a reliability regression, a model price change, or a runaway-agent scenario, often before it shows up anywhere else.

Done well, CPCT becomes the metric your whole economics stack hangs off of: it feeds margin math, informs whether to cap autonomy to protect costs, and gives finance a number they can actually forecast against. Done poorly, averaged, undefined, missing the human-labor line, it's a comfortable lie.

Insights Most People Overlook

• Your true CPCT is usually a "completed-task labor cost," not a compute cost. In every honest GaaS teardown I've seen, the human-rescue line dominates the numerator long before scale kicks in. Teams that benchmark only inference are measuring the cheap part. The expensive part is the reviewer who fixes one task in five, and it's the part that determines whether the business is actually autonomous or just compute-subsidized BPO.

• The "completed" denominator is a strategic choice, not an accounting one. Where you draw the completion line literally defines your product. A vendor who counts "replied" as done is selling a different (and weaker) product than one who counts "resolved without reopen," even with the identical agent. The definition is a positioning decision disguised as a metric definition.

• Falling token prices can raise your CPCT. This feels backwards, but cheaper inference invites more reasoning, longer context, more retries, and more sub-agent fan-out, because the marginal call feels free. The behavioral response to lower prices routinely outruns the price cut. CPCT is one of the few metrics that catches this, because it counts all the calls, not the per-call rate.

• p99 CPCT, not mean CPCT, is what kills consumption businesses. Flat per-task pricing against a fat-tailed cost distribution means a handful of pathological tasks can erase the margin on thousands of clean ones. Most teams never look past the average, so they discover the tail only when a single customer's runaway workload shows up on the cloud bill.

• CPCT is a leading churn indicator if you let it be. A rising human-intervention component inside CPCT means the agent is getting less autonomous on real traffic, which tends to precede a customer noticing and leaving. The cost metric and the retention metric are the same signal viewed from two sides.

Frequently Asked Questions

How is cost-per-completed-task different from cost-per-task? "Cost-per-task" usually divides total spend by all attempts, which silently counts failures and retries as if they were free or successful. CPCT divides total spend (including those failures) only by tasks that reached an accepted outcome. The first flatters you; the second tells the truth.

Should human review time really count in CPCT? Yes, if a human is required to finish or rescue tasks, their loaded time is part of cost-of-goods-sold. An agent that needs human cleanup isn't fully autonomous, and excluding that labor is the single most common way GaaS margins get overstated.

How do I handle retries, are they a separate metric? Retries belong in the CPCT numerator as attempt cost. They're also worth tracking on their own, because retry blow-up is where one task quietly becomes dozens of model calls. CPCT captures the financial impact; a dedicated retry-rate metric captures the mechanism.

Can I compute one CPCT for my whole platform? You can compute a blended one, but it's mostly useful for board slides. Operationally, CPCT is a per-workload metric, a coding agent and a support agent have completely different cost structures, and averaging them hides the levers you'd actually pull.

How often does CPCT change on its own? Frequently. Provider inference prices shift, sometimes weekly, and your CPCT moves with them even if your agent is unchanged. Always stamp a CPCT with the cost-basis date so you know which figures are comparable across time.

Does CPCT work for per-outcome pricing? It's essentially a prerequisite. You can't credibly price by outcome unless you know what producing one outcome costs, including the failed attempts along the way. CPCT is that number.

What's a "good" CPCT? There's no universal target; it only means something relative to your price. The useful question is per-task gross margin: price minus CPCT, over price. A CPCT that supports 60-80% gross margin at your price point is healthy for a consumption business carrying real variance.

Conclusion

Agentic AI-as-a-Service is a category in search of its native units, and cost-per-completed-task is the most important one on the cost side. It works because it's shaped like the business: it ties variable, messy, per-transaction spend to the only thing customers actually buy, work that got done and got accepted. The discipline is in the details. Define "completed" as the outcome the customer pays for, and freeze that definition. Load the numerator fully, including thinking tokens, retries, sub-agent fan-out, and the human labor everyone wants to forget. Report the distribution, not just a comforting average, and remember that the p99 tail is what actually threatens the business.

Master CPCT and the rest of the GaaS economics stack, pricing, gross margin, autonomy decisions, churn prediction, starts to cohere around a single, defensible number. Skip it, or compute it lazily, and you'll quote prices that look brilliant on the clean tasks and bankrupt you on the long tail. In a category this young, getting the core unit right is most of the battle.

References

• a16z, The Cost of Compute and AI-Native Unit Economics
• OpenAI, API Pricing (inference and reasoning-token billing)