← All posts This week Tom's Hardware reported that Microsoft has been quietly discouraging its own engineers from using Claude Code, in favour of its internal Copilot CLI, on cost grounds. Meta and Amazon have made similar moves. Inside Amazon, employees have confessed to "using AI unnecessarily to pump up internal usage scores." Nvidia's CEO Jensen Huang has told the industry that engineers should be consuming AI tokens worth "at least half their annual salary," every year. (Tom's Hardware has the round-up.)
The single most uncomfortable number in that piece is buried halfway down. Agentic AI traffic burns up to 1,000 times the tokens of a single chat call. Peter Steinberger, an indie developer building on the agentic pattern, ran up over $1.3 million in token costs in one month by himself.
These are not bills you can absorb. They are bills you have to see the moment they start, because by the time the dashboard catches up they have already happened.
The CFO's dashboard is honest, and that is the problem #
Every cost dashboard in the field today was built for chat-pace traffic. A user types a prompt, the model answers, the cost line appears in your ledger a minute or two later, the dashboard refreshes a few minutes after that. By the time the CFO opens the tab in the morning, the spend from yesterday is settled, attributed and visible. This works perfectly for chat, because chat is slow: the number of calls per user per hour is in single digits.
An agent does not work that way. An agent receives one human instruction and then talks to a model dozens of times, sometimes hundreds, in seconds. Each call costs money. Each call is another event the dashboard has to absorb. And the agent does not for the dashboard to catch up.
The dashboard is not lying. It is doing exactly what it was built to do. It just was not built for this.
Tokenmaxxing makes the problem unsolvable retrospectively #
The Tom's Hardware piece reports what Amazon, Meta and Microsoft are now quietly admitting: when an organisation announces an AI adoption target, the workforce will hit it. If the metric is "tokens consumed per engineer," engineers will consume tokens. They do not have to be malicious. They just have to be employees responding to an incentive.
So now there are two effects compounding in the same direction. Agent traffic generates many calls per task, and the people running those agents have a reason to keep them running. The bill scales with the call count and the call count scales with the headcount.
A monthly attribution exercise has no answer for this. By the time the report is run, the spend is already in the ledger and the next month's spend has already started. The CFO is always one cycle behind the runaway.
Seeing it is not enough. The control has to be in the path #
The only place the spend can be acted on is the same place it is incurred: the request path, the moment the call is about to be made.
That changes what "cost control" has to mean. It is not a daily digest. It is not a Slack alert at the 80% threshold. It is the ability to decline, downgrade or reroute a call before the provider sees it.
Three properties matter:
In-path attribution. The cost is priced and tagged to the team, user, application and model the moment the call returns, not in last night's batch job. The CFO's question becomes a query, not a forensics project.Hard caps that enforce, not alert. A per-team budget thatstopsthe next call when it is breached, not one that sends an email about the call after it ran. The runaway agent is interrupted in seconds, not on next month's invoice.Cost-based routing. When two providers can serve a request inside the policy and quality bar, the cheaper one wins by default. The application's hardcoded model name is treated as a hint, not a hard requirement. The application keeps working; the bill stops growing for the wrong reasons.
| Chat-pace observability | An in-path control plane | |
|---|---|---|
| When the spend is visible | ||
| Minutes to hours later | The moment the call returns | |
| What happens when a cap is breached | ||
| An alert | Traffic is stopped or rerouted | |
| What the CFO can answer in real time | ||
| "Last week, roughly" | "Right now, exactly, per team" | |
| What the runaway agent sees | ||
| Nothing, until billing day | The cheaper model, or a 429 |
The difference is not "more dashboards." It is whether the layer in front of every AI request is something the finance team has to chase, or something that has already made the right decision before the call leaves the building.
The executive takeaway #
When agent traffic arrives in your organisation, three things happen in the same week. The number of calls per task multiplies by a factor that nobody warned you about. The internal incentive to use AI keeps the agents running. And the dashboard you bought last year, on the strength of chat-era benchmarks, starts reporting a number that was already wrong by the time the page loaded.
Microsoft, Meta and Amazon all have engineering benches measured in the tens of thousands of people and budgets measured in the tens of billions, and they are pulling back. A regulated mid-market CFO does not have those benches and cannot afford those budgets. The only viable response is to stop trying to catch the runaway after the fact and start governing the request path itself, where the spend is actually decided.
Disclosure: this is the problem my company, Vidai, exists to solve. Our take on cost control that acts, not just alerts, is at vidai.uk/use-cases/control-ai-spend. The runaway in this article is real regardless of what you do about it.