Skip to main content
Engineering 12 min read

AI Agent Cost Per Resolution Decides If It Ships

AI agent cost per resolution, not eval accuracy, decides if your agent ships or dies. Token pricing hides the unit economics of retries and failures.

Financial review of AI agent cost per resolution showing why unit economics determine whether an agent ships to production.

Your agent just cleared 95 percent on the eval harness. Precision and recall both look excellent, the pass rate is up, latency is acceptable, and the team is ready to ship. Then the CFO walks into the review and asks a single question that nobody in the room can answer from the dashboard: what does each successful resolution actually cost? That question, and the inability to answer it cleanly, is why high-accuracy agents get killed in finance review. AI agent cost per resolution is the only number that predicts whether your work sees production, because per-token pricing and retry loops quietly make capable systems economically unviable.

Stay in the loop.

Get the latest posts and exclusive content delivered to your inbox.

Join 3 readers. No spam. Unsubscribe in one click, anytime.

This is the gap between engineering and finance. Eval harnesses measure capability. Finance measures what capability costs under real conditions, including the attempts that never resolved anything. The rest of this article bridges that gap with one formula, a worked example, and a go/no-go framework your CFO will accept.

The Agent That Aced Every Eval and Got Killed

This is a recurring pattern in 2025 and 2026 deployments. A team builds a support automation agent, runs it through a leakproof eval harness, hits 95 percent accuracy, and pushes it to staging against real traffic. The eval pass rate holds. The agent handles tickets competently. Three weeks later, finance kills the project because each successful ticket cost more than the human it was supposed to replace.

What kills these projects is almost never accuracy but the silent denominator problem: the cost of attempts that never resolved anything. The agent that resolves 95 of 100 tickets can still cost more per success than a human, because the 5 failures, the 12 retries, and the 8 escalations all consumed tokens, time, and downstream compute without contributing a successful outcome. Accuracy measures how often the agent was right. It does not measure how much each correct answer cost, and per-token pricing systematically obscures that cost.

Why Eval Accuracy Is Necessary But Never Sufficient

Eval harnesses score per-attempt correctness. Cost is an aggregate-across-attempts property. No per-attempt metric can capture an aggregate, which is why bolting more columns onto the harness never closes the gap. Two agents with identical 95 percent accuracy can post a 3x difference in cost per successful resolution, because cost depends on where the 5 percent of failures land, not on how many there are.

The Failure-Distribution Blind Spot

Picture two agents, both 95 percent accurate. Agent A fails on cheap inputs: short tickets that burn a few hundred tokens before timing out. Agent B fails on expensive inputs: long-context edge cases that run through multi-step scaffolding before collapsing. Same accuracy score. Agent A's failures cost a fraction of a cent each. Agent B's failures cost ten times that. The harness reports them identically, because it counts successes and failures with no weight for token spend. Survey work on LLM agent evaluation methods confirms that benchmark-driven evaluation is rigorous at capability measurement when contamination and leakage are controlled. Keep that rigor for capability gating. It simply does not extend to cost, and the failure-distribution asymmetry is why accurate agents die in finance review.

Why a Cost Column on the Harness Fails

The instinct is to add a spend field to the existing eval harness and call it solved. That fails because the harness scores held-out benchmark inputs, not the production long-tail where retries and escalations actually cluster. The benchmark distribution is curated and bounded. Production traffic carries long-tail inputs the benchmark never saw, and those inputs are precisely the ones that trigger retry loops and escalation chains. Each retry consumes tokens without producing a success. The accuracy score holds because the harness only sees the held-out set, but production accuracy cost tradeoffs turn negative on the tail the benchmark underrepresents. By the time the dashboard reflects the damage, finance has already started asking questions.

Cost Per Successful Resolution, the Metric Finance Actually Uses

Cost per successful resolution, or CPSR, is total agent spend divided by successful resolutions only.

CPSR = (total spend across all attempts, retries, and escalations) / (successful resolutions)

The numerator includes every token, every tool call, every retrieval lookup, every escalation, and every failed attempt. The denominator counts only outcomes the business classifies as a success. This is the number finance cares about, because it is the true cost of one useful unit of work.

