An AI bill can be perfectly accurate and still be almost useless to me.
If the total goes up, I know something consumed more. I still don't know what. One difficult verification pass? A research branch that kept expanding? Five retries around the same failed task? A pile of cheap work that probably should not have existed in the first place?
My first instinct is to ask for more telemetry. I don't think that's quite right.
The problem is the unit.
Think of a card statement versus an itemised receipt. The statement can give you the correct total. The receipt gives the total a set of things you recognise. The comparison stops before financial accounting — agent systems have shared overhead, caches, nested work, and plenty of costs that do not divide neatly — but the diagnostic difference is useful.
If the work is delegated in tasks, subagents, loops, and sessions, but the money only appears as one aggregate number at the edge, the system is using one unit for work and another for cost.
That mismatch is where the explanation disappears.
Delegation already gives the work an identity
A delegated task is not just a model call with a nicer name. It has a purpose. It usually has a parent. It starts, does some work, and returns something that can be accepted, rejected, retried, escalated, or abandoned.
That is already an operational boundary.
Anthropic's current documentation gives a few concrete examples of the shape, without proving anything broader than that. The Claude Code cheatsheet defines a session as one run and /cost as a session-level view of token usage and spend. Its subagent material describes a secondary Claude instance handling a focused task in its own context. Anthropic's subagent guide makes the delegation boundary explicit: a subagent takes a focused task, works independently, and returns its result to the main session.
The economic part becomes possible because the work is already separable.
Other Anthropic surfaces expose the same idea at different levels. Managed Agents session events can carry cumulative usage at the session boundary. An Agent SDK ResultMessage can expose run-level usage and total cost. A first-party cost-optimization cookbook shows an isolated subagent helper accumulating its own cost and returning that cost with the subtask result.
That last example is an implementation pattern, not evidence that every hosted agent product has native task-level accounting. I wouldn't generalise it that far.
The narrower point is enough: session, run, and subagent boundaries can be inspectable, and usage can be associated with them. Once that is true, cost can attach to the same object the operator already recognises as work.
The unit should follow the decision
The tempting rule is "measure everything."
That sounds thorough. It can also produce a very expensive pile of numbers.
A model execution can be split almost indefinitely: requests, turns, cache reads, tool calls, retries, reasoning steps, nested agents, background jobs. The smallest measurable event is not automatically the most useful economic object.
The better question is: if this number changed materially, what decision would I make differently?
If I decide whether to retry a task, task-level cost is useful.
If I compare two subagent strategies, subagent-level cost is useful.
If I only decide whether a whole session was worth running, session-level cost may be enough.
This is close to a problem Dream Atlas has already recorded from the review side: faster agent output can make review more expensive because the scarce unit shifts toward the exact work a human has to inspect and judge. Cost attribution has a similar identity problem. If I can accept or reject a piece of work as one unit, I should be able to ask what that unit consumed.
Not every internal event deserves that treatment.
The useful boundary is the smallest work unit whose cost can change an actual operational decision.
A same-unit ledger can stay small
Once cost and work share an identity, the record does not need to become a financial system.
It needs enough context to answer where the resources went.
work_unit_id
parent_work_unit_id
work_type
objective
usage
tracked_cost
attempt_number
outcome
acceptance_or_quality
The exact fields will vary. I would not turn this into a universal schema.
What matters is the relationship between them.
work_unit_id gives the cost a referent. parent_work_unit_id preserves lineage when a task creates more work. attempt_number separates one expensive task from a cheap task that quietly ran ten times. outcome stops successful and failed work being mixed together. acceptance_or_quality is there because otherwise cost becomes the only thing the system knows how to optimise.
The result is two views that need to coexist.
Roll-up: what did this session, workflow, or project cost in total?
Drill-down: which delegated units account for that total, and what happened to them?
I still want the total. I just don't want the total to be the end of the explanation.
Reconciliation matters more than microscopic precision
This is the part where a neat model can become dishonest if it tries too hard.
A parent session may spend resources planning, compressing context, coordinating children, or interpreting their results. Cache effects can make allocation messy. A tool cost may belong cleanly to one child, while another cost exists only at the parent level. Nested agents can create descendants of their own.
Forcing all of that into perfectly allocated child totals would give the ledger the appearance of precision without necessarily giving it more truth.
I would rather keep an explicit overhead bucket.
parent total
= delegated child work
+ retries and rework
+ parent orchestration overhead
+ unallocated or shared overhead
The point is not to make every fraction independently auditable, but to make the large movement explainable.
If a top-level session becomes much more expensive, I want to know whether the work itself expanded, whether a retry loop kept failing, or whether coordination around the work became the expensive part.
That is enough to change a decision.
Cost without outcome is a trap
Once a system can show cost per task, the next bad idea is obvious: rank the tasks by cheapest execution.
I can see the appeal, but that is also how a useful observability signal turns into a local objective function.
A task that costs less because it stopped early, skipped verification, or produced unusable work is not more efficient. A verification pass can be expensive because it found the thing that mattered. A slower first pass can be cheaper at the system level if it avoids three rounds of human correction.
Reasoning Needed a Budget reaches the same accounting boundary from the allocation side: a turn that returns quickly and then fails validation twice was never the cheap option.
So cost needs an adjacent outcome.
It does not need to be sophisticated. Accepted. Rejected. Rework required. Test passed. Reviewer disposition. A bounded quality score, if the workflow already has one.
The important part is that "cheap" does not get to mean "good" by accident.
With outcome next to cost, the questions get much better:
- Which task families are expensive and frequently rejected?
- Which retries consume budget without improving acceptance?
- Which work units look expensive in isolation but reliably prevent downstream rework?
- Which apparently cheap paths push the cost into human review later?
Without that second column, cost per task can become another aggregate metric wearing finer clothes.
Attribution is not budget authority
I keep wanting to collapse these because they sit next to each other.
They are still different problems.
A budget answers whether work is allowed to continue after some economic boundary. Attribution answers what consumed the budget before that point.
One controls reach. The other explains behaviour.
A hard cap can prevent runaway spend and still leave me unable to identify the expensive branch. Detailed attribution can explain the branch perfectly and still do nothing to stop it.
Both are useful. Neither replaces the other.
Keeping them separate also keeps the argument away from provider pricing. I don't need one model to be cheaper than another for this to matter. I need the resource use to connect back to a work identity that the operator already understands.
The loop is where the useful explanation often appears
A single expensive task may be justified.
The same task running five times deserves a different question.
This is why lineage matters. A retry with no parent looks like another independent task. A retry attached to the same objective exposes a pattern. A research unit that quietly spawns three more units is different from one that returns once. A verification branch that grows after every failure is not just "more tokens." It is a loop.
The cost graph starts to resemble the execution graph.
Most of the time I would not inspect it. The roll-up should be enough when nothing looks strange.
The drill-down earns its keep when the aggregate moves and somebody needs to explain why.
Instrumentation should earn its own cost
Fine-grained observability is not free. Events have to be emitted, stored, joined, and retained. Work-unit identity has to survive retries and nesting. Somebody has to look at the result.
A metric that nobody can act on is just another system to maintain.
So the design test I would keep is deliberately boring:
If this metric changed, what would I do differently?
No answer means the metric probably does not need a first-class surface.
For a small operation, session totals plus a few major work units may be enough. A more complex multi-agent system may justify parent-child attribution, retry grouping, and outcome labels. The granularity should follow the delegation and review structure, not a telemetry checklist.
The part I find most useful about this model is that it does not ask for perfect accounting; it asks for economic traces that line up with the way the work is already being assigned and judged.
The total still matters. Now it has somewhere to point.
The statement was always accurate. I needed the receipt.
// End of transmission. Link cost to the work — ZYANE