Visibility into LLM Spend Across Teams and Providers

Spend visibility is an attribution problem

Most enterprises can see a total LLM bill per provider. The harder question is who incurred it: which team, application, user or agent, through which model, and for what purpose. Provider invoices and usage exports answer that question only to the extent that identity and tagging were applied consistently at the time of each request. With several providers, many teams, coding assistants and agents, that consistency is rare.

Five data points make a request attributable. Identity says who or what made the call. Model says which provider and model served it. Token counts record input and output usage. Pricing basis records the unit and rate that convert usage to cost, and it should be stored with the record because rates change. Application or tool context says which system, coding assistant or agent produced the call.

If any of the five is missing at capture time, it is difficult to reconstruct later. A dashboard built on incomplete records will show tidy charts that cannot be defended when a team disputes its allocation. The design question is therefore where in the architecture each field can be captured reliably.

Comparing approaches and their limits

Each common approach captures part of the picture. The gaps below are structural, and they matter more than the feature list of any one tool.

• Provider dashboards: Fast to start and authoritative for billed amounts. Each provider uses its own grouping, fields and token accounting, so cross-provider comparison needs normalization, and attribution stops at whatever the provider can group by.
• API key segmentation: One key per team or application gives coarse attribution without code changes. Key counts grow quickly, keys get shared or copied, and a key identifies a workload rather than a person or agent.
• Tagging conventions: Metadata on requests carries application and team context where providers accept it. It relies on every caller applying the convention, and untagged calls fall into an unallocated bucket.
• Proxy-layer capture: Centralizes request and response records for traffic routed through it. Coverage is limited to routed traffic, identity must be propagated to it, and streamed responses need explicit handling.
• Execution-path capture: Records usage where policy is enforced, with identity, model and tool context per interaction. It still covers only traffic that passes through it, so bypass routes must be closed or detected.

Reconciling invoices with request-level records

Treat the two data sets as having different jobs. The provider invoice is authoritative for what was billed. Request-level records are authoritative for who caused the usage. Reconciliation allocates the billed amount using the request-level evidence, and surfaces the difference as a measured variance rather than hiding it.

A workable routine joins records by provider, model and time window, then compares summed token counts against provider usage reports. Normalize units first, because providers can count tokens differently and price input and output separately. Store the pricing basis used for each record, so a rate change does not rewrite history.

Streaming responses need a defined rule. If the stream returns final usage figures, capture them. If it does not, or the stream is interrupted, record an estimate and mark it as an estimate. Unmarked estimates erode trust in the whole data set.

Shadow usage is the remaining gap. Calls made with personal keys, unapproved tools or direct provider access do not appear in central records, but they may appear on an invoice. Spend on the invoice that has no matching request-level records is a useful signal. Review it by key or project, and bring that traffic into the central path or block it.

Why attribution needs one point of enforcement and identity

Attribution is only as consistent as the point that produces it. If five teams capture usage five ways, the resulting records are not comparable. A single enforcement point in the request path applies one identity model and one record format to every provider behind it.

The same point is where controls belong. NIST guidance on API protection describes cost amplification, where a small expenditure by a requester triggers much larger spending by the system. It recommends mitigating this through a combination of rate limiting, quotas and spending policy controls, alongside application or business flow changes. Those controls act on request flow, so they work best where requests are recorded. NIST's work on agent identity similarly expects monitoring of agentic access, with agent-specific metrics, thresholds and policies.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. It can allow, redact, block, rate limit or escalate individual interactions and tool calls, and it generates audit-ready evidence from that enforcement. It runs self-managed in the customer cloud, with configurable retention and data residency. In production it applies one policy plane across 100+ models. It is not a billing or finance tool. Its role here is to provide the per-interaction identity and evidence that attribution depends on, and the rate limits that apply at the same point.