AI Agent Cost: Measure Cost per Successfully Completed Task

In August I let a browser agent publish a post with a seven-part thread on X. It made eight attempts and failed in four different ways. Twice it lost focus between calls and its text went into keyboard shortcuts. Another time the field ended up holding 1,419 characters of garbage, and a click on Reply once cleared the field and published nothing. The agent got the first three posts out, and I posted the remaining five by hand in about a minute.

On a report, that thread is one completed task. The API bill for an agent can be tiny. The agent can still be expensive to use. Somebody reads what it produced, fixes what it missed, runs it again, reads it again. You get charged for the requests. The person who did all that rarely appears in the same report.

The AI agent cost number I want is what it took to get a result somebody accepted, including the work that went nowhere. A cheap request is useful information, but a poor answer to whether the workflow is worth running.

• What counts as done. Who accepted the result, and how much of it a person had to finish.
• A small ledger. Four invented attempts, where six assumed minutes outweigh the modeled token bill.
• When to stop. A limit the worker checks before it spends again.

The starting material is the traces from AI agent monitoring, and a cost ledger connects them to a result somebody accepted.

What counts as done

The thread counts as a completion, and I posted five of its eight posts. My ledger should show both facts. Say a reviewer rewrote half the answer and then accepted it. Fine, that is a completion. It still tells a different story from an answer accepted with no repair. Hide the difference and the model looks reliable thanks to a person nobody counted.

Take a release-note paragraph. Suppose it contains a test claim that nobody supplied. Now a person has to catch it and rewrite it. Count that paragraph as a success anyway and the agent looks cheaper than it was. The repair got charged to somebody else's time. So set the acceptance rule before you collect any cost. For release notes that could be only the supplied changes, the requested format and no unsupported test claims. For a coding task it might be a reviewed diff and the relevant tests. Which rule fits depends on the job.

One setup can produce a quick draft while another checks it. Maybe you need both. Their prices still describe two different deliverables. The rule is also what makes a comparison usable: two setups get the same work and the same acceptance requirement before one of them is called cheaper. In September I ran two settings of my own on the same work. Same model, Claude Opus 5.5, same three read-only tasks, two levels of reasoning effort. Medium came to $1.77 and 1 minute 38 seconds in total for the three tasks. Max: $5.22 and 19 minutes 46 seconds in total. Then a blind judge scored the answers. Max got 8, 8 and 8. Medium got 6, 7 and 6. Which setting is cheaper depends on where the acceptance bar sits. If a 6 is accepted, medium did all three tasks for about a third of the price. If only an 8 is accepted, medium completed nothing and its $1.77 bought three failed tasks.

Three tasks is a tiny sample. I am also on a flat subscription, so those dollars are the cost the tool reported for the usage, not money I was billed.

Keep the failures in the comparison. Removing a difficult case after one setup fails it removes precisely the cost the comparison was supposed to expose. Sometimes a case really is out of scope. Then define that exclusion for both setups, and do it before you have seen the result.

What costs belong in an AI agent budget?

Model usage, paid tools, storage and execution infrastructure belong in the cash figure. Review and repair go into a separate operator-time figure. Recurring licenses and maintenance need an explicit allocation if you include them. I want to see those parts separately before I see a combined total.

My own first count went wrong before any rate was applied. In September I had an agent add up a month of usage from my coding agent's session logs, and it summed log lines. The tool writes one API response as several lines with the same usage numbers, so one response was counted between two and eight times. The dollar total came out more than twice the corrected one, and two of the rates were wrong as well. The recount a day later went by unique response ID.

The rates are the next place it goes wrong. Look at Anthropic's pricing documentation: cache reads have one line, cache writes another. OpenAI's API pricing splits model charges from tool charges. One rate for every token may be convenient. It can also put a price on a usage category that the provider bills differently.

One task ID connects the requests, tool calls, attempts and final outcome. For each attempt that means the model and provider, the usage categories, the elapsed time and the result. Without that connection a billing export is a list of requests with no answer to which ones bought useful work. A failed request can cost money outside the model too. Search may already have run. A browser service or a code runner may have done paid work before inference failed. Put those charges on the same task. Once you have the actual bill for that period, reconcile your estimates with it and leave the adjustment where people can see it. An estimate that is quietly replaced loses the reason it changed. Both of my September totals are still in my notes, with what went wrong.

How do I calculate cost per successful task?

Take what every in-scope attempt cost. Divide it by how many tasks in that same group got accepted. Do the cash-only figure first. After that, show a second figure with labor and any overhead you stated. If nothing was accepted, report zero accepted tasks. There is no cost-per-success average to calculate.

cash cost per success = total cash spend / accepted tasks

labor-inclusive cost per success =
  (cash spend + operator labor + allocated overhead)
  / accepted tasks

Here is a synthetic ledger. The token counts and the outcomes are invented, the decimal arithmetic was checked locally, and no paid model experiment was run. The rates are the Claude Sonnet 5.5 base API rates listed on 3 October 2026: $2 per million input tokens and $10 per million output tokens. Not in the example: caching, tools, tax, regional modifiers, infrastructure.