Why finance scrutinizes the denominator: it is the only place the business gets paid. A 95 percent accurate agent that resolves 950 tickets but burns tokens across 1,200 attempts has a numerator inflated by the 250 failed attempts. If each success costs $4.20 and the human cost per resolved ticket is $3.50, the agent is more expensive than the alternative even though it looks accurate. AI unit economics analysis consistently frames production AI in these terms rather than in capability scores.

How Per-Token Pricing Hides the True Cost of Resolution

Retry loops and escalation chains driving token cost inflation in production AI agent deployments.

Per-token pricing is the single biggest reason capable agents die in finance review. The pricing model bills every attempt, including the ones that contribute zero successful outcomes. When the failure modes are concentrated in a small slice of inputs, the cost profile looks healthy on average and catastrophic in the aggregate.

Where Tokens Leak

In a typical agentic loop, tokens leak in five predictable places:

  1. Context loading on every retry, even when the failing context is unchanged.
  2. Tool-call padding where the model emits long reasoning before a single failed action.
  3. Escalation chains that route to a larger model or a human reviewer.
  4. Self-correction rounds that consume context and produce no resolution.
  5. Edge-case bloat where rare input types trigger multi-step scaffolding that never converges.

Each leak inflates the numerator without touching the denominator. Token cost inflation from retries compounds when these leaks stack inside a single resolution attempt.

Why Averages Conceal the Damage

Reported cost per query can look acceptable while CPSR is often substantially higher. The reason is distribution. Most queries resolve cheaply. A small tail of inputs burns a disproportionate share of tokens through retries and escalations. If your dashboard reports the mean cost per query, the tail is invisible. Finance does not care about the mean. Finance cares about the total spend divided by the outcomes the business can actually charge for or save against.

Calculating AI Agent Cost Per Resolution With Five Real Failure Modes

Walk through a single agent handling a support ticket queue with 1,000 incoming tickets. Each ticket costs roughly $0.06 in baseline tokens on a current LLM API pricing schedule. The eval accuracy is 95 percent.

The per-ticket dollar figures below are illustrative estimates based on current API pricing ranges, not empirical measurements from a named production deployment. They exist to show how each failure mode inflates the numerator, not to benchmark any specific system.

Baseline Spend

At $0.06 per baseline attempt and 1,000 tickets, naive spend is $60. The eval says 950 should resolve. Naive CPSR is $60 divided by 950, or about $0.063 per success. This is the number the team brings to finance.

Failure Mode One, Retry Inflation

About 15 percent of tickets trigger at least one retry. Each retry reloads context and re-runs tool calls. That adds $0.18 per retried ticket on average across 150 tickets, or $27 of additional spend, with zero new successes.

Failure Mode Two, Escalation to a Larger Model

About 8 percent of tickets escalate to a frontier model for verification. Each escalation costs roughly $0.30. Across 80 tickets, that is $24 of additional spend.

Failure Mode Three, Tool-Call Failures

About 5 percent of tickets hit a tool that returns an error the agent must recover from. Recovery consumes an average of $0.12 per case across 50 tickets, or $6.

Failure Mode Four, Long-Context Edge Cases

About 3 percent of tickets are edge cases with unusually long context windows. Each costs $0.40 across 30 tickets, or $12.

Failure Mode Five, Non-Converging Self-Correction

About 2 percent of tickets trigger self-correction loops that never converge and eventually time out. Each burns $0.50 across 20 tickets, or $10.

Adjusted CPSR

Adjusted spend is $60 baseline plus $27 plus $24 plus $6 plus $12 plus $10, which is $139. Successful resolutions are still roughly 950. CPSR is now $139 divided by 950, or about $0.146 per success. That is 2.3 times the naive number the team brought to finance, and the gap is driven entirely by the five failure modes the eval underrepresented.

This is the pattern that retry cost research documents at production scale. Failures are cheap individually and expensive in aggregate.

Failure ModeAffected TicketsAdditional SpendRunning Total
Baseline resolution1,000$60$60
Retry inflation150$27$87
Escalation to larger model80$24$111
Tool-call failures50$6$117
Long-context edge cases30$12$129
Non-converging self-correction20$10$139

The punchline. Naive CPSR was $0.063 per success. Adjusted CPSR is $0.146, a 2.3x jump driven entirely by five failure modes the eval harness underrepresented.

The Break-Even Math, When Agent Cost Beats Human Labor

