LLM cost attribution needs request-level metadata, not invoices

At a glance

What this is: This is a playbook for attributing LLM spend at the request level, with the key finding that invoice-only reporting cannot explain the drivers of cost growth.

Why it matters: It matters because IAM and security-adjacent teams increasingly need traceable control over who, what, and which workflow generated AI spend, especially where agent runs behave like governed identities in production.

👉 Read Braintrust's guide to tracking LLM costs with request-level attribution

Context

LLM spend becomes difficult to govern when finance sees only a total invoice and engineering cannot tie that total back to a specific user, feature, prompt version, or agent run. In practice, that creates a control gap between billing visibility and operational accountability, which is especially relevant as AI workflows start to behave more like managed systems with identifiable execution context.

The article focuses on request-time attribution, which is the right starting point for any programme trying to connect AI usage to product economics, reliability, and margin. The identity intersection is real here: when an agent run is traceable to a request, it begins to resemble a non-human workload with governance requirements similar to other managed runtime identities.

Key questions

Q: How should teams attribute LLM cost at the request level?

A: Tag each model call with request metadata at creation time, including user, customer, feature, deployment, prompt version, and agent run identifiers. That lets teams roll spend into actionable views instead of reconstructing causality later from invoices. The key is to preserve the metadata on the trace so cost, quality, and behaviour stay linked.

Q: Why do agentic workflows make LLM cost harder to control?

A: Agentic workflows can trigger repeated tool calls, retries, and long execution chains inside one run, which turns a small failure into a cost spike. A single invoice line cannot show whether the spend came from normal usage or a runaway loop, so teams need span-level visibility and ceilings on execution behaviour.

Q: What breaks when LLM cost is tracked only in invoices?

A: Finance may see the spend, but engineering cannot identify which user, feature, prompt change, or agent run caused it. That leaves teams guessing during investigations and slows responses to retry storms, prompt bloat, and runaway agents. Request-level attribution is what converts spend from a billing fact into an operational signal.

Q: How do teams stop a misbehaving agent run from wasting budget?

A: Use a kill switch in the agent framework that watches token count, tool-call count, retry count, and span depth. When one of those ceilings is crossed, stop the run before it completes the next loop. That containment belongs in the execution path, because post-hoc review arrives too late to prevent the cost.

Technical breakdown

Why invoice-level LLM spend hides the real cost driver

Provider invoices aggregate usage after the fact, so they are useful for accounting but weak for diagnosis. They can show that spend rose, but not whether the cause was a single customer, a retry storm, a larger prompt template, or a runaway agent loop. The architectural problem is that the billing boundary is detached from the execution boundary. Once the trace loses request context, teams must reconstruct causality from logs and product knowledge, which slows both incident response and optimisation work.

Practical implication: attach cost metadata at request creation so cost analysis starts from the trace, not the invoice.

How request-time metadata enables cost rollups across users, features, and agent runs

Request-time attribution works because each model call carries metadata that survives downstream processing. Fields such as user_id, feature, deployment, prompt_version, agent_run_id, and customer_id let teams roll spend into slices that answer different questions. Low-cardinality attributes support alerting and charting, while high-cardinality values remain useful for drill-down and investigation. This is a governance pattern as much as an observability pattern, because it turns opaque spend into queryable operational evidence.

Practical implication: standardise span metadata at the call site and define which fields are safe for alerting versus trace-level investigation.

Why agent-run controls should include cost ceilings and kill switches

Agentic workflows can amplify spend because one malformed response or repeated tool failure can trigger a long sequence of calls inside a single run. Cost controls therefore need to operate inside the execution path, not just in reporting. A kill switch based on token count, tool-call count, retry count, or span depth stops waste while the run is still active. This is the same governance logic used in other runtime control patterns: when execution can loop autonomously, post-hoc review is too late to protect budgets or service quality.

Practical implication: set run-level ceilings in the agent framework so excessive spend is interrupted before it leaves the workflow boundary.

NHI Mgmt Group analysis

Request-level attribution is the real control boundary for AI spend. Invoice-only visibility is too coarse for operational governance because it collapses many behaviours into one number. When user, feature, prompt, and agent-run metadata are attached at call time, cost becomes auditable in the same way other production events are auditable. That shift matters for security and platform teams because it turns AI usage into governed runtime activity, not an anonymous expense line. Practitioners should treat trace-level attribution as the minimum viable control for AI economics.

