Cost per Completed Task: The Agent Metric That Matters

A $0.03 agent run is not cheap if it fails half the time and needs a person to repair the other half. A $0.12 run may be cheaper if it reliably delivers a usable result. The metric that sees this difference is cost per completed task: all relevant operating cost divided by tasks that meet a stated definition of done.

This is the number to optimize after an agent leaves a demo. It puts model tokens, tools, retries, infrastructure, and human recovery on the same ledger. More importantly, it refuses to call an answer a success just because a model produced text.

Start with a definition of completed

“Completed” is a product and operations decision, not a model label. A support agent might be complete when it resolves the customer’s request without reopening the ticket. A code agent might be complete when its change passes CI and review. A research agent might be complete when its claims are sourced and the requested deliverable is present.

Write that condition before measuring cost. A minimal event record looks like this:

{
  "task_id": "support-4821",
  "final_status": "completed",
  "verifier": "ticket closed; no escalation",
  "attempts": 2,
  "human_minutes": 0
}

The verifier determines whether the denominator is credible. “The model said done” is not a completion criterion. A schema check can be enough for a formatting task; an external state check or human review is appropriate for a consequential action. Match the verifier to the risk, then count only the tasks that pass it.

Use the full numerator

For a cohort of tasks, calculate:

cost per completed task =
  (model + tool + infrastructure + human recovery + failure costs)
  / verified completed tasks

The individual components should be boring and visible:

Cost	Include
Model	Input and output tokens for every attempt, including retries and graders
Tools	Search, browser, API, database, or vendor charges attributable to the task
Infrastructure	Worker time, queues, storage, and observability where material
Human recovery	Review, correction, escalation, and reconciliation time at an agreed internal rate
Failure costs	Rework or external remediation that can be attributed to failed agent actions

Not every organization can estimate downstream failure costs precisely. Do not invent them. Report the narrower operational metric, label what it excludes, and add the missing category when the accounting is sound. A transparent partial numerator is better than a precise-looking fiction.

Retries belong to the original task

The common reporting mistake is to make each model call its own unit. That makes a ten-call recovery loop look like ten inexpensive runs instead of one expensive task. Group attempts by the durable business intent: the ticket, the requested report, the code change, or the order exception.

This is why idempotency is a cost control as well as a safety property. When a network timeout leaves an outcome unknown, a harness that replays the same intent safely can recover. A harness that blindly repeats a side effect can create a second invoice, a second deployment, and a remediation bill that never appears in its token dashboard.

Keep a task-level ledger:

task_id: report:customer-108:2026-09-01
attempt 1: $0.04, verifier failed: missing source
attempt 2: $0.05, verifier passed
human review: $0.00
task cost: $0.09
completed: yes

The two attempts are not two completed tasks. They are one completed task that cost $0.09. A task that exhausts its retry budget and goes to a person is also one task; its final cost includes the failed automation and the person’s recovery time.

Segment before you optimize

A single blended figure can hide a broken workflow. Report cost per completed task by task class, model or harness version, tool path, and escalation outcome. The useful comparison is not “this week versus last week” in the abstract. It is “the same class of task, under a controlled change.”

For example, a stricter source verifier may raise average model cost while reducing human review. That can increase cost per attempt but decrease cost per completed task. A smaller context may lower token use but cause enough retries to erase the saving. Without task-level outcomes, either change can look good on a dashboard.

This is the same discipline as model-swap drills: hold the task suite and acceptance criteria steady, then compare the whole run. Change one meaningful variable at a time when possible. Otherwise, report the change as an observation, not proof of causation.

Pair cost with service quality

Cost per completed task is deliberately outcome-weighted, but it should not stand alone. Track it beside completion rate, elapsed time, and safety or quality failures. An agent that completes only easy tasks may show an excellent cost number while quietly escalating the hard work. Measure that review work as part of the human-in-the-loop escalation path, not as an externality. An agent that “completes” quickly by taking unsafe actions has a bad verifier, not good economics.

A compact weekly view can be enough:

Segment	Verified completion rate	Median elapsed time	Cost per completed task	Escalation rate
Routine support	measure	measure	measure	measure
Account changes	measure	measure	measure	measure
Research briefs	measure	measure	measure	measure

The empty values are intentional. Populate them from traces, invoices, and review records; do not substitute a plausible benchmark. The point of the table is to make tradeoffs visible once the system is running.

Instrument the denominator first

Teams often have token billing before they have a trustworthy completion event. Reverse the priority. Add a task ID at the agent harness boundary, propagate it into tool calls, record retries and escalations, and emit one verified terminal outcome. The observability record should let an operator reconstruct the path from task intent to result without reading a transcript.

Then allocate costs. Exact per-task infrastructure allocation can wait if it is small relative to model and human cost. What cannot wait is tying spend to a real outcome. If the denominator is wrong, cleaner token accounting only makes the wrong metric faster to compute.

Takeaway

Do not optimize the price of an agent attempt. Optimize the cost of a verified, usable completed task. Count every retry under the original intent, include the human work needed to make automation whole, segment the result by workflow, and keep completion criteria outside the model’s self-report. That number will tell you whether a cheaper model, a longer context, or a new guardrail actually improved the system.