The $70,000 Bill for Tokens Nobody Generated
A billing bug at a major AI provider kept charging one company even after every API key was deleted. Spend caps didn't exist yet — and even now, they wouldn't have fully stopped it.
In 2025, a pricing configuration error at a major AI provider caused its billing system to charge developers for output they never actually generated. Some companies woke up to bills exceeding $70,000 for usage that simply never happened.
The part that should concern every finance leader isn't the bug itself. Bugs happen. It's what came after.
One affected company reported deleting every API key tied to the account, only to watch the erroneous charges keep climbing — by hundreds of dollars within minutes of the keys being revoked. Disabling the billing account entirely didn't fully stop it either. The meter kept running on a bill for usage that was never generated, well past the point where every conventional "off switch" had been thrown.
The provider's eventual fix, months later, was to introduce spend caps. It was the right move, and one other major providers had already made. But it also reveals the limits of relying on the vendor alone to catch this kind of failure.
Spend Caps Solve the Wrong Layer of the Problem
A spend cap stops new charges once a threshold is hit. It does nothing about charges that are already wrong — a billing bug, a pricing misconfiguration, a duplicate charge — because the cap is measuring the same broken number the provider is generating in the first place.
And spend caps come with their own tradeoff. They don't warn you as you approach a threshold. They cut off access when you hit it. In a production environment, that means a feature stops working, with no notice, until the next billing cycle. Finance teams are left choosing between two bad options: set the cap low and risk outages, or set it high and lose the protection it was supposed to provide.
Neither option tells you anything about whether the number on the invoice is actually correct.
What Actually Catches This
The company in this story didn't find out about the erroneous charges from a dashboard. They found out from the invoice — after the damage was done, and after multiple attempts to stop it through the provider's own controls had failed.
The only thing that would have caught this earlier is independent visibility — a system tracking actual usage against actual billed amounts, across every provider, outside of the provider's own reporting. Not because providers are acting in bad faith, but because when the bug is in their billing system, their billing dashboard is the last place you'll see it clearly.
That is a fundamentally different problem than "we need a spend cap." It's "we need to know what we're being charged for, independent of the system that's charging us."
What Real Visibility Looks Like
Real AI spend visibility means knowing, at any moment, what your company is spending across every provider — and being able to compare that against what you expect to be spending, based on actual usage you can independently verify.
It means catching a charge that doesn't match any usage pattern you recognize, the moment it appears, not thirty days later in an invoice.
It means your finance team isn't relying solely on the same vendor dashboard that produced the error to also be the one that catches it.
That is the standard spend360.ai holds itself to. Not because billing bugs are common, but because when they happen, the only real protection is visibility that doesn't depend on the system that failed.