On this page
- Key Takeaways
- Cost Per Task Is the Only Number a CFO Can Check
- The Human Baseline Comes Before the Agent Bill
- A Claude Agent Costs More Per Run Than Chat, and That Is Usually Fine
- Only Accepted Work Counts
- Saved Hours Only Count When They Go Somewhere
- The Break-Even Test Is Simple. Getting Honest Inputs Is the Work
- An Agent That Can't Show Its Cost Per Task Is Still a Pilot
- FAQ
Key Takeaways
- Cost per task is the number a CFO can check. Tokens, seats and API spend are inputs. One finished, accepted piece of work is the unit that maps to a budget line.
- Price the human version first. Most agent business cases skip the baseline. Without a fully loaded cost for the manual task, there is nothing to compare against.
- The agent's bill is bigger than its token bill. Tools, human review, failed runs and upkeep all belong in the cost per task.
- Count only accepted output. A cheap run that someone throws away costs more than it looks. Divide by the tasks your team kept.
- Savings are real only when the freed time goes somewhere. Decide up front what the hours buy, or the gain disappears into the week.
Here's the question I wish more teams asked before they built an agent: what does this task cost today, done by hand, one time?
Almost nobody can answer it. They can tell you the API spend. They can tell you how many people have Claude seats. Some can tell you how many times the agent ran last month. But ask what one reviewed contract, one reconciled invoice, or one first-draft memo costs, before and after, and the room goes quiet.
That gap is why so much AI work gets stuck in "promising." MIT NANDA's State of AI in Business 2025 report, as covered by Fortune, found that about 95% of generative AI pilots in its dataset delivered little to no measurable impact on P&L. That number draws on interviews, a survey and public deployments, so I would not treat it as a precise census. But the shape of it matches what we see. Lots of pilots. Very few that can prove their value in a way finance accepts.
I don't think the problem is the models. A Claude agent can do a lot of real work today. The problem is that the business case is written in the wrong unit.
The way I'd put it: an agent earns its keep when its cost per accepted task is lower than the human cost of the same task, by enough to pay for building and running it. That's it. Everything in this post is about getting those three numbers right.
Cost Per Task Is the Only Number a CFO Can Check
Every other AI metric is an input.
Tokens per month tells you how much the model worked. Seats tells you how many people have access. Runs tells you how often the agent fired. None of those tells a finance team whether the business got anything for the money.
Cost per task does. It takes everything you spent on a workflow and divides it by the finished work it produced. A CFO can hold that number next to what the same work cost last year and decide whether it is worth funding. It also survives price changes. When Anthropic lowers a model's price, or you move a step to a smaller model, the number moves, and you can see exactly why.
There is a second reason I like it. Cost per task forces you to name the task. "Use AI in finance" is a theme. "Match vendor invoices to purchase orders and flag mismatches" is a task. You can only measure the second one.
Define the task before you price it
Write down where the task starts, where it ends, and what "done" looks like. A contract review starts when the document lands and ends when a person signs off on the redline. If you can't describe the finish line in one sentence, the agent can't hit it and you can't measure it.
The Human Baseline Comes Before the Agent Bill
Most agent business cases I see start with the agent. What it costs to build, what it costs per run, how fast it is. The human side gets a line like "saves time."
Flip that. Price the manual version first, honestly.
Start with fully loaded cost. Salary alone undercounts it. The Bureau of Labor Statistics' June 2026 compensation data puts average employer cost for private industry workers at $46.89 per hour worked, and benefits make up 30% of that. For skilled roles like analysts, paralegals or associates, the number is higher.
Then put a time on the task. Anthropic did a version of this at scale. In its study estimating productivity gains from 100,000 Claude conversations, it estimated the tasks people brought to Claude would take about 90 minutes without AI, with a median labor cost of about $54 per task. The same study is careful to say it does not count the time people spend checking Claude's work outside the conversation, so the savings may be overstated. I'd say the same about most internal estimates.
So, as an illustration: a task that takes a person 45 minutes at that $46.89 average is about $35 of labor before anyone reviews it.
Price the human version honestly
Include the review step, the rework when something is wrong, and the wait while it sits in someone's queue. Those costs are real today. If you leave them out of the human baseline but count review in the agent's cost, you'll undersell the agent. If you leave them out of both, you'll fool yourself in the other direction.