Break-even comparison weighing AI agent cost per resolution against fully loaded human labor benchmarks.

Once you have a defensible CPSR, the go/no-go question becomes a comparison against the human alternative. Build the comparison transparently, with every assumption visible.

Frame the Human Cost

Take a US-based support tier-one role fully loaded at $35 per hour, handling an average of 10 tickets per hour. That is $3.50 per resolved ticket, including benefits, overhead, and the failure rate of humans routing escalations.

Compare Against CPSR

If your adjusted CPSR is $0.146, the agent wins on raw cost by a wide margin. If your adjusted CPSR is $4.20 because the failure modes are worse than the example, the agent loses against the human benchmark. The decision is mechanical at that point.

Check the Sensitivity

Run the comparison against three CPSR values: your current production CPSR, your best-case CPSR if you cut retries by half, and your worst-case CPSR if edge-case volume doubles. If only the best case beats the human benchmark, the project needs iteration, not deployment. Agent workforce economics and automation versus human worker comparisons both use this kind of sensitivity framing rather than single-point estimates.

Reference Production Benchmarks

For calibration, agentic AI cost benchmarks provide a useful reference range for what production agents actually cost across enterprise deployments. Use them to reality-check your own numbers, not as a target.

Instrumenting CPSR in Production Without Rewriting Your Stack

You do not need a rebuild to measure CPSR. You need five fields logged on every resolution attempt, and a daily rollup.

What to Log Per Attempt

Log the following on every agent invocation:

  1. trace_id linking all retries, escalations, and self-corrections for a single user task.
  2. input_token_cost attributed to the model and tier that produced it.
  3. output_token_cost attributed the same way.
  4. tool_call_costs including retrieval, function calls, and downstream API usage.
  5. resolution_status as success, failure, escalation, or timeout.

How to Attribute Tokens to Attempts

The hard part is attribution. Token optimization tools and adjacent instrumentation libraries give you per-call cost attribution without rewriting the model layer. The pattern is to wrap every model call with a cost recorder keyed to the trace_id, so retries inside a single user task roll up to a single numerator entry.

How to Surface the Metric

Build two rollups. The first is a daily CPSR computed as total spend divided by successful resolutions, broken down by task type. The second is a CPSR distribution by failure mode, so you can see which of the five failure modes is dominating the numerator this week. When your rollup shows per-request cost drifting week over week, inference cost per request explains how hardware choices, from self-hosted GPUs to managed endpoints, shift the per-token baseline that feeds every CPSR calculation.

Surviving the Finance Review, a Go/No-Go Decision Framework

When you walk into a finance review, the only thing that survives is a CPSR number with the assumptions visible. Build the case in three layers.

Layer One, the Current CPSR

Present the production CPSR with the five failure modes broken out. Show the gap between naive and adjusted CPSR explicitly. Finance trusts the adjusted number more when the gap is visible, not hidden.

Layer Two, the Break-Even Comparison

Present the human benchmark with full load and throughput assumptions. Show the sensitivity range. Make it easy for finance to see which CPSR value beats the human and which does not.

Layer Three, the Decision

Tie the decision to explicit CPSR thresholds. If adjusted CPSR beats the human benchmark with margin to spare, ship. If CPSR beats the human benchmark only in the best case, iterate on the dominant failure mode and re-measure. If CPSR loses against the human benchmark in all three scenarios, kill the project before finance does. Enterprise ROI case studies suggest that projects where CPSR crossed the human break-even before the funding decision are more likely to survive than those where it did not.

The Decision You Actually Make

What killed the agent that aced every eval was a numerator nobody instrumented, not accuracy itself. What saves the next agent is measuring what each successful resolution actually costs, comparing that number honestly against the human alternative, and shipping only when the unit economics survive the scrutiny you already know is coming.

Build the CPSR instrumentation first. Calculate it before the finance review, not after. Then your agent survives the question that killed the last one.

Stay in the loop.

Get the latest posts and exclusive content delivered to your inbox.

Join 3 readers. No spam. Unsubscribe in one click, anytime.

About the author

Tyler Brooks

Tools Analyst

Tyler has tested developer tooling for a decade, first as a platform engineer and now as an independent analyst. He reviews models, frameworks, and APIs the way he would want them reviewed before relying on them for real work.

Related Posts