How to Attribute LLM Cost to Agents, Users, and Workflows

Ask an engineering leader what their LLM spend was last month and they'll tell you to the dollar. Ask them why it was that number — which agents, which customers, which workflows, which retry loops — and the conversation usually ends. Provider dashboards report spend by API key. Nobody operates a business by API key.

This is the defining feature of LLM cost, and it's why FinOps practices built for cloud infrastructure translate poorly. An EC2 bill maps to resources you provisioned deliberately. An LLM bill is emergent: it is generated one decision at a time inside conversations and agent runs — a system prompt here, a growing context window there, a tool result stuffed into context, a retry, an escalation from a small model to a large one. The bill is the sum of a million small choices no one explicitly made, which is precisely why nobody can explain it after the fact.

The consequence shows up in a pattern we see constantly: spend grows faster than usage. Traffic is up 20%, cost is up 70%, and the gap is invisible — because the gap isn't a resource, it's a behavior. Context windows creep as conversations lengthen. A tool starts returning bloated responses that get re-embedded into every subsequent turn. A retry loop triples the calls behind a fraction of sessions. An escalation policy quietly routes more traffic to your most expensive model. None of this appears on the provider dashboard as anything but a bigger number.

Attribution is a tracing problem, not an accounting problem

Here's the practical insight: you cannot fix this from the billing side, because the billing data has no context. You have to fix it from the telemetry side. Cost attribution means capturing token usage and model cost at the moment of the call, inside the trace, where the surrounding context still exists — which agent made the call, in which workflow, for which user and account, after which tool result, with what outcome.

flowchart LR
    CALL["LLM call"]
    CALL -- "billing export" --> BILL["monthly total<br/>by API key<br/><i>no context</i>"]
    CALL -- "span attribute" --> SPAN["tokens + cost<br/>inside the trace"]
    SPAN --> DIM["by agent · user ·<br/>workflow · team · outcome"]
    DIM --> UE["<b>unit economics</b><br/>productive spend vs waste"]
    style BILL stroke:#8e9aaa,stroke-dasharray:4 4
    style SPAN stroke:#f4ae30,stroke-width:2px
    style UE stroke:#59ca6f,stroke-width:2px

Once cost is a span attribute rather than a monthly export, the questions that matter become queries instead of investigations. Cost per session, per workflow completion, per resolved ticket. Spend by agent, by customer, by team. Which tool's output is inflating context windows. Which model escalation paths are earning their price.

And one question matters more than all the others: is the spend producing outcomes? Cost attribution that stops at "which agent spent the most" produces naive cost-cutting — teams downgrade a model, save 30% on tokens, and lose more than that in task completion. Tie spend to evals and business outcomes, and you can tell productive spend from waste before optimizing the wrong one.

What this looks like in practice

A product team using AnoSys cost intelligence typically finds something like this within the first weeks: 8% of sessions are generating 31% of token spend. The outlier sessions share a signature — a tool retry loop, concentrated in one workflow and one customer segment. And the kicker: those expensive sessions also have lower task completion. The money is being spent on failing.

That finding is an ideal optimization target precisely because it isn't a tradeoff. Fix the retry behavior and cost drops while quality rises. Findings with that shape are common once cost and outcomes sit on the same timeline — and essentially invisible until they do.

The dimensions that make cost useful

The biggest mistake in AI cost reporting is stopping at totals. A useful cost model needs enough dimensions to explain behavior, but not so many that no one trusts the numbers.

Dimension	Why it matters
Agent or workflow	separates product areas and operating owners
User, account, or tenant	exposes power users, abusive patterns, and enterprise unit economics
Model and route	shows whether expensive models are used where they earn their cost
Prompt and release version	catches prompt bloat and deployment-driven spend changes
Tool call and retry count	identifies hidden loops and bloated tool responses
Outcome	distinguishes productive spend from expensive failure

Two ratios are especially useful for leadership reviews: cost per completed workflow and cost per successful outcome. Raw spend can rise because usage is growing, which may be healthy. Cost per successful outcome rising is different. It means the system is getting less efficient at turning model calls into business value.

What not to optimize first

Teams often reach for the most visible lever: switch to a cheaper model, shorten prompts, or cap conversation length. Sometimes that is right. Often it is premature. If you reduce spend by cutting context the agent needed, the bill improves and the product gets worse. If you downgrade a model in a workflow where failures create human escalations, the provider bill falls while operating cost rises.

Start with waste that has no upside: retries, loops, oversized tool payloads, unused context, unnecessary model escalation, and abandoned sessions that consumed expensive tokens before failing. Once those are under control, model-routing and prompt-compression decisions become much safer because you can see the quality and outcome tradeoff.

Getting there with AnoSys is mostly a matter of instrumentation discipline: capture model, token usage, and provider cost on every call; attach the operational attributes you actually manage by — user, account, workflow, agent, team, outcome; build dashboards around unit economics (cost per session, per workflow, per outcome) rather than raw totals; and alert on the behaviors that precede billing surprises — token spikes, retry storms, cost per completed task, latency regressions, or engagement drops. Model escalation patterns still matter, but mainly as routing and cost evidence during the investigation. AnoSys captures all of it in one operational data layer, alongside the evals and user behavior that tell you which spend is buying results.

Your LLM bill is a symptom. The telemetry is the diagnosis.

Explore AI Cost Intelligence, the AI Cost Optimization solution, and the Cost Intelligence documentation.

Create a free account or schedule a demo.