A Claude Agent Costs More Per Run Than Chat, and That Is Usually Fine
People get nervous when they see what an agent burns compared to a chat window. They should expect it.
Anthropic's engineering team wrote about this when it explained how it built its multi-agent research system. Agents typically use about 4x the tokens of a chat interaction, and multi-agent systems about 15x. The same post makes the point that matters for the business case: multi-agent setups make sense when the value of the task is high enough to pay for the extra performance.
That's the whole game. A run that costs a few dollars is cheap if the task it replaces costs $35 of someone's time. It is expensive if the task was a two-minute lookup. The token bill only means something next to the value of the work.
Count every loop, retry and review
An agent's cost per task has five lines. Most teams only count the first one.
| Cost line | What it includes | Where it hides | How to measure it |
|---|---|---|---|
| Model tokens | Every model call in the loop, plus context reread at each step | Provider dashboard, rolled up by day | Tag usage by workflow and divide by runs |
| Tools and infrastructure | Connectors, search, hosting, logging | Separate cloud and vendor bills | Allocate monthly cost to the workflows that use it |
| Human review | The person who approves, edits or rejects the output | Nowhere, unless you track it | Time a sample of reviews each month |
| Failures and retries | Runs that loop, error out or get thrown away | Hidden inside token totals | Count failed and rejected runs separately |
| Build and upkeep | Build cost, evals, prompt tuning, model updates | Project budget, not the run rate | Spread over expected task volume for the first year |
Human review is the one that sinks business cases. If a person spends 20 minutes checking every output from an agent that saved them 30, the agent saved 10 minutes, not 30.
Only Accepted Work Counts
Here's a claim I'll make flat: an agent's real cost is what you spent divided by the outputs your team kept.
Runs are easy to count, so teams count runs. But a run that produces a draft nobody uses still cost tokens, and it still cost someone the time to read it and decide to throw it away. If an agent produces 1,000 drafts and your team keeps 600, your cost per task is the total spend divided by 600.
This is also where quality and cost stop being separate conversations. A cheaper model that drops your acceptance rate can raise your cost per accepted task. A more expensive model that gets it right the first time can lower it. You only see that if you measure both in the same row.
Track acceptance before you tune for price
Before anyone touches model routing or prompt length, get an acceptance rate. Ask the reviewer one question per output: kept as is, kept with edits, or thrown out? That single field turns a token report into a cost per task report. It is also the early warning when a workflow starts to drift.
Saved Hours Only Count When They Go Somewhere
This is the part people skip, and it's where most of the "ROI" in AI slide decks quietly falls apart.
An agent that saves an analyst six hours a week creates capacity. Money shows up only when those hours turn into something: more deals screened, a backlog cleared, a hire you didn't need to make, overtime you stopped paying. If the six hours dissolve into a slightly calmer week, the agent was a nice perk.
I don't say that to be cynical. Calmer weeks matter. But if you are asking finance to fund the agent, you need to say what the freed time buys, and then check whether it bought it.
Building the agent is the easier half. The harder half is a people question. Deciding who gets the time back, what they do with it, and how you'll know is a management decision. No model makes it for you.
Decide what the freed hours buy
Pick one before launch. Throughput (the same team handles more volume), cost avoidance (you don't backfill a role or you cut contractor spend), or speed (the work finishes days sooner, which matters for deals and close cycles). Write it down. Measure it at 30 and 90 days.
The Break-Even Test Is Simple. Getting Honest Inputs Is the Work
Once you have the pieces, the test fits on one line. Take the human cost per task, subtract the agent's cost per accepted task, and multiply by how many accepted tasks the agent handles a month. If that beats what the agent costs to build and maintain each month, it earns its keep.

The math is easy. The inputs are where teams cheat, usually without meaning to. They use salary instead of loaded cost. They count runs instead of accepted output. They forget review time on the agent side. They leave build cost out entirely because it came from a different budget.
Volume is the lever people underrate. A workflow that saves $20 a task and runs ten times a month will not pay back a real build. The same savings at a thousand tasks a month is a different conversation. That's why the best first agents tend to be boring, repetitive and high volume.
Re-run the test every month
Cost per task moves. Model prices change, usage grows, prompts drift, and someone adds a step to the workflow. A number you proved in month one can be wrong in month six. Put cost per accepted task on a monthly review next to acceptance rate and volume, and treat a rising number as a bug to fix.
An Agent That Can't Show Its Cost Per Task Is Still a Pilot
This is how we build at PressW. Every custom Claude agent we ship comes with evals, grading criteria and telemetry, so the cost and quality numbers exist from day one instead of being reconstructed later. When a client wants to bring those numbers down, our Token Optimization work starts with a spend audit that sets a baseline cost per task, then tunes model routing, prompts, caching and batching with evals confirming quality holds after each change.
I want to be honest about what's unsolved, though. I don't have a clean way to price quality improvements. When an agent catches an error a tired person would have missed, that's worth something, and it rarely shows up in cost per task. I also think pricing for agent work is going to move toward outcomes over time, and nobody, including us, has fully figured out what that looks like yet.
What I'm sure of: the teams that can show one honest number per workflow get their next agent funded. The ones that show token charts don't.
If you have an agent in pilot right now, try this. Pick one workflow, write down the human cost of a single task, and count how many of last month's outputs your team kept. If the comparison is hard to make, that's the first thing to fix. Our Custom Claude Agent Development team builds that measurement in from the start, and if you want to walk through your numbers with us, Book a Discovery Call.
FAQ
Cost per task is the total cost of running an AI agent on a workflow divided by the finished, accepted tasks it produced. It includes model tokens, tools, human review, failed runs and the amortized cost of building and maintaining the agent. It is the most direct way to compare an agent with the human cost of the same work.
Multiply the time the task takes by the fully loaded hourly cost of the person doing it, including benefits. Then add review time, rework and any hand-offs. That gives you a baseline cost per task to compare against the agent.
Show cost per accepted task for the agent next to the human cost per task, multiplied by monthly volume, and compare that against what the agent costs to build and run. Then say what the freed time is being used for. Finance teams trust a unit cost and a named outcome more than token charts or usage counts.
Agents run a loop of model calls: they plan, call tools, read results and repeat. Anthropic reports agents use about 4x the tokens of a chat interaction, and multi-agent systems about 15x. That extra cost is worth it when the task is valuable enough, which is why cost per task matters more than cost per run.
An accepted task is an output your team used, either as is or with edits. Outputs that were thrown away still count toward cost but not toward the task total. Tracking acceptance gives you an honest cost per task and an early signal when quality starts to slip.
Monthly is a good default. Model prices, usage volume and prompts all change, and so does cost per task. Review it alongside acceptance rate and volume, and investigate any month where cost per accepted task rises.


