Your dashboard says an agent task costs about 20 cents. The invoice says the real figure is more than double that, and the gap is where your margin goes.
- Cost per successful outcome is total spend on every attempt, failed ones included, divided by the tasks that actually finished.
- In the worked example below, a task that costs 20.5 cents on the happy path costs about 54 cents once retries, loops and failures are counted, a 2.6x gap.
- About 10% of tasks, the long tail, ate nearly half of the total spend in that example.
- A hard per-task cap set near 4x the happy-path cost cut the cost per success by almost 30% while losing only 5% of completions.
- Define success strictly, for example no reopened ticket within seven days, or your cost per outcome will look better than it is.
Intercom charges $0.99 per resolution for its Fin support agent, according to its own pricing page, and Salesforce launched Agentforce at $2 per conversation. Both vendors priced the outcome, not the tokens. If you sell an agent that way, or fold it into a monthly seat, you need to know how to calculate AI agent cost per task, and the number you get from glancing at your model bill is almost certainly too low.
The reason is simple. Your provider dashboard reports tokens per request. Your customer pays for a finished task. Between those two sit retries, tool-call loops, runs that wander for forty steps, and runs that fail and produce nothing. You pay for all of them.
Take a support agent that handles refund and order-status tickets. The prices below are illustrative, so replace them with your own model rates. Say input tokens cost $3 per million and output tokens $15 per million. A clean run makes six model calls. Because the context grows with each step, the run reads about 40,000 input tokens in total and writes about 3,000 output tokens.
Input: 40,000 tokens at $3 per million is $0.12. Output: 3,000 tokens at $15 per million is $0.045. Add four calls to an order-lookup API at a cent each and you land on $0.205 for the happy path. This is the number most founders put in the pricing spreadsheet, and it's the number their dashboard gently reinforces, because the median request looks like this one.
[How to Calculate the Right AI Agent Error Budget Before You Ship](https://startupfortune.com/how-to-calculate-the-right-ai-agent-error-budget-before-you-ship/)
How to calculate ai agent error budget starts with picking a target below 100% reliability, then multiplying volume by allowed error rate; a 10,000-call agent at 99% gets a 100-mistake daily budget to spend. - how to set error budget for AI agents - AI agent reliability metrics before shipping product
Now run 10,000 attempted tasks through it and look at what really happened. 7,000 finished cleanly at $0.205. Another 2,000 hit a retry or a loop: the model called the wrong tool, got an error, tried again, or asked itself to re-check an answer. Those averaged three times the happy-path cost, $0.615 each, and all of them eventually succeeded. The last 1,000 were long-tail tasks, odd cases with missing order data or a customer who changed the request halfway. They averaged twelve times the happy path, $2.46 each, and only half of them ended in a resolution. The rest were handed to a person.
Total spend: $1,435 for the clean group, $1,230 for the retries, $2,460 for the tail. That's $5,125. Divide by 10,000 attempts and you get 51 cents per attempt, already more than double the happy path. But attempts aren't what you sell. You sold 9,500 resolutions, so the cost per successful outcome is $5,125 divided by 9,500, or about 54 cents. That's 2.6 times the figure in the spreadsheet.
Look at the bottom line of that table once more. A tenth of the tasks produced 48% of the spend. Nothing in the average told you that.
The three leaks, and why the tail is the worst one #
Retries are the boring leak. They're also the most predictable, which makes them the easiest to fix. A malformed JSON response, a tool timeout or a rate-limit error triggers another full pass, and each pass re-sends the whole context. If your agent retries up to three times and your retry rate is 20%, you've added a double-digit percentage to your bill before anything interesting has happened.
Loops are nastier. An agent that can call tools can call the same tool again with a slightly different argument, read the same unhelpful result, and try once more. Every turn adds to the context, so the cost of turn twenty is far higher than the cost of turn two. Spend doesn't grow in a straight line here. It curves upward.
Then there's the long tail, and frankly this is where most unit-economics models fall apart. Your median task is cheap. Your 95th-percentile task can cost ten or twenty times as much, and a customer paying $1 per resolution doesn't care. If your average is dragged around by a few expensive runs, a single week of unusual tickets can move your gross margin by points. Setting a price off the median is how you end up with a business that looks healthy in a demo and bleeds in production.
Failures matter as much as expense. A run that burns $2.46 and ends in a human handoff earns nothing. Under outcome pricing you eat that cost. Under seat pricing you eat it too, plus you've annoyed a customer.
How to Forecast AI Agent Usage for Pricing When Nobody Can Predict Volume The fix borrows from cloud pricing: Snowflake and Databricks already sell committed bands with true-ups instead of point forecasts. Rolling 90-day averages absorb spikes like a 10,000-call retry loop, and OpenAI's enterprise API deals now reset tiers off trailing usage too. - how to forecast AI agent token usage - pricing AI agents when volume is unpredictable
Count what never shows up on the model invoice #
The token bill is only part of what an LLM cost per resolution really contains. If you run a second model as a judge to score the first one's answer, that's another call on every task, sometimes with the full transcript attached. Embedding and vector search fees belong in the number. So do paid tool APIs, as in the order lookups above, and any web-search or browsing service your agent uses.
The biggest omission is usually the human. When the agent hands off, someone on your team or your customer's team picks the ticket up, and they often start from scratch because the transcript is long and unreliable. Put a cost on that handoff, even a rough one, such as ten minutes at a loaded hourly rate. If you leave it out, a lower success rate looks like a saving, because failed runs get cut off early and cost you little in tokens.
Observability tooling carries a cost too, though a small one. Platforms like Langfuse, Helicone and LangSmith log every call so you can group it by task. You need that grouping anyway, and I'd pay for it before I'd pay for another prompt-tuning week.
Define a successful outcome before you divide #
The denominator is where founders cheat without noticing. Counting a task as done because the agent said it was done is the easiest definition, and the least honest. A refund that was issued to the wrong order isn't a resolution. A ticket that comes back two days later isn't one either.
Pick a test you can compute automatically and be strict about it. For support, no reopen and no follow-up message on the same issue within seven days is a reasonable bar. For a data-entry or coding agent, it might be that the output passed validation and nobody edited it afterward. Whatever you choose, write it down. If you change the definition next quarter, the trend line stops meaning anything.
Intercom's pricing model is useful here, as it's a public example of someone forced to take this question seriously. When you charge only for resolutions, you must decide what counts as one, and every disputed case lands on your margin. You don't need to charge per outcome to benefit from the same discipline. Apply it internally and you'll find your real costs faster.
Set a hard per-task budget, and let it kill runs #
Once you have the cost per outcome, the next step is a cap that the system enforces itself. Not a dashboard alert that somebody sees on Monday. A limit in code that stops the run.
Here's how to choose it using the same example. Suppose you charge $1.00 per resolution and want AI costs under 40% of revenue. That's a 40-cent target, and the uncapped result of 54 cents misses it. The clean group at 20.5 cents is fine. The retry group at 61.5 cents is already above target on its own, so it needs an engineering fix. The tail, at $2.46 per attempt and roughly $4.92 per success, is far above the price of the product.
Set the hard cap at 80 cents, a bit under four times the happy path. Any run that reaches it stops and escalates to a human with a short summary of what was tried. Re-run the table. The clean and retry groups are untouched. The 1,000 tail tasks now cost at most 80 cents each, so the tail costs $800 instead of $2,460. Total spend drops to $3,465. You lose some completions, since the half of the tail that would have eventually succeeded at high cost now goes to a person, so resolutions fall from 9,500 to 9,000. The cost per success becomes about 38.5 cents. That's a drop of nearly 30%, for a 5% loss in completions, and it clears the 40-cent target.
Notice what the cap did. It didn't make the agent smarter. It stopped paying $4.92 to earn $1.00.
Add a softer limit below the hard one. At around 3x the happy path, say 60 cents, switch the run to cheaper behaviour: stop re-reading the full history, drop the optional verification step, or move the remaining steps to a smaller model. Many tail tasks resolve at that point anyway, and you keep the completion.
Cap three things, not one. Dollars is the obvious one, but also cap the number of tool calls and the number of model turns, because those fail fast and don't depend on your price list staying current. A model price cut will quietly loosen a dollar cap. A turn cap will keep working.
What to log this week #
You can't compute any of this without a task ID attached to every model call, tool call, judge call and retry. That's the one piece of plumbing to build first. Log the task type, the outcome (resolved, escalated, abandoned, reopened), the token counts per call, the tool costs, and the wall-clock time. Store them somewhere you can run a query against, since a spreadsheet will do for the first month.
Then pull a week of real traffic and do three calculations. First, the cost per attempt, which is the number most people stop at. Second, the cost per successful outcome, using your strict definition. Third, the cost at the 50th, 90th and 99th percentiles of tasks. If the 99th percentile is more than ten times the median, you have a tail problem and a cap will pay for itself within days.
Do this by task type too. A founder with three agent workflows rarely has three similar cost profiles. One of them usually carries the others, and one usually loses money on every run while its revenue hides inside a blended average.
One caution about model choice. It's tempting to respond to a high cost per outcome by switching to a cheaper model, and sometimes that's right. But a cheaper model that fails more often can raise the cost per success, because failed attempts still cost money and every retry restarts the context. Test it on the same week of traffic and compare the cost per outcome, not the price per million tokens.
Run the 90th-percentile query on your own traces before you change a single price on the pricing page. If the tail is where your money goes, the cap comes first and the price follows from it.
Also read: How to Get a Virtual Number for Free and What to Check Before You Rely on It • Your revenue per employee benchmark for startups, before investors ask • Most founders get their SaaS quick ratio calculation wrong
This article is posted in AI News, check it out for more related stories.
Join the discussion #
Open in the community → Almost there. Sign in and your reply posts straight away.