Buried in the LiteLLM v1.91.0 changelog, between a new Tencent provider and a Microsoft Purview guardrail, is a line that reads like plumbing: "roll up MCP tool spend to user counters and usage UI." Shipped July 4, 2026. Six words of intent. It is one of the more consequential moves the gateway has made this year, and almost nobody will notice, because it fixes a cost you couldn't see in the first place.

The bill that wasn't there#

For two years the unit of agent cost was the token. Every cost dashboard, every budget alert, every max_spend cap was built on the same primitive: count the tokens in and the tokens out, multiply by the model's price, sum by user. It worked because, in the chatbot era, the token was the bill. The model was the only thing that cost money.

Agents broke that quietly. An agent's expensive turns are increasingly not the ones where it thinks — they're the ones where it acts. It calls a search tool, a code sandbox, a retrieval endpoint, a payments API. And here is the accounting gap: an MCP tool call is a function invocation, not a model call. It emits no tokens of its own. To a token meter, a tool call is free.

A token meter prices what the model says. It is structurally blind to what the model does — and doing is where the agent bill moved.

That blindness would be tolerable if tool calls were cheap. They aren't, and the reason they aren't is the non-obvious part.

A tool call is two bills fused#

The cost of a single tool call has two components, and they live in different places.

The first is the invocation itself. Some tools bill per request. Some tools are agents wearing a function's clothes — they call another model internally, so one "tool call" hides a full inference you never see on your model dashboard because it happened on someone else's.

The second is subtler and usually larger: the tool's result. Whatever the tool returns — a page of search hits, a stack trace, a JSON blob — gets injected back into the conversation and travels in the prompt of every subsequent turn. A 4,000-token tool result isn't a one-time charge; it's a tax the model pays on repeat until the context is trimmed. This is the same quadratic that makes long agent runs expensive — cost that scales with the square of the conversation, seeded by tool output rather than by the model's own words.

Add those up and you get the real shape of the problem: the true cost of a tool call is only visible to something that sees both the call and the model turn that follows it. The MCP server can't see it — it knows its own invocation but nothing about the tokens its answer will cost downstream. The model logger can't see it — it prices the follow-up turn but has no idea a tool caused the bloat. The only vantage point that sees both is whatever sits between the agent and both the tool servers and the model.

That vantage point is the gateway.

Why the proxy wins the meter#

LiteLLM already occupies the seat that matters. It is an AI gateway that proxies model calls and tracks their cost per key, team, and user. And it is also an MCP gateway: a fixed endpoint the agent calls for every tool, with access scoped by key and team. Both the tool call and the model turn it triggers pass through the same process.

So "roll up MCP tool spend to user counters" is not a new feature so much as a land grab. The proxy already metered the token half of the bill. This release annexes the tool half into the same counters — the same usage UI, the same per-team budgets, the same spend caps you set per run. The tool layer stops being a shadow economy and becomes a line item next to tokens.

Read strategically, this is a bid for a specific throne. Model routing has commodified — every gateway proxies the same 100 providers, and the margin on "we call OpenAI for you" is gone. The next defensible position is governance: the chokepoint that can attribute, cap, and audit everything an agent spends, tools included. Whoever owns per-tool spend attribution owns agent FinOps. This changelog line is LiteLLM planting a flag on the half of the bill its competitors' token meters can't read.

The catch worth stating#

None of this is free of assumptions, and the load-bearing one is routing. The gateway can only meter what flows through it. If your agent calls MCP servers directly — a common setup, because direct is one hop faster — the tool calls never touch the proxy and this counter stays at zero. You get attribution only for the traffic you deliberately funnel through the gate, which is exactly the tradeoff tool-approval defaults made: the gateway's power is its centrality, and its blind spot is anything that goes around it.

And "spend attribution" is not the same as "true cost." Rolling invocations into a counter tells you who called what, how often. Pricing a tool whose real cost is a downstream token tax, or a hidden sub-model call, still requires the follow-up inference to route through the same meter. Attribution is the floor, not the ceiling.

But the direction is unmistakable, and it's the tell that matters. For two years the meter lived on the model. This week it moved to the tool. The agent bill went where the agent's money was already going — and the gateway was standing there to catch it.