Cost-per-task: the real unit economics of AI agents

There is a moment, early in every AI build, that feels like winning: the worker runs, the output is good, the thing works. It is also the moment most founders stop asking the only question that determines whether they have built a business or a slow leak — what did that cost, and is it less than the alternative? A demo shows you that a system works. It never shows you the invoice. And in AI, the invoice is where companies quietly die.

An automation that works is not automatically a business

It is entirely possible — common, even — to build an AI worker that does its job perfectly and loses money on every task. The output is correct; the unit economics are underwater. This is not a rare edge case, because the cost of AI labour is not fixed like a salary; it scales with every token, every retry, every "just in case" document you pour into the context. A working automation that costs more per task than the person or process it replaced is not a success. It is a more expensive way to do the same work, dressed up as progress.

So the metabolism of a one-person AI company — the thing you have to be able to measure the way a physical business measures cost of goods — is cost-per-task: the true compute cost of one completed unit of agent labour.

What cost-per-task actually is

Strip away the mystique and it is arithmetic. A task is not one model call; it is all the calls the system makes to finish one unit of work — the main call, the retries when something fails, the sub-agent that looked something up, the second pass that checked the first. Each call has a token bill: tokens in, priced at the input rate, and tokens out, priced at the (usually higher) output rate. Cost-per-task is the sum of those bills across the whole task.

def cost_per_task(trace):
    total = 0.0
    for call in trace.model_calls:          # every call in the task: retries + sub-agents included
        total += call.input_tokens  * price_in(call.model)
        total += call.output_tokens * price_out(call.model)
    return total                            # dollars for ONE completed unit of work

The two things people get wrong here are both about scope. They measure a single call instead of the whole task, so they miss the retries and the sub-agents that make up most of the real cost. And they measure a clean demo run instead of production, where messy inputs trigger the extra loops that a rehearsed input never does. Measure the whole task, on real traffic, or you are measuring a fiction.

Capability is not the same as economy

Here is the counter-intuitive part, and the one that catches good engineers: making the system more capable often makes it more expensive, not less. Reach for a bigger model and every token costs more. Give the agent more room to reason and it emits more tokens. Add a tool-using loop and it may call the model five times where one would do. Add a second agent to "collaborate" and you have bought coordination overhead paid in tokens. The instinct that a smarter system should be a cheaper one is exactly backwards. Capability is bought with tokens, and tokens are the bill.

This is the efficiency paradox of agentic systems: the more impressive the setup, the more it tends to cost per task — and because the demo only ever shows the impressive version working once, the cost stays invisible until it arrives monthly, at scale, on the whole distribution of real inputs including the ones that loop three extra times.

Where the cost actually hides

If you want to control cost-per-task, know where it accumulates:

• The oversized model. Paying flagship prices to do high-volume, well-specified work — extraction, classification, routing — is the most common and most quietly expensive mistake. Most of these tasks want the smallest model that passes the check, not the smartest one alive.
• The stuffed context. Pouring the whole knowledge base into every prompt "just in case" means you pay for those tokens on every single call, forever — and, past a point, get worse answers for the money. Retrieve the few things the task needs; do not stuff the window.
• The uncapped loop. An agent that can call tools in a loop can also loop far more than you expected on an input it finds confusing. Without a step cap, one hard case can cost ten times a normal one.
• The silent retries. Every failed call that gets retried is paid for. In production, where failures cluster, retries can be a large and invisible share of the bill.
• The unnecessary second agent. Multi-agent designs are often a single workflow multiplied, each hand-off adding tokens and latency. Add an agent for a genuinely distinct scope, not for sophistication.

The comparison that decides everything

A cost-per-task number on its own is not a verdict; it only means something against an alternative. The decision that actually matters — automate, keep manual, or hire — comes from comparing the measured cost-per-task to the fully-loaded cost of the same task done another way, at the same acceptable quality. Fully-loaded means the real cost of the human alternative: not just the wage, but the time, the tools, the overhead. Put the two numbers side by side and the decision usually makes itself.

This is the rational line: automate when the automation is genuinely cheaper at acceptable quality, and not otherwise. Automating a task whose cost-per-task exceeds the human cost is not efficiency; it is paying more for the privilege of saying it is automated. The number protects you from the most seductive mistake in this field — automating for its own sake.

How to bring it down

Once you can see the number, the levers are concrete, and they are mostly about right-sizing rather than cleverness:

1. 1Right-size the modelUse the smallest model that passes your quality check for that task, and revisit the choice as the catalogue moves. This single lever usually dwarfs every other optimisation.
2. 2Trim the contextRetrieve the few relevant pieces the task needs instead of stuffing the window. You pay for input tokens on every call; a lean prompt compounds into real savings and often better answers.
3. 3Cap the loops and retriesBound how many steps an agent may take and how many times a call may retry, so a single confusing input cannot run up the bill unbounded.
4. 4Cache and batchReuse results for repeated inputs and batch where the workload allows. Work you do not repeat is the cheapest work there is.
5. 5Question every extra agentBefore splitting a task across multiple agents, confirm the split earns its coordination cost. Often a single well-scoped worker is both cheaper and more reliable.

Put a number on every worker

The discipline is simple to state and rare to practise: every AI worker you run should have a known cost-per-task and a known alternative cost, measured on real traffic, watched over time. That is the difference between running a company and hoping about one. Cost-per-task is not a finance chore bolted on at the end; it is the vital sign that tells you whether the automation you are so pleased with is actually earning its place — before the monthly bill tells you it wasn't.

A demo shows you that it works. The invoice shows you whether it's a business. Learn to read the invoice before you commit, not after.

Going deeper

Cost-per-task is one instrument in a larger operating system — the economics chapter of running a company on software. Working out the full picture, from placing a task to making it reliable to proving it pays, on a single build-along company, is what The Durable Operating Manual does across its chapters; this is its Part VIII. For where the economics sit in the whole build, start with how to build a one-person AI company, and for deciding what should be automated in the first place, see the capability boundary.

Frequently asked questions