Agent-run cost is a governance problem, not just a FinOps problem. Runaway loops, retries, and context bloat are behavioural patterns, which means they need runtime boundaries as well as reporting. The named concept here is agent-run cost drift: a steady rise in spend caused by execution behaviour that looks normal in aggregate but is inefficient at the span level. Teams should connect this to OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework so cost governance is aligned with AI risk management, not isolated from it.

AI spend attribution now intersects with machine identity governance. When an agent_run_id, service context, or workflow identity determines which model calls happen and at what cost, that execution path behaves like a non-human identity with a measurable footprint. The governance question is no longer only who approved the model, but what runtime identity executed the work and under what cost boundaries. That makes NHI-style visibility relevant even in a finance-led conversation. Practitioners should extend identity-style accountability to agent execution paths that can create material spend.

Cost controls need to be checked against quality controls before release. The article's strongest operational point is that cheaper routing is only defensible when it preserves eval pass rate and latency. That is a governance pattern that should be embedded in release gates, not handled as a post-deployment tuning exercise. Teams that separate cost from quality will optimise the wrong metric. Practitioners should treat cost, eval score, and latency as a single control triangle for AI change management.

Prompt and provider variability make static budgeting brittle. Changes in prompt version, cache behaviour, retry handling, and provider pricing can all alter effective cost without changing the business surface area. That creates a hidden governance gap if teams assume budget baselines are stable across releases. The article shows why cost observability has to evolve with the release process. Practitioners should review pricing tables, attribution tags, and cache fields whenever model behaviour or routing changes.

What this signals

agent-run cost drift: The practical risk is not only overspend, but spend that rises quietly as prompt templates, retries, and tool chains change across releases. Teams should watch for cost movement at the feature and agent-run level, then compare it with eval pass rate and latency so a cheaper route does not become an operational regression.

LLM cost governance is converging with runtime identity governance because the execution path, not just the invoice, now carries accountability. That makes request metadata, cost ceilings, and release gates part of the same control surface, especially where agentic workflows behave like persistent non-human actors inside production systems.

For practitioners

• Implement request-time metadata tagging Attach user_id, feature, deployment, prompt_version, agent_run_id, and customer_id at the model call site so every trace can support cost rollups and investigation.
• Build cost rollups for operational decisions Create cost per user, cost per feature request, cost per agent run, and cost per customer reports, then use them to identify retry storms, runaway loops, and margin pressure.
• Set run-level ceilings for autonomous workflows Define token, tool-call, retry, and span-depth limits inside the agent framework so a misbehaving run can be stopped before it finishes its loop.
• Separate low-cardinality and high-cardinality signals Alert on feature, deployment, and model combinations, then use user-level and agent-run traces for drill-down after an alert fires.
• Tie cost changes to release gates Require eval pass rate and latency checks alongside cost reductions so cheaper routing cannot reach production unless quality remains inside threshold.

Key takeaways

• Invoice-level billing is not enough to explain LLM spend because it hides the request, workflow, and agent behaviour behind the total.
• Request metadata turns AI usage into governed operational evidence, which is the only reliable basis for cost rollups and investigation.
• Cost control becomes durable only when teams tie attribution to kill switches, release gates, and quality checks in the execution path.

Key terms

• Session-Level Attribution: The ability to tie an action back to a specific runtime session, actor, and policy state. For AI agents, this matters because network logs alone often cannot show whether activity came from an approved workflow, a shadow tool, or a reused user entitlement.
• Agent-run cost drift: Agent-run cost drift is the gradual increase in spend caused by agent behaviour such as retries, tool loops, prompt growth, or repeated context expansion. The problem often appears harmless in aggregate, but it can materially change unit economics and reliability at the span level.
• Kill Switch: A kill switch is an emergency control used to stop an autonomous system from taking further action. In security practice, it is a containment mechanism, not a governance strategy, because it does not prevent prior overreach or replace least-privilege design.
• Cardinality: The number of unique attribute combinations in telemetry data. High cardinality increases the number of metric series and can inflate cost, overwhelm backends, and make analysis noisy unless attributes are normalised or removed before export.

What's in the full article

Braintrust's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step span tagging patterns for OpenAI client wrappers in TypeScript and Python
• Token-field conventions for cached tokens, cache writes, and custom model cost logging
• Practical rollup examples for user, feature, customer, and agent-run cost analysis
• Release-gate logic that combines cost, eval pass rate, and latency before production rollout

👉 The full Braintrust guide covers tagging patterns, rollup logic, and release-gate examples in implementation detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It helps security and identity practitioners extend runtime accountability into the controls that increasingly shape AI operations.