Finance asks why the model bill went up. You can see which agents used tokens, but a shared document service serves two teams and some requests have no known owner. Which team should pay?
Keep those unanswered questions visible in the report. The following example shows how to allocate known costs without quietly spreading the unknown amount across everyone else.
Start with a worked example
Assume a hypothetical reporting window with $1,000 of estimated model cost across four mutually exclusive workload buckets. These are invented figures for arithmetic, not Dome prices or observed customer spend.
| Workload bucket | Estimated cost | Allocation decision | Allocated result |
|---|---|---|---|
| Invoice assistant | $430 | Finance owns the workload for this window | Finance: $430 |
| Support assistant | $300 | Customer operations owns the workload | Customer operations: $300 |
| Shared document service | $170 | Agreed equal split for this example | Finance: $85; customer operations: $85 |
| Unmapped activity | $100 | No supported owner mapping yet | Unassigned: $100 |
| Total | $1,000 | Preserve the unresolved amount | Finance: $515; customer operations: $385; unassigned: $100 |
The equal split is an organizational decision, not a measured causal attribution. If finance later selects a request-based allocation, retain the earlier method and effective date rather than silently rewriting the old report.
The unassigned row is also useful. It gives someone work to resolve and keeps the report from claiming more precision than the evidence supports.
Count the same usage only once
Dome's usage views expose workspace totals and breakdowns by agent, API key, accepted act-as subject, and served model connection. The served-model view matters when failover changes the destination; the requested name alone is not enough to attribute provider usage.
Choose one basis for the ledger. The example uses non-overlapping workload buckets. Do not add the agent, key, person, and model views together: they are different breakdowns of overlapping consumption, not independent charges.
Keep the time window, workspace, query basis, and pricing assumptions with the report. Estimated cost is derived from usage and applicable pricing data; it is not a provider invoice.
Match usage to the owner at the time
Use the durable agent ID from the operational inventory to connect activity with the service owner. Maintain effective dates when responsibility changes.
A display name that now says “Finance” does not prove finance owned the workload last month. Likewise, a shared agent used by several services may not provide enough information for a clean team split.
For a workflow-level view, define the workflow identifier and join its application records to the governed requests. Include retries and fallback attempts according to a written accounting rule. Do not describe an application-level join as a native, automatic chargeback capability.
If some requests can't be matched, leave their cost unassigned and investigate. Don't call a partial total the cost of the whole workflow.
Reconcile the estimate with the bill
Now suppose the provider invoice for the relevant account is $1,180. The $180 difference is a reconciliation item, not an amount to allocate automatically in the same proportions.
Check the account and time boundaries, traffic outside the governed route, pricing basis, credits, and missing usage. These are possible explanations to investigate, not facts established by the example.
The model-pool contract helps identify the connections that may actually serve the workload. Preserve that connection-level view when different routes have different commercial terms.
Publish the usage estimate and invoice reconciliation as separate stages until their differences are explained.
Repeat the calculation at each close
At each close:
- Save the reporting window and the ownership records used.
- Assign costs with a known owner.
- Apply the agreed rule for shared services.
- Leave unmatched costs visible and give someone the job of resolving them.
- Compare the estimate with the provider invoice before treating it as chargeback.
Then ask what the spending bought. A lower token bill can accompany more retries, manual rework, or fewer completed tasks. Outcome records belong in the application; use them to interpret the allocation without claiming the model meter can judge business value.
Another analyst should be able to reproduce the total from the saved records. Start with the agent and served-model usage views, and make every step from those records to a team's allocation visible.