Last July, a unit conversion error in Cost Explorer started showing customers bills in the billions, some in the trillions. A student in Delhi watched a $1.28 monthly bill turn into $10.9 billion. Someone's normal five-dollar month became $1.7 billion. Nobody was actually charged. It was bytes read as gigabytes, a decimal point in the wrong place, and AWS fixed it within a day.
But for a few hours, a lot of engineers sat there staring at a number that made no sense, refreshing the page, waiting for it to resolve itself into something sane. Some, in a panic frenzy, started to delete infrastructure before AWS even confirmed it was a display bug.
That's what such an impossible number does to you. It doesn't just cost money, it produces a specific kind of panic, the kind where you're genuinely unsure if you still have a company.
Now imagine you log in and see that number, and it's not a bug. It's 100% real. That's where AI coding spend is headed in a tokenmaxing reality.
Not because someone fat-fingered a decimal.
Because the controls to stop a runaway bill exist, sitting in a dashboard somewhere, and almost nobody turns them on. AWS's bug got a fix and a "slight calculation error" tweet within a day, because someone was on the other end who wanted it gone. Nobody's coming to save you from your $500 million number, because nothing's broken. The number is real, and it's real because the system was built to let it get that large - it's a feature, not a bug.
Alerts don't stop anything
That's the whole story of AI coding cost governance in a nutshell, right now. The controls are available, they just don't enforce anything - so having the features "available" will not help your next invoice.
Most budget tools don't actually stop anything when you hit a limit. What happens instead is a Slack ping, a red badge on a dashboard, an email telling you that you've crossed 80 percent of your monthly allowance.
But the outcome stays the same - the tokens keep flowing exactly as before. That's not a control, it's a smoke detector that watches the house burn and files a report after the fact. An alert tells you spend crossed a line.
A very important distinction, though, is that a cap stops the spend at the line. Those aren't two versions of the same feature, they're different categories of tool. Security teams learned this distinction the hard way long before cost governance had to. Knowing you have a thousand open CVEs doesn't stop a breach in real time. Information isn't the same as enforcement, and a budget tool that only tells you what happened is making the same mistake a vulnerability scanner makes when it's treated as a defense instead of an inventory.
Vendors like to ship alerts because alerts demo well and it rolls the responsibility onto the receiver. Set a threshold, trigger a notification, and everyone in the room nods like something was just solved. But an alert has no authority to stop a request from executing. Put 150 engineers on frontier models through an agent all day and the gap between "you're at 80 percent of budget" and "you blew past it hours ago" closes faster than any human is going to react to a notification. The alert still fired right on schedule, but the spend it's describing already happened hours ago.
That's the shape of the $500M bill, without fail. Every. Single. Time.
So let's actually look at how the big tools handle this Because the devil is always in the details - and often where the whole thing falls apart.
Copilot. There's a governance dashboard, and it looks the part. But "stop usage" is off by default. Budgets act as alerts unless someone explicitly hardens them. Metered usage is on by default. Credits get forfeited monthly, used or not. In a demo you see a ceiling. In production you get a speedometer that watches the overage happen.
Claude Code. Seat allowance isn't metered in dollars until you opt in to usage credits. And there's no native, real-time, per-user attribution. Want to know which engineer or which key is torching the budget right now? You're building your own OpenTelemetry stack to find out. The controls to prevent a runaway bill were available. They weren't enforced. That's the $500M incident in one sentence.
Cursor. You get usage analytics. Requests, diffs, lines of code. What you don't get is dollar attribution. Billing runs in arrears, so there's no hard ceiling by design, just an invoice that shows up after the damage. And real cost governance is locked behind the Enterprise tier, so the teams most likely to overspend early are the ones least likely to have guardrails.
See the pattern?
Every one of these vendors can say, with a straight face, that governance is "available," yet every single one of them enjoys the outcomes when enforcement is left as something you opt into, harden yourself, or upgrade to reach.
OK, so what does "governance that enforces" actually mean? Here's the bar I'd hold any tool to before I put my company's card behind it, and it consists of two pretty simple things:
1. A hard budget caps at every level. User, team, API key, org. Not thresholds that ping. Caps that enforce when configured.
And I want to be specific about what "enforce" means, because this is exactly where the devil we mentioned earlier lives. In Kimchi Coding, every inference request runs through the proxy, and the proxy checks it against the budget before it runs. If you're at or over your limit, you get an HTTP 429 back and the request never executes. The tokens never leave the building, spend is stopped in its tracks. That's a cap.
If it doesn't stop the request, it's an alert wearing a cap's clothes.
The caps cascade, with the org setting the ceiling and team, user, and API key limits nesting underneath it. Whichever scope is tightest wins, and a per-model limit still binds even when it's stricter than everything above it. That's what stops a service account on a CI runner from quietly outspending the whole org just because nobody remembered to set a limit on it specifically.
2. Per-user cost attribution, in real time. You should be able to see, right now, what every user, team, key, and org is spending. Not reconstruct it next week from logs.
And it should be real because of how it's built, not because of a dashboard someone bolted on. The cost gets computed at the proxy from the model plus the actual token counts as requests flow through. For per-team visibility, tag requests with a team header and the teams show up on their own. No unnecessary admin setup, or config screens, no pre-registering every squad. First tagged request arrives, the team exists, and it works across the agents your engineers already use.
Put those two together, per-user cost attribution and hard budget caps, and you've got a governed AI coding platform instead of a dashboard.
Let me bust one myth here, because I'd rather you hear it from me than find out the hard way. "Governed" means the governance is built and ready to enforce, not that it's already running before anyone's touched it. The caps aren't on the moment you sign up. They're available from day one, and turning them on is part of the setup, the same way you'd configure any other control before trusting it. That distinction matters, because the tools that oversell "default" governance are the same ones whose customers end up with the surprise invoices.
Our own bill is the proof
The proof of the pudding is in the eating - so preaching enforcement as a vague idea is easy. Here's the pudding instead. And we ate our own pudding.
CAST AI runs 150 engineers on this setup, generating roughly 36 billion tokens a month of real agent work, not a benchmark. Measured over a 30-day window against a 100 percent Anthropic Sonnet and Opus baseline, the result was 12x cheaper than going frontier-only, with the same engineers doing the same work, held to the same bar for output quality.
That 12x didn't come from switching to a cheaper model, and it didn't come from silently degrading what people get back either. It came from smart routing combined with governance that actually works. Enforce the caps and keep attribution real-time, and you stop paying for the runaway tail, the part that turns a normal month into a board-level problem.
Kimchi Coding is built by the same team behind CAST AI, and the bill we cut for ourselves was our north star, before we ever shipped a product to anyone else. We also don't train on other people's data, ever. Sovereignty to us isn't a slideware feature, it's the fundamentals of how the product is built.
The part everyone gets backwards
The pushback I hear constantly is that governance is always synonymous with friction and it sounds like it's built to slow developers down. It isn't, and framing it that way is how you end up building the wrong control and losing your engineers in the process.
Developers don't care about your budget dashboard. What they do care about is whether the agent is good enough to trust with real work, and that's a non-negotiable gate on its own. If the agent isn't genuinely good, nothing else matters.
Governance sits on a different axis entirely.
It's the buyer's problem, not the developer's, and the split is clean: your engineers get the best agent available, and you keep control of the bill. Those two things were never actually in contention. The tools that made them feel that way did it by making enforcement expensive or optional, which left degrading the developer experience as the only lever they had for controlling cost. Caps that enforce at the org, team, key, and user level let you protect the invoice without your developers ever noticing.
AWS had a bug. Your exorbitant bill is largely a feature for your AI coding agent, sitting there by design, unconfigured, waiting for enough volume to make it a business emergency.
So if you're picking an AI coding tool this quarter, ask the vendor one question and make them answer it straight: when a team hits its budget, does spend actually stop, or does someone just get told, after the fact, that it didn't? Everything else is detail.
Caps that enforce, not alerts that only notify. Real-time attribution you don't have to build yourself. The best agent your engineers will actually use, and a bill you actually control.
See how Kimchi Coding does it at Kimchi.dev.
Top comments (0)