Your provider invoice tells you how much you spent. It cannot tell you which team, feature, customer or agent spent it. A cost attribution dashboard closes that gap by capturing usage at the gateway, tagging every request with an owner and pricing each call as it happens. This guide gives six build steps, the tags and panels to include, and a way to handle spend that has no clear owner.
TL;DR
- The goal: tie every dollar of LLM spend to a team, feature, user and model, not just to a provider invoice.
- Capture: emit one usage event per call with input, output, cached and reasoning tokens, the model served, and a cost priced at ingest.
- Tag: make owner metadata mandatory, and refuse calls that arrive without it at the gateway.
- Show: build views for burn rate, team, model, feature and user, with alerts that fire before a hard limit.
- Settle: publish one rule for shared costs, show the unallocated remainder, and reconcile estimates to invoices weekly.
What is LLM cost attribution?
LLM cost attribution is the practice of assigning each dollar of model spend to the team, feature, customer, user, agent and environment that caused it. The unit of measure is the single request. Requests roll up into views that people can act on, such as spend per team against its budget or cost per feature per day.
A provider invoice cannot do this. An aggregate bill from OpenAI, Anthropic or AWS shows spend by provider, model and date. When several teams share one API key, the bill is correct but the record of who owns each charge is missing.
Agents make this harder. One task can trigger a handful of calls or hundreds, so spend per run varies widely. Our guide to cutting LLM costs without changing models gives the working formula: agent cost equals model calls times tokens per call times token price, plus workflow overhead. Attribution has to capture every term, per request, with an owner attached.
Organizations are catching up fast. In the FinOps Foundation’s State of FinOps 2026 survey, as cited in Lyzr’s guide to chargeback and showback for AI spend, the share of respondents managing AI spend went from under a third to nearly all in two years.
How do you build the dashboard in six steps?
The build has one data path. Applications call models through a gateway. The gateway checks tags, prices the call and records a usage event. A store holds the events, and a dashboard and alerts read from it. The diagram shows the path, and the steps below build it in order.
Step 1: Capture core telemetry dataEvery LLM call emits an immutable usage event with input, output, cached and reasoning tokens, the provider and model, and a USD cost computed at ingest from a maintained price book instead of waiting for the monthly invoice.
Step 2: Enforce mandatory metadata taggingAttach a user or principal, team or cost center, project or feature, and environment to every request. A call that arrives without its owner fields is refused, so untagged spend never builds up.
Step 3: Route traffic through an AI gateway or proxySend calls through a gateway or proxy rather than instrumenting each SDK. The gateway tags, prices and meters every call in one place, and can enforce budgets and rate limits before a request reaches the provider.
Step 4: Design the dashboard views and panelsBuild a cost overview with burn rate, cumulative spend and projected month-end, then break spend down per user, team or project, model, and feature. Keep each panel tied to a question someone will ask.
Step 5: Decide how shared and untagged spend is handledChoose one split rule for costs that have no single owner, publish it before the first report, and show the unallocated remainder as its own line so it stays visible.
Step 6: Add early-warning alerts and reconcile weeklyAlert on rolling cost drift and on budget thresholds that fire before a hard limit. Compare your event-level estimates with provider invoices every week so errors surface early.
What should every usage event contain?
The event is the foundation of the dashboard. Everything else is a query over it, so a field missing from the event cannot be recovered later. Capture four groups of fields: tokens, model, cost and owner.
| Field | Why it matters | OpenTelemetry attribute |
|---|---|---|
| Input tokens | Base volume of every call | gen_ai.usage.input_tokens |
| Output tokens | Usually priced higher than input | gen_ai.usage.output_tokens |
| Cached input tokens | Quantifies savings from prompt caching | gen_ai.usage.cache_read.input_tokens |
| Reasoning tokens | Tracked as its own dimension, because reasoning can dominate cost | gen_ai.usage.reasoning.output_tokens |
| Requested and served model | A silent fallback to a costlier model changes the price | gen_ai.request.model, gen_ai.response.model |
| Provider | Separates OpenAI, Anthropic, Bedrock and self-hosted spend | gen_ai.provider.name |
| Price book version | Explains why an old estimate used an old price | Custom field |
| Retry count and fallback origin | Stops retried calls from being counted as new demand | Custom field |
The attribute names come from the OpenTelemetry GenAI semantic conventions. Those conventions are still evolving, so pin the version you build against. Using the standard names keeps the events portable across the monitoring tools covered in our roundups of AI agent observability tools and open-source LLM observability platforms.
How do you price a call at ingest?
Cost per call is input tokens times the input price, plus output tokens times the output price, with cached and reasoning tokens priced at their own rates where your provider bills them separately. Check your provider’s pricing page for each rate, then store the rates in a versioned price book.
Here is an illustrative calculation at example rates of $2.00 per million input tokens and $8.00 per million output tokens. A call with 3,000 input tokens and 400 output tokens costs $0.006 plus $0.0032, or $0.0092. At scale the same rates make 20 million input and 4 million output tokens a day cost about $72, or roughly $2,160 over 30 days, an example used in a public guide for platform teams. Treat these rates as placeholders and use your own price book.
Which tags should every request carry?
Raw provider bills cannot say which internal feature or team drove a cost, so the request itself must carry that context. Inject structured headers or context tags into every call. The table lists a practical minimum.
| Tag | Question it answers | Notes |
|---|---|---|
user_id or iam_principal | Who triggered the spend? | Powers per-user quotas, abuse detection and pricing-tier analysis. Keep it as a log or span attribute, not a metrics label, to avoid a cardinality explosion |
team_id or cost_center | Which department pays? | Drives department accounting and budget allocation |
project_id or feature | Which product feature or sprint caused it? | Maps spend to delivery work |
environment | Is this production? | Separates production, staging and development usage |
agent_id and version | Which agent, at which release? | Needed once agents, not apps, are the unit of spend |
request_id | Which call is this charge? | Lets any disputed charge trace back to the original request |
Tags only work if they are required. Enforce ownership metadata at the gateway or proxy, not through optional logging in each app, and reject outbound calls that lack fields such as the team or tenant. Avoid filling gaps later from lookup tables, because that weakens auditability when the source systems change. For the owner field to mean anything, each agent needs a named owner, which is the job of an AI agent registry.
If calls currently share a single provider key, replace it with per-team or per-project credentials issued by the gateway. Our explainer on virtual keys in an LLM gateway shows how a key identifier on each request ties spend to a team, project or app.
Why route traffic through a gateway?
Instrumenting every application SDK means every team must adopt your telemetry code, and notebooks, scripts and no-code tools slip past. A gateway or proxy sits in the request path, so it sees every call whatever framework made it. It can attach identity and tenant headers automatically, and it can enforce budget caps and rate limits per team or project before a request reaches the provider.
| Approach | Strength | Watch for |
|---|---|---|
| SDK instrumentation in each app | Rich app context, such as feature flags and user sessions | Coverage gaps wherever a team skips the SDK |
| AI gateway or proxy | One chokepoint for tagging, pricing, budgets and rate limits | An extra hop per call, and a component to run and keep available |
| OpenTelemetry tracing pipeline | Vendor-neutral events that feed tools such as Grafana or OpenObserve | Still needs a source of consistent tags and prices |
| Provider invoice only | No engineering work | Monthly, shared-key blind, and no feature or team detail |
These options combine well. A gateway tags and prices each call, then exports OpenTelemetry events into whatever store and dashboard tool you already run. The reasoning behind the gateway choice matches the placement logic in our guide on where guardrails should live: anything that must hold for every agent belongs outside the agent. For a feature-by-feature view of the market, see our comparison of LLM gateways.
Which views belong on the dashboard?
Organize the dashboard into slices that answer real questions. Whether you build it in Grafana, OpenObserve or a notebook, start with a cost overview at the top and attribution breakdowns beneath it.
| Panel | Question it answers | What to look for |
|---|---|---|
| Cost overview | How fast are we spending, and where will the month end? | Burn rate, cumulative spend and projected end-of-month run rate against budget |
| Per user or tenant | Who are the power users? | Cost anomalies and accounts that skew the average |
| Per team or project | Is each team inside its allocation? | Spend against departmental budgets |
| Per model | Is an expensive model doing cheap work? | Steps, such as summarization, that a smaller model could handle |
| Per feature or sprint | What does this feature cost to run? | Daily AI usage tied to product delivery cost |
| Early-warning alerts | What needs attention before a limit is hit? | Rolling cost drift and threshold alerts |
Before you act on the per-model panel, test quality, because a cheaper model can save money and still fail the task. Run your scenarios against the smaller model first, and our guide to auto generating test scenarios for AI agents shows how to build that suite. Lyzr’s own advice is to judge spend by cost per successful task, not cost per token, a point we develop in how to cap spend per model without blocking teams.
Spend is only one signal. Pair this dashboard with the live health views described in our guide to real-time AI agent monitoring, so a cost spike can be read next to latency, errors and quality.
How do you handle shared and untagged spend?
Some spend has no single owner. Gateway infrastructure, observability, reserved commitments and central experiments serve everyone. Traffic behind an old shared key is the main source of unattributed spend. Forcing all of it onto teams makes the numbers look precise while being wrong, so decide how to treat it before the first report.
Lyzr’s guide to chargeback and showback for AI spend lists four ways to split a shared cost, and recommends choosing one and publishing it before the first report.
| Split rule | Best when | Risk |
|---|---|---|
| Proportional to direct spend | You want a fair default | Heavy users carry more of the shared cost, which may hide who benefits |
| Fixed, agreed split | Teams value predictability | Drifts away from real usage over time |
| Proxy metric, such as request count | Spend is hard to measure but traffic is easy to count | Cheap and expensive requests are treated alike |
| Leave it central | The cost is a platform investment | Teams never see the full price of their usage |
Show the unallocated remainder as its own visible line, and do not split idle reserved capacity across teams, because that hides waste. The same guide describes a typical directly attributable share of 70 to 80 percent as a practitioner range rather than survey data.
Showback or chargeback?
Both report the same costs to the same teams. Showback keeps spend on a central budget to build awareness, while chargeback posts it to the consuming team’s budget. As Lyzr’s guide puts it, chargeback moves money and showback moves information. Move to chargeback only when allocation accuracy is measured, teams can reconstruct their own bills, disputes have stopped, every workload has a named owner and finance will defend the numbers.
How do you set alerts and budgets?
A dashboard that is only read once a month is a report. Add alerts that fire early, so someone can act while there is still budget left. Use two kinds: threshold alerts against a budget, and rolling cost-drift alerts that compare today’s spend with a trailing average and catch a spike even when no budget is near.
Thresholds should end in an action. Our guide to preventing agent abuse with quota design patterns describes staged limits, such as throttling at 75 percent, notifying at 90 percent and stopping at the ceiling, and explains why dollar budgets catch runaway loops that call-count limits miss. Detecting those loops is covered in runaway tool loops detection.
Avoid one shared pool for everyone. In our guide to capping spend, a single shared budget turns a cost limit into an availability problem, because one team can use up the pool and block the others. Isolate budgets by user, team and project instead, and decide what should happen when a cap is reached, such as falling back to a cheaper model or holding the request for approval.
What mistakes break attribution?
Most failed dashboards trace back to one of four problems:
1. Shared keys.
Traffic behind one provider key cannot be traced to an owner. Issue per-team or per-project credentials through the gateway and attribute spend at the agent, not at the key.
2. Wrong retries and fallbacks.
Count a retry as new demand and the numbers inflate. Log only the requested model and a silent fallback to a costlier one makes the dashboard look clean while being wrong. Record the model actually served and the retry count.
3. Late enrichment.
Filling owners from a lookup table after the fact makes old reports shift when the source system changes. Stamp ownership at call time and keep one raw evidence path.
4. Optimizing the wrong unit.
Cost per token rewards cheap, failing answers. Track cost per successful task as well, so a cheaper model has to hold its quality to count as a saving.
Where does Opencontroller fit?
Opencontroller by Lyzr is the control plane for AI agents. It carries the gateway, tagging and tracing steps of this build in one product, so the dashboard reads from a single, consistent source. Per the product page, the relevant pieces are:
- LLM Gateway: virtual keys, team budgets, rate limits, routing, fallback and caching across model providers.
- Cost by owner: the product page shows every dollar by agent, version and team, with sample figures for monthly spend and per-call cost.
- Traces with cost on every span: OpenTelemetry traces with cost, quality and owner on each span, exported to the tools you already run.
- Identity: each agent gets a workload identity and signs in through your existing identity provider, so ownership is known when the call is made.
- Budgets that act: a budget or rule can refuse a call rather than only raise an alert, as described in our monitoring roundup.
- Deployment: in your VPC, on-prem or air-gapped, with no control-plane data, credentials or telemetry reaching Lyzr for customer-managed setups.
| Build step | If you build it yourself | With Opencontroller |
|---|---|---|
| Capture usage events | Write and maintain emitters per app | Traces carry cost, quality and owner on every span |
| Tag every request | Define headers, then police each team | Virtual keys and agent identity attach team and agent context |
| Gateway and budgets | Run a proxy, then add budget logic | LLM Gateway with team budgets, rate limits, routing and fallback |
| Dashboard and alerts | Build in Grafana or a notebook | Cost by agent, version and team, plus OpenTelemetry export to your own tools |
Opencontroller does not replace your finance process. Split rules, showback or chargeback decisions and invoice reconciliation stay with your FinOps team. If you are weighing control planes against other approaches, our overview of AI agent governance tools and the Lyzr agent control plane post explain the wider design, and Governance Control Plane 101 covers audit trails and cost controls together. Teams still counting their agents should start with AI agent sprawl. For a short definition of the goal, see cost-optimized AI agents.
Frequently asked questions
What is LLM cost attribution?
LLM cost attribution assigns each dollar of model spend to the team, feature, user, agent and environment that caused it. It works at the level of single requests, which are tagged with an owner, priced at ingest and rolled up into dashboards.
How do you track LLM costs per user or team?
Route calls through a gateway or proxy, require user and team tags on every request, record token counts and model per call, and compute cost from a price book. Group the resulting usage events by user, team, project and model in a dashboard.
How do you calculate the cost of an LLM request?
Multiply input tokens by the input price and output tokens by the output price, then add any cached or reasoning tokens at their own rates. For example, 3,000 input and 400 output tokens at $2 and $8 per million cost $0.0092.
What metadata should you tag on every LLM request?
At minimum, tag a user or principal, a team or cost center, a project or feature, and the environment. Add the agent and version, and a request ID so any charge can be traced back to the original call.
Why not just use the provider’s billing dashboard?
Provider dashboards show spend by model and date, not by your teams or features. They arrive after the fact, and traffic behind a shared key cannot be split by owner, so you need request-level events with your own tags.
Do you need an LLM gateway to attribute costs?
No, but it helps. SDK instrumentation and OpenTelemetry pipelines can work, yet each app must adopt them. A gateway sees every call, applies tags and prices in one place, and can enforce budgets before a request reaches the provider.
How do you attribute costs when teams share one API key?
Replace the shared key with per-team or per-project credentials issued by a gateway, and require owner tags on each request. For spend already behind a shared key, allocate it by an agreed rule and show it as a separate unattributed line.
How do you allocate shared LLM costs?
Pick one rule and publish it before the first report. Common options are proportional to direct spend, a fixed split, a proxy metric such as request count, or leaving the cost central. Always show the unallocated remainder separately.
What is the difference between showback and chargeback for LLM spend?
Showback reports each team’s consumption while spend stays on a central budget. Chargeback posts that consumption to the team’s own budget. Chargeback moves money and showback moves information, so use it only once your allocation is accurate and disputed.
How do reasoning tokens and caching affect cost attribution?
Reasoning tokens are often billed like output tokens and can dominate a call’s cost, so track them as their own field. Cached input is cheaper than fresh input, so record cache hits to measure savings and avoid overstating spend.
How often should you reconcile estimates with provider invoices?
Weekly is a good cadence, rather than only at month end. Comparing event-level estimates with invoices each week surfaces price book errors, missing events and fallback drift while they are still small.
What tools can you use to build an LLM cost dashboard?
Common choices are Grafana or OpenObserve for visualization, an OpenTelemetry pipeline for events, and a gateway or control plane such as Opencontroller to tag, price and meter calls. A notebook or BI tool also works for early versions.
See every dollar by agent, version and team
Walk through your current LLM spend with us and leave with a tagging plan and a dashboard layout for your agents.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
