In 2025, Uber’s R&D spend rose 9% to $3.4 billion. A few months into 2026, the company had already burned through its entire planned AI budget for the year, driven largely by how fast engineers adopted AI coding tools. The budget assumed usage would grow at a manageable pace. It didn’t. Engineers were encouraged to use these tools, and usage scaled far faster than that assumption held up.
Most enterprises hit this same wall once AI moves past a pilot. Tracking one provider is straightforward. The moment a team adds a second, for a different task, and a third, for cost or reliability, that simplicity disappears. Every provider bills on its own schedule and in its own format, and none of them show which team, workflow, or feature actually drove the cost.
This guide breaks down how to monitor LLM costs across providers, from what real cost monitoring should show you, to the specific mistakes that let spend quietly outgrow the plan for it.
Why Provider Billing Dashboards Aren’t Enough
Provider billing dashboards answer one question: what did you spend.
Each LLM provider shows a number for their own usage. It doesn’t show you why that number is what it is, or what’s driving it up. Dashboards reconcile invoices. They don’t show which team, workflow, or feature generated the spend.
Three limitations show up once teams run more than one provider:
- Each provider bills separately: If one workflow uses both OpenAI and Anthropic, you get two separate charges in two separate dashboards. To know what that one workflow actually costs, someone has to open both dashboards and do the math by hand.
- A dashboard also reports after billing: By the time a spike appears, the provider has already consumed and billed the tokens. Catching it at that point tells you what happened. It doesn’t undo the cost.
- No breakdown of requests: A dashboard shows GPT-4 cost $40,000 last month. It won’t show that $12,000 of it came from one workflow calling a frontier model on queries a smaller model could’ve handled.
What LLM Cost Monitoring Should Actually Tell You
Just knowing the total cost isn’t enough. What you need is a breakdown of where that cost actually came from. Real cost monitoring answers three questions.
Who spent it?
Real monitoring attributes every request to the user who triggered it. It ties that request to the specific agent or workflow that ran it. It rolls that cost up to the business unit accountable for it.
What was it for?
Real monitoring shows the purpose behind every dollar. A $40,000 monthly spend could be $30,000 going to a workflow serving real customer interactions, and $10,000 going to a test workflow nobody’s using anymore.
Whether it needed to cost that much?
A routine query, like a support ticket asking for an order status, gets sent to a frontier model by default. But a smaller model would’ve answered it correctly for a fraction of the cost. Real cost monitoring flags this while the request is happening, not after the invoice arrives. What happens next, whether that flag leads to a cheaper model or not, is where most systems stop.
The Multi-Provider Cost Problem
Different token definitions per provider
A token doesn’t mean the same thing across providers, and that difference shows up in pricing too. Anthropic and OpenAI both discount cached tokens, but the discount size and how long the cache stays valid isn’t the same on both. So identical usage patterns can cost differently depending on the provider, even when the sticker price looks similar.
Billing schedules and formats
Each provider reports usage on its own schedule, and that schedule isn’t always current. Some providers delay usage data by a day or two. So the number on your dashboard right now may not reflect what you’ve actually spent today.
No shared cost attribution model
No provider’s billing system knows who made a request or which workflow it belonged to, because that context lives in your application. Even when a provider lets you tag a request with a user ID, that tag rarely survives into the final invoice. It’s used to make the call, then dropped once billing happens. So the two things you need, who spent it and what it cost, are never linked together automatically.
How to Monitor LLM Costs Across Providers: Step by Step
Put every provider behind one gateway
Instead of connecting your app to OpenAI, Anthropic, and Bedrock separately, route every request through one layer that sits in front of all three. That single point is where you capture cost, in one format, no matter which provider handled the request. Without it, you’re stitching together three separate integrations that were never built to talk to each other.
Track cost per successful output, not per request
A request that fails and retries three times can end up costing more than an expensive request that worked the first time. If you’re only counting requests, retries hide inside the total and never show up as a problem. Counting successful outputs instead shows you the real cost of getting a usable result.
Decide what you alert on and what you just store
Not every field belongs in a real-time alert. Fields like feature, model, or team are broad enough to alert on directly; a sudden jump in any one of them is worth flagging immediately. Fields like individual user IDs or individual request IDs are too granular to alert on one-by-one. Store that data instead, and use it to investigate once a broader alert has already fired.
Enforce spend limits in one place, not inside every app
If each team builds its own cost limit into its own application, the limits will be inconsistent, and some workflows will have none at all. Enforcing spend limits at the gateway, before a request ever reaches a provider, means every team works under the same rule.
Review your pricing data on a schedule
Providers update pricing, add models, and change how they charge for cache or reasoning tokens. If the pricing your monitoring relies on isn’t reviewed regularly then your cost numbers quietly go stale, even though nothing about your usage changed.
Cost Monitoring for Agentic and Multi-Step Workflows
An agent doesn’t answer once. It plans a step, acts on it, checks the result, and decides whether to go again. Each of those steps is a separate model call. A single task might take four calls to finish, or forty. The agent decides that in real time.
That changes how cost needs to be tracked.
Group every call under one run ID
An agent’s calls need a shared ID connecting them back to one task. Without it, a run that took twenty steps looks like twenty unrelated, ordinary requests, none of them individually alarming, none of them flagged.
GitHub’s own agentic workflows tooling tracks this exact thing under what it calls an “episode,” a run ID that ties every call in one task together, so cost can be read as one number, not twenty small ones nobody looked at twice.
Split planning cost from execution cost
Not every step in a run does the same job, or costs the same. A planning step, where the agent reasons about what to do next, is usually short. An execution step, where it calls a tool or generates a longer output, usually costs more and swings wider. A run that’s expensive because of long, repeated planning is a different problem than one that’s expensive because of one costly tool call. Lumping both into a single number hides which one it actually is.
Set a hard ceiling on steps per run
A run that fails cleanly is cheap. A run that loops isn’t. It keeps retrying the same tool call and getting a bad result back each time. No single step in that loop looks wrong on its own.
GitHub’s agentic workflows platform caps this directly with max-turns. It limits chat iterations per run so a stuck loop stops itself instead of running until someone notices the bill.
Measure cost against whether the run succeeded
Two runs can cost the same and mean opposite things. One reaches the right answer in six steps. The other burns the same budget and fails anyway. Cost per successful run separates real work from a run that’s just expensive and stuck.
Common LLM Cost Monitoring Mistakes
- Switching models without checking quality: A cheaper model lowers cost per request. But if it fails more often and triggers retries or manual fixes, the real cost can end up higher than before.
- No one owns the cost data: An alert means nothing if nobody’s responsible for acting on it. Without an owner per team or workflow, alerts pile up unread. The same spend keeps repeating month after month because no one was ever accountable for questioning it.
- Missing cost after a prompt change: A longer system prompt doesn’t look like a cost decision when it ships. But it raises token count on every request after that. A one-line addition to a shared prompt template can quietly raise cost across every feature that uses it.
- Is it a spike or a slow creep? A sudden spike is easy to catch. A cost that rises gradually isn’t, and by the time it’s noticed, it’s already the new normal. A monitoring setup built only for spikes will miss the slower pattern entirely.
- Rolling out a cost change without testing it first: A cheaper model looks good on paper. But shipping it to every user without checking real traffic first can mean trading a lower bill for a worse product.
- Comparing teams’ spend without adjusting for what they do: One team runs simple, high-volume queries. Another runs fewer, complex ones. Comparing their totals without that context makes normal usage look like overspending.
Tools for Multi-Provider LLM Cost Monitoring
Most tools in this space fall into a few categories, and picking the wrong one for your setup usually means rebuilding the same tracking work twice.
AI gateways
AI gateways sit between your application and every provider you use. Every request passes through one layer, so it captures cost in one format regardless of which provider handled it. Without a gateway, adding a new provider usually means adding a new integration, a new billing format, and a new place someone has to check. With one, adding a provider means pointing it at the same layer everything else already goes through.
LLM observability
These platforms go further than cost alone. They tie spend to traces, prompt versions, and quality scores, so a team can check whether a cost-saving change (like a cheaper model) actually held up in production. This matters most for teams that ship prompt or model changes often, where cost and quality need to be reviewed together.
Standalone cost trackers
Standalone cost trackers focus narrowly on spend, usually through lightweight proxies that log token usage and estimated cost without the broader tracing layer. They’re a reasonable starting point for a team on one or two providers with no immediate need for evals or quality scoring. But cost sits on its own here, disconnected from whether the request that generated it actually worked.
Which category fits depends on whether cost is the only thing you need visibility into, or whether it needs to sit alongside quality, latency, and routing decisions in one place.
A few things are worth checking before picking one, regardless of category:
- Does attribution happen at the request itself, or does it rely on a tag surviving in the invoice? The two behave very differently once billing happens, and only one of them is reliable.
- Can it group an agent’s calls into one run, or does it only see individual requests? A tool built for single-call workloads won’t show a runaway agent loop the way one built for multi-step workflows will.
- Does it only report after the fact, or can it act while a request is happening? Some tools stop at visibility. Others can enforce a limit before a request goes out.
How AISquared Solves Multi-Provider LLM Cost Monitoring
Seeing a cost problem after the invoice arrives is too late. AISquared fixes this at the point the request is made.
UNIFI tracks token spend and costs at the execution level. It links every request directly to the user, workspace, workflow, or business unit that made it. There are no tags to track and no reconciliation to do afterward.
The most effective way AISquared monitors and controls cost is at runtime through the UNIFI Model Routing mesh. Administrators set strict cost guardrails, latency targets, and hosting rules directly in the platform. The router intercepts every prompt and dynamically evaluates task complexity before deciding where it goes. The router dispatches simple tasks, like SQL queries or general chat, to lower-tier, highly cost-effective models like Bolt-7B. It reserves expensive frontier LLMs strictly for complex reasoning.
Conclusion
Multi-provider LLM cost monitoring isn’t a formatting problem. Different token definitions, mismatched billing formats, and no shared attribution model all make it genuinely hard to see where spend is coming from, and that visibility is the necessary first step.
But visibility alone still reports after the fact. By the time a dashboard shows a spike, the tokens are already billed. The real fix has to sit at the point a request is made, catching a routine query before it reaches a frontier model, not explaining it after the invoice arrives.
As AI usage grows across more teams and more workflows, efficient spend stops being optional. Scaling AI sustainably means building cost efficiency into how the system runs from the start.
Frequently Asked Questions
Can I monitor LLM costs without a gateway or proxy?
Yes, but it takes more manual work. You’d need to pull usage data from each provider separately and reconcile it by hand, since nothing normalizes it for you across providers. A gateway or proxy removes that manual step and gives you one combined view instead of three.
How accurate are estimated token costs vs. provider invoices?
Estimated costs are usually close, but rarely exact. Gaps often come from missed cached-token fields, an outdated pricing table, or a fine-tuned model still priced at its base-model rate. Retries can throw off an estimate too, if they’re not logged separately from the original request. When your numbers diverge from the invoice, check your pricing data first before assuming the estimate itself is broken.
How do I track costs for self-hosted models?
Self-hosted models don’t come with a per-token invoice, so cost tracking shifts from pricing to compute. Track GPU time and infrastructure usage per request instead of a token rate. Attribute that usage the same way you would a provider call, by user, workflow, or business unit, so self-hosted spend shows up in the same breakdown as everything else.
