15.4 Measuring, not estimating
The cost report is an orchestration artifact, the same way the evidence pack is: something the orchestrator produces as part of operating the system, not a response to an accusation from finance. The people who will ask for it already exist. The FinOps Foundation’s 2026 survey of 1,192 practitioners — the people who manage cloud bills for a living — found 98 percent now managing AI spend, up from 31 percent two years earlier, named AI cost management the skill their teams most want to add, and recorded many being asked to self-fund AI investment out of savings found elsewhere.4 The survey does not say how many of those teams can attribute a token to a workload; my experience is that most cannot. The report has four properties:
- Per-workload attribution. Every run is tagged to the workload that caused it — the same tagging discipline as the trace.
- Cost per completed task, not per attempt. Attempts are cheap to count and meaningless to budget. The unit of account is the finished thing: the answered question, the triaged ticket, the proposed change. The toolkit survey’s worked example — the internal documentation agent whose month costs about six dollars on a cheap model and four hundred fifty on a flagship, and about twenty-eight when five percent of the questions route to the frontier and the rest route cheap — is the whole method in one line.5
- The multiplication in the footnote. Any worked cost example shows its arithmetic: the token volume, the price, the product. On Claude Fable 5.1’s standard rates, a 300,000-token read at $10 per million is $3.00; 2,000 billed output tokens at $50 per million are ten cents. That is $3.10 a call, times 24 calls a day: $74.40 — call it seventy-five. Times 1,000 agents: about $74,000 a day. GPT-6 Astra’s long-context premium makes the same token volumes $6.15 a call. The provider and pricing threshold belong beside the multiplication.6
- A trend, not a snapshot. One month’s bill says nothing. The report that matters shows the cost per completed task moving — because the routing got smarter, because memory cut the re-reads, or because the workload grew and the bill grew with it. Which of those is happening is the orchestrator’s reading of the system’s health.
15.4.1 The cost record
A report needs a record underneath it, and the record is per run. If the bill is an architectural document, this is the document: the minimum I would ask a system to emit for every run, whether or not the run finished.
| Field | What it holds | Why it is there |
|---|---|---|
run_id |
One attempt by one agent | The unit everything else hangs off |
trace_id |
The customer request this run served | Joins the cost to Chapter 16’s evidence pack, which uses the same key |
task_id, workload |
The task-system item and the workload it belongs to | Attribution — unattributed spend is unmanageable spend |
model, effort |
Model identifier and reasoning-effort setting | The two dials that set the price range |
input_tokens, cached_input_tokens, output_tokens |
Metered volume, cached reads broken out | Cached reads are the cheapest tokens you buy |
tool_calls, subagent_runs |
Tool invocations made and child runs spawned | Fan-out is where budgets disappear |
retry_of |
The run_id this run is repeating, if any |
A retry is a full-price run and must not look like new work |
wall_time_ms |
Start to finish | Separates latency and runtime charges from token spend |
rate_card, cost_usd |
Applicable token rates, premiums, tool charges, and billed total | Prices move; store what the run actually cost |
outcome |
completed, failed, stopped_by_limit |
Records the attempt’s result; task completion is checked in the task system |
budget_id, budget_owner |
The spend limit this run drew against and who authorized it | A credential has an issuer |
Every row attributes spend to a workload. For a defined cohort of tasks, sum cost_usd, including retries, failures, and child-agent runs, then divide by the number of distinct task_id values confirmed complete in the task system. Report unfinished tasks and their spend alongside that figure; a reporting-period boundary must not make them disappear. Three agents completing work on one task count as one completed task. Record each run’s cost once; do not add a parent’s aggregate bill to the child costs it already includes.
The record also shows cached reads, fan-out, and loops stopped by the budget limit. Joined through trace_id to Chapter 16’s evidence pack and Chapter 8’s operating record, it puts the cost beside the authority used and the result achieved. That is how “was that worth it” becomes an answerable question.
What the record does not decide matters as much. It does not know whether a completed task was correct; that is the operating record’s business, and a workload with a beautiful cost per completed task and a thirty percent error rate is a cheap way to produce mistakes. It does not know whether the workload was worth delegating at all; that was the triage in Section 15.3. And it does not know what the price will be next quarter, which is why rate_card is a field and not an assumption.