Tracking provider cost across models, tools, and agents
One customer request can touch several models, tools, and agents, each billed separately. Here is where cost attribution breaks, and the fields every usage signal should carry.
One customer request to an AI agent can touch a lot of paid infrastructure. A small model classifies the input. A larger one plans the work. A sub-agent calls a search API and queries a vector store, then hands its results to a third model that writes the answer. Each step has a price, and the charges arrive on different invoices from different providers.
At month end, those invoices show what you spent in total. They do not show which customer, agent, or feature the money went to. Without that breakdown, you cannot tell which accounts are profitable, which plan is underpriced, or whether last month's model switch saved anything.
The number keeps getting harder to find
Companies run more models every quarter. Databricks' State of AI Agents report, based on telemetry from more than 20,000 organizations, found that 78% were using two or more model families by October 2025. The share using three or more rose from 36% to 59% in three months. In a16z's 2025 survey of enterprise CIOs, 37% used five or more models, up from 29% a year earlier.
Teams switch models to save money. In a Dataiku and Harris Poll survey of 600 CIOs, 55% had switched LLM providers at least once, with cost reduction as the main reason, and 81% expected to rely on two or more providers in 2026. Each switch changes what the same customer request costs you.
Agents delegate to other agents. Use of multi-agent workflows on the Databricks platform grew 327% between June and October 2025. When one agent hands work to another, the cost spreads across calls that may never reference the customer who started the request.
More models per company
Every model family added to a stack brings its own price list, its own token counting, and its own invoice. When a router picks between them per request, the cost of serving one customer changes from one request to the next.
5 ways attribution falls short
Routing. A router that picks a model per request means two identical requests from the same customer can cost very different amounts. If you log cost at the router level, record the model it chose for each call, along with that model's rate at the time of the call. Rates change, and a monthly average will hide which customers drove the expensive calls.
Tool calls. Search APIs, vector databases, code sandboxes, and browser sessions all bill separately from the model. They often run on shared API keys, so the provider has no idea which customer a call served. The only place that knows is your application, at the moment the agent makes the call.
Sub-agents. When an orchestrator hands a task to a sub-agent, the sub-agent's calls need to carry the original customer and request ID. Without that, its cost lands in a shared bucket, and the most complex requests look cheaper than they are.
Discounts that depend on timing. Cached input tokens, batch processing, and committed-use discounts all lower the effective rate below list price. Two customers sending the same prompt can cost different amounts if one hits the cache. Pricing every call at list rates overstates cost, and pricing everything at the blended discount hides who benefits from it.
Reconciliation. Your own records and the provider's invoice will disagree, because of rounding, retries, failed calls that still billed, and rate changes mid-month. Compare the two every month and track the gap as its own number. A gap that grows is usually a call path that is not being metered.
A checklist for every usage signal
Each call to a model or a paid tool should emit one record with these fields.
| Field | Why it matters |
|---|---|
| Customer ID | Ties cost to the account that pays for it |
| Request ID | Groups every call made for one customer request |
| Parent call ID | Links sub-agent calls back to the agent that started them |
| Agent and feature | Shows which part of the product is driving cost |
| Provider and model, with version | Separates routing decisions and catches silent model changes |
| Input, output, and cached tokens | Prices each token type at its own rate |
| Tool name and quantity | Covers searches, queries, and sessions that are billed outside the model |
| Rate applied | Records the price at the time of the call, so later rate changes do not rewrite history |
| Computed cost | Gives finance a number that can be summed directly |
| Timestamp and status | Catches retries and failed calls that still billed |
With these fields in place, margin per customer becomes a query. Without them, it stays a spreadsheet exercise at month end.
Start with one request
Pick one expensive request from last week and trace it end to end. Count the model calls, tool calls, and sub-agents it touched, and check how many of them you can tie back to the customer. The ones you cannot are the first fields to add.
Clocknext receives these signals as they happen, with provider cost attached, so the cost of each customer's work sits next to what that customer pays.
If you're looking for real-time visibility into cost on every level, then you're in the right place. Talk to us, we'd love to help.
Manish Balaji
A fan of compelling stories, memorable product experiences, and Liverpool FC, not necessarily in that order.