Task A: 2000 × 2 / 1000000 + 300 × 10 / 1000000 = $0.007. Add up all four attempts and you get $0.022. Only two tasks were accepted. Modeled cash cost per success: $0.022 / 2 = $0.011. Then the operator. I assumed six minutes of their time and I assumed $30 per hour. That is $30 × 6 / 60 = $3 of labor. Put it together: ($0.022 + $3) / 2 = $1.511. Rounded to cents, $1.51.

The token bill barely moves that number, which is why I would ask about review time before spending a week shaving a little off the input rate.

These quantities are invented. They do not establish what any real agent costs, or how reliable Sonnet is. They show how easily a cash-only report can leave most of the assumed cost out. Replace them with usage records and measured time before using the worksheet to choose a product.

Which group are you dividing? Name it. One week of support summaries works. So does a fixed evaluation set. This month's invoice over last month's completions does not. You get a number, it looks plausible, and that is all it is. The average needs its completion count beside it, because two accepted tasks demonstrate the arithmetic and do not forecast a month. And do not let the average swallow the unusually expensive tasks. One task that repeats dozens of times can disappear in there. It is also the first thing the operator needs to fix.

How do retries and failed tasks change the calculation?

Every retry adds cost to the same task. It does not add another completion. A task that fails outright contributes its spend and no success, and recovery work stays in the ledger even when the final result is accepted.

The thread from August is the plain case: eight attempts, one task, one completion, and that completion was assisted. B in the ledger is the same story with no person stepping in. First attempt failed, $0.003. Second attempt accepted, $0.007. So B costs $0.010. C costs $0.005 and nobody accepted anything from it. A report that kept only the winning attempts would show $0.014 for this cohort instead of $0.022. The agent did not get any more efficient. That report just left out B's failed attempt and everything C did.

Write down why each retry happened. A transient network failure gives you another request. So does a task the agent cannot do at all. You fix those two in different ways. And when an agent repeats the same impossible request indefinitely, call it an incident, not a recovery policy. With a write action, and posting to X is one, there is a more immediate question: did the first attempt already change the destination? You cannot tell from a timeout. Extra tokens are a small problem next to a duplicate effect. So before you repeat a send or a purchase, check the outcome and use an idempotency strategy that suits the action.

How do I enforce a stop budget?

The worker checks the limit before each new request or tool action. If the next one would go over, it stops or hands off. The limit covers active work, attempts, elapsed time and tool calls. An alert that fires after the spend is fine for the report. The request it warns about has already run.

My clearest case is a review gate. It was an adversarial check on one long report. A single run meant fifteen agents, somewhere between 35 and 70 minutes, and roughly 2.5 to 2.8 million tokens. The report had about 140 measurable claims and each run sampled ten of them, a different ten every time. Every run ended in FAIL. The findings were real, they got fixed, and the next run found more. Full coverage would have taken fourteen runs. After several I stopped the gate by hand.

For long documents I now allow two runs. After that a person gets the open objections and decides. Nobody starts another run without stating what it will cost. The work orders I hand to coding agents carry a line of the same kind: two correction rounds, then a blocker report.

Both lines say what reaching the limit produces. That can be a partial result for review, a handoff, or a failed task with a reason. Set the number for the kind of task. A short summary and a code migration should not inherit the same limit because it appeared in a tutorial. Then test that boundary on synthetic records first.

Concurrent workers need a shared view of the limit. Without it, several workers see the same remaining allowance and every one of them can spend it. Before a call goes out, reserve a conservative amount. When the usage comes back, reconcile. If several tasks share one budget there are two limits to enforce: the allowance per task and the aggregate allowance.

Claude Code has its own cost-management documentation. It covers usage visibility and controls for that client and nothing else. Tools that are billed separately still have to show up in the application budget. Other workers too. The production-readiness checklist treats spending limits as something to establish before the workflow ships.

Compare the workflow you will actually run

You may pay through a subscription, a prepaid balance or a metered API bill. Those are different inputs. With a subscription you already have, there are two numbers: the incremental cash cost, and a share of the fee that you allocated. Show them separately and say how you allocated it. You can also convert a quota into dollars at an API rate. That does not turn the estimate into an invoice. My $1.77 and $5.22 are estimates of exactly that kind.

Claude against OpenAI is no different. Keep each provider's actual usage categories and its actual rates. Give both the same set of accepted tasks. A lower input rate can be overwhelmed by extra output, retries, tools or review, and the ledger is how you find out which happened. Prompt caching changes one part of the bill, so record the actual cache usage. Then check acceptance again after every optimization. The answer got cheaper, good. If it no longer satisfies the task, it does not belong among successful completions.

Give me a small report I can act on. I will take it over a token-cost dashboard that shows no outcomes. Attempted tasks, accepted tasks, cash spend, operator minutes and the failed or expensive cases are enough to start. Remove sensitive content from the export and keep the costs, especially the ones incurred before somebody finally made the task work.

For my thread that report is one line: one task, eight attempts, one acceptance, five posts by hand.