How can I identify which AI applications are driving my LLM bill?
Summary
- Tag first, then trace. Give every model call a tag that names the application, team, or project behind it. Each request is then logged with its own cost, so you rank applications by spend instead of guessing which one is the culprit.
- Route AI traffic through one gateway. When every application's model calls pass through a single governed path, usage and cost for Databricks-hosted and external models land in one place instead of scattered across separate provider invoices.
- Read the cost in governed system tables. Per-request tokens, the requesting identity, the destination model, and the tags applied are recorded in Unity Catalog system tables you can query, chart, and alert on.
- Start from the built-in cost dashboard. Unity Gateway ships a cost analysis view that breaks spend down by application, user, model, endpoint, and tag, so the biggest driver shows up without building anything.
- These pieces are generally available. Usage tracking, per-request cost attribution, and request tags are GA, so attributing your LLM bill to a specific application is a query away.
How can I identify which AI applications are driving my LLM bill?
Tag the traffic, then trace it. Give every model call a tag that names the application, team, or project behind it, route those calls through one AI gateway, and each request lands in a log with its own cost attached. From there, ranking applications by spend is a query or a dashboard filter, not a forensic exercise. Most LLM bills stay opaque because calls go straight to a provider with no shared identity or tag on them, so all you get back is a lump sum. Fix that at the point where traffic enters and the bill becomes legible.
Why an LLM bill is hard to read
An LLM bill blends pay-per-token calls to hosted models, provisioned throughput, calls out to external providers, and the retries and long contexts that agents generate on their own. Without attribution, one invoice hides which application, user, and model ran up the total. A smaller number isn't the goal by itself. Knowing where the number comes from is what lets you act on the application or workflow responsible instead of throttling everyone.
What to look for in cost attribution
| Capability | Why it matters |
|---|---|
| Per-request cost logging | Token counts alone don't equal spend. You want the actual cost of each request recorded, across hosted and external models. |
| Custom tags on requests and endpoints | Tags carrying the application, team, project, or environment let you group spend the way your org is organized. |
| One path for hosted and external models | A single governed route means one consistent record, not separate provider bills reconciled by hand. |
| Governed, queryable usage data | Usage in tables you can query with SQL, chart, and alert on, not a static export you can't join to anything. |
| Identity on every call | Knowing the user or service principal behind a request separates a runaway job from normal use. |
How Databricks approaches this with Unity Gateway
Unity Gateway is the governed control plane for AI traffic on Databricks, and usage tracking is on by default for every request routed through it. Because each call carries the caller's identity and the destination model, and can carry your own tags, attribution is built in rather than bolted on. See Unity Gateway cost observability.
- Tag each application's traffic. Attach custom
key:valuerequest tags, such as a project or team, to individual calls, and set endpoint tags on the model service. Request tags are recorded per call; endpoint tags appear ascustom_tagson billing records. See tag requests for usage tracking. - Read the spend in system tables.
system.ai_gateway.usagelogs tokens and requester details per request,system.billing.usagerecords Databricks consumption with the endpoint name, destination model, and requesting identity, andsystem.ai_gateway.external_model_spendrecords estimated spend for external model calls. It all lives in Unity Catalog, so you query and join it like any other governed table. See usage tracking. - Start from the built-in dashboard. The cost analysis view in the Unity Gateway observability dashboard breaks spend down by application or coding agent, user, model, endpoint, and tag, drawing on those same tables. Optional inference tables can capture full request and response payloads for deeper tracing; confirm the current availability of that feature in the docs.
- Ask in plain language, then act. AI/BI Dashboards and AI/BI Genie let you explore spending trends over the usage tables in natural language. Once you know the driver, budgets can alert on it and enforce spend caps scoped by tag, team, user, or endpoint.
See also the AI gateway as the governance layer for agentic AI and AI spend controls in Unity Gateway.
Use cases
- Find the runaway agent. An autonomous agent that retries or over-fetches context can dominate a bill; per-request logging with identity makes it visible so you tune or rate-limit it.
- Charge back by team. Endpoint and request tags let a platform team attribute spend to the business unit that generated it, then set per-team budgets.
FAQs
How do I attribute a single request to an application?
Attach a request tag naming the application or team when the call is made, and set endpoint tags on the model service. Both are recorded with the request, so you can group spend by application, project, or environment in the usage tables and the cost dashboard.
Where does the cost data live?
In Unity Catalog system tables: system.ai_gateway.usage, system.billing.usage, and system.ai_gateway.external_model_spend. Because they're governed tables, you query, join, and build dashboards or alerts on them.
Does this cover external providers, not just Databricks-hosted models?
Yes. Requests to external providers route through the same gateway, and their estimated spend is tracked alongside Databricks-hosted usage, so one record covers both.
Which of these capabilities are generally available?
Usage tracking, per-request cost attribution, request and endpoint tags, the system tables, and the cost analysis dashboard are generally available. Deeper tracing features such as inference tables are evolving, so check the docs for current status.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.