Unit Economics of an Agent Run: Cost Accounting for Multi-Step Systems

The number that is missing from most agent dashboards

Ask an engineering team what an agent task costs and the answer usually arrives as a token count multiplied by a published rate. That figure is easy to produce and almost never describes the thing the business cares about. A single completed task may involve a planner decomposing the request, an executor calling tools, a verifier checking the result, and a repair loop that runs when verification fails. Each of those is a separate model call, often against a different model, sometimes against the same prompt with a slightly mutated context. The token meter aggregates all of it into one line item and strips out the structure.

Without that structure, adoption decisions become guesswork. A team cannot say whether raising the retry ceiling improved completion rates enough to justify the extra spend, because the extra spend is not separated from the baseline. It cannot say whether a cheaper model should handle a subtask class, because it has no per-subtask quality or cost signal. The unit that matters is cost per successful task, computed alongside cost per abandoned task, and the only way to get there is to instrument the run itself.

Why per-token reporting misleads

One task is many calls

A multi-step agent is a program whose control flow is decided at runtime. The planner may emit five steps or fifteen. The executor may call a search tool once or loop until a budget runs out. The verifier may pass on the first attempt or trigger two repairs. Token accounting sees the sum of these calls; it does not see which role produced them, which task they belonged to, or whether the task ever finished. A rise in total spend is therefore ambiguous: it could be more traffic, more retries, or a prompt change that inflated context on every call.

Retries and failed tool calls are charged but invisible

Failed work is billed exactly like successful work. A tool call that times out after the model has already generated a long argument payload has consumed tokens and produced nothing. A verifier rejection that triggers a full re-plan doubles the planner cost. In per-token reporting these appear as ordinary volume. In a per-task ledger they appear as a distinct category, which is what makes them fixable.

Caching and context reuse move the effective price

Prompt caching and context reuse change the effective cost of a call by large factors, and the factors depend on ordering, prefix stability and how much of the context is shared across roles. A system that keeps a stable system prompt and appends task-specific context can pay materially less per call than one that rebuilds the prompt each time, even when the visible token counts are similar. Any cost model that ignores cache behaviour will misprice the two designs against each other. The practical consequence is that prompt architecture is a cost decision, not only a quality decision.

Building the cost model

Instrument every call with a task identifier and a role label

The foundation is a correlation identifier that survives the whole run. Every model invocation, every tool invocation and every sandbox start is tagged with the task id and a role label such as planner, executor, verifier or repair. This is ordinary distributed tracing applied to an agent loop, and it is the difference between a cost report and a cost model.

# Pseudocode: one record per model call, joined later by task_id
record = {
    "task_id": task_id,
    "role": "executor",
    "model": model_name,
    "input_tokens": prompt_tokens,
    "cached_tokens": cached_prefix_tokens,
    "output_tokens": completion_tokens,
    "attempt": attempt_index,
    "latency_ms": elapsed_ms,
    "outcome": "ok" | "tool_error" | "verifier_reject",
}

The outcome field is what later lets a team separate the cost of doing the work from the cost of doing it twice. The cached_tokens field is what keeps the model honest about effective price.

Compute cost per completed task and cost per abandoned task separately

Averages over all tasks blend two populations with different economics. A completed task is an asset; an abandoned task is pure loss, and it is usually the more expensive of the two because abandonment correlates with loops. Reporting them together produces a number that flatters the system whenever abandonment is high, since the failed runs drag the mean down while contributing nothing.

Split the ledger:

• Cost per completed task — total spend on tasks that reached a verified terminal state, divided by their count.
• Cost per abandoned task — total spend on tasks that hit a budget, a timeout or an unrecoverable error, divided by their count.
• Abandonment rate — the ratio between the two populations, tracked as a first-class metric alongside quality.

A system can improve its cost per completed task while getting worse overall, if it abandons more hard tasks. Only the pair of numbers, plus the rate, exposes that.

Attribute tool-side costs

Model calls are not the whole bill. Tool invocations have their own price: external API calls, sandbox or container time, vector store queries, object storage for artefacts, and the compute spent parsing and validating tool output. These are frequently larger than the model spend for tool-heavy agents, and they are almost always missing from agent dashboards. Attribute them to the same task id and role label so that a single query can answer what a task actually cost end to end.

A useful discipline is to keep a cost schema with a small, fixed set of dimensions — task id, role, resource class, outcome — and refuse to add dimensions that cannot be populated reliably. A cost model with gaps is worse than a coarse one, because it invites false precision.

Using the model

Route subtasks where the quality delta is measured

Once cost is attributed by role, routing becomes an empirical question rather than a matter of taste. The pattern is to send narrow, well-specified subtasks to smaller models and reserve larger models for planning, ambiguous synthesis and verification. The constraint is that the quality delta must be measured on the actual task distribution, not assumed from benchmark scores. A routing change is a hypothesis: same task set, same verifier, compare completion rate and cost per completed task before and after.

This is also where the honest trade-off lives. Aggressive routing lowers cost per call and raises the number of repair loops, because weaker models produce more verifier rejections. The net effect can go either way, and it is only visible when repair cost is attributed to the routing decision that caused it. Teams that skip the measurement tend to oscillate between two configurations on the basis of anecdote.

Treat budget exhaustion as a routing signal

A per-task budget is more useful as a control signal than as a hard stop. When a task exhausts its budget, that event carries information: the task class is harder than assumed, the planner is over-decomposing, or the executor is looping on a tool that will never return a usable result. Logging exhaustion with the role breakdown at the moment of exhaustion turns a failure into a routing input. Some systems respond by escalating to a stronger model for that class; others respond by tightening the planner's step ceiling. Both are legitimate; neither is discoverable without the ledger.

Report cost regressions next to quality regressions

Quality and cost move together, and reviewing them separately guarantees that one is optimised at the expense of the other. A prompt change that lifts completion rate by a few points while tripling repair cost is a trade-off, not a win, and it should be presented as one. The review artefact is a small table per release: completion rate, abandonment rate, cost per completed task, cost per abandoned task, and the role-level breakdown of any change. Regressions in either column block the release or are explicitly accepted with a written reason.

This mirrors how the wider industry has been forced to think about inference spend as agentic workloads moved from demos into production, with cost governance becoming a first-class engineering concern rather than a finance afterthought (industry coverage).

What this changes

The shift is from accounting for consumption to accounting for outcomes. Token spend remains a useful input, but it is an ingredient, not a unit of value. Once cost is attributed per task, per role and per outcome, the questions teams actually need to answer become tractable: which task classes are worth automating, where a smaller model is good enough, which failure modes are expensive, and whether a quality improvement paid for itself. Those are the questions that determine whether an agent deployment survives contact with a budget.

---

Cover photo: Rafael Minguet Delgado / Pexels.