We're going to need default hard budget caps on pretty much everything

It’s incredible that in 2026, AWS and GCP are only just now introducing this. It’s possibly one of the most obviously needed features for a cloud provider.Also, does anyone know why it’s taken this long? I suspect it’s a technical reason. While one could be cynical, I doubt it’s an intentional business/product decision. Hard spending caps are both excellent product differentiators and could possibly save these providers money as they don’t have to forgive their users when they accidentally over-use a service. reply: It's one part technical, one part a product decision. The technical part is that billing is not actually instant. As a most basic example, a VM reports its billing units every X period of time it is active. If there is some network blip but it's still running, then that billing data could be delayed.The product level decision is that "shut down everything" is something the customers you want to target don't actually want. Are we including deleting RDS data? S3? Glacier storage? If so then the headline will just change from "Hobbyist got charged XXXXXX on AWS" to "Business literally had all their data deleted because a hacker took over their VM and mined bitcoin"....

Wait, Google Cloud finally added hard caps on spending per service? I've been wanting that for so many years! They sure took their sweet time.https://cloud.google.com/blog/topics/cost-management/new-ear...Edit: Ugh it's fake. Literally only works for four random services, unsupported for all the rest. Completely useless for all of my projects. Also dumb that the only supported term is "monthly" considering that months are different lengths, and that they don't bother to account for credits or discounts. Maybe next decade they'll get around to implementing something useful. reply: The hard caps work on projects created in AI studio

Network saturation is difficult. Even if you turn off the endpoint you can still saturate the network in between. And it's still bandwidth.I actually think network ACL triggers based on billing might be the only way to really enforce this.I witnessed a DDoS attack once that changed how I think about billing. It was locally provisioned hardware and the attackers had saturated the switches. Naively I said "just block the CIDRs" but the problem was the incoming ram is so saturated that it can't even get to the point of "deny" in the firmware.So from a technical perspective if there's an internal DDoS at AWS what do you do? Do you turn off the endpoint? Do you drop the sources from hitting it at the router? And even that costs money. Anyway that incident gave me a different level of appreciation for this challenge.Edit: this is mainly targeted at the people complaining why this took so long. At some point in scaling even telling you "no sorry" in a nice way is expensive. I'm sure recruiters can sympathize with this nowdays.

I used to work on a support team of a well known backend type service that had hard budget caps.It was, unfortunately, a nightmare. There were tons of tickets and even threats of lawsuits from customers whose service got cut off hard at the worst possible time due to organic growth/going viral/big event/nobody knew about the limit/etc. Not only did they lose all the leads and revenue they would have gotten from that bump, but they also pissed off their own existing users who suddenly couldn't use the service either.Generally speaking, it's much better to use alerts instead of hard limit. Even in the worst case (hackers pwn your credentials and mine Bitcoin or whatever) the rest of your business is unaffected and you can negotiate with the billing department at comparative leisure.This is all assuming you have humans operating the service. If you're letting AI agents yolo infra in prod, you have a whole series of new problems. reply: Yes, this is an important point although it has changed with A.I....

These shouldn't even exist without a negotiated contract.I can subscribe to your service for a specific fee on a monthly basis ($20/month say), and take the risk of losing that month's fee if your service or I make mistakes, or I can choose to drop another $20 mid-month, or anything for convenience.Saying that the computer will "control" the billing and can run haywire tells me that I don't want to be anywhere near your pile of bad incentives. reply: Monthly electricity bills are based on usage, and it works well but there’s a limit to how surprising a bill can be. The difference is the relative orders of magnitude you can be charged for these services you can go from 20$/month to 200k/month without warning.

Hard caps are rare because companies find it more profitable to forgive sympathetic individuals' bills while raking in profits from corporations whose services have gone awry reply: Clearest explanation ever.Plus, nobody wants to be the fired PM who said "I spent our eng. hours to achieve -20% revenue".

I wonder if BigCorp adding spending caps is due to them getting sick of customers solving it for themselves with virtual cards. reply: Virtual cards don't solve anything. They just get you sent an invoice instead.It works for some non-B2Bs.

Having a monthly summary or estimate of how your spending is going would be really useful, too.Even if we have a negotiated yearly contract for $X spend per year, maybe we’ll hit that spend in 6 months instead of 12. Having some kind of automated telemetry saying how we’re trending would be so useful.I’ve gotten vague warnings from customer success people saying vaguely that, but without any warning of what’s truly happening. The more we abstract away from money (tokens, credits, etc), the more we need a way to translate right back to money, to see how close we’re getting to any limits over time.I don’t want to find out in month 5 that the contract which was expected to cover a year is now going to run out in 14 days.

So, prepaid services which you top up?I know AWS and similar sites have no such concepts, but other than those, this is an existing option of most kinds of service providers.Realistically, most providers can't even allow you to consume $10k usage if they don't have the certainty that you can pay up. Prepaid is what gives them that certainty.

I learned this the hard way with OpenAI last week. A key got hacked and a Chinese-language bot used $300 in tokens in an hour.I had a spending limit on for $30, so why did it keep charging? Because the spending limit is meaningless without a hidden checkbox called “enforce spending limit,” which is (or at least was for me) off by default.To OpenAI’s credit, they refunded the money.

My org has a leaderboard for AI spending each month, and I have found it interesting how fast the distribution decays, just within the top 10 users. I often think “what did these people do with all those tokens?” It’s interesting to think the answer to that question is “maybe not a lot?”

Where I live, you can just not pay for something and it is cancelled.Phone service, bank card, home internet etc.If you don't pay your bill than they just cancel your membership and it works ok.People in western countries are just getting shafted by companies for (mostly) no reason because an alternative balance is just inconceivable.

"Oh hai. I'm hooked on the drugs. Please stop me from taking more. kthnxbai."Seriously. You all asked for this.

It should be illegal to not have them

So weird, cause it seems a lot of services are suddenly adding them. Huh, wonder what changed?

I read the title and thought it was going to be a rant about how nations will get out of crushing debt...

> In an ideal world, our agents could help with this.Not exactly the sort of case Simon has in mind, but I tell Claude to keep to hard daily limits on its OpenRouter spending for two long-running projects [1, 2].A Routine for each project fires ever few hours, and Claude decides itself what to do in each session. It does tasks that require calls to other models through OpenRouter only when it is still within its daily budget for that project; after it reaches that cap, it does other tasks that don’t require extra spending.[1] https://github.com/tkgally/je-dict-1[2] https://github.com/tkgally/eex-dict

Uncapped usage is just corporate infinite scrolling in social media. Once you're hooked you just can't stop.

We always did, the clouds convinced us that overages were the norm. You can blame credit ratings as another vector for big business to screw everyone over. Everything should have been pay in advance with an alternate billing method for overages if you want it.

I had an api key set to read only that somehow ran up a $400 bill, I contacted openai about it and never heard back. Not quite the same thing, but still, I find this very annoying.

It'd be nice if more than AI spend worked this way, autoscaling is almost a mixed blessing because unpredictable pricing can be worse than the cost savings...

Ubicloud does not have hard budget caps, which I only realized this morning after moving all my CI over to them over the past few months. Fortunately I didn't learn the hard way.

I'm surprised this isn't law. Should it be?

This could have been written in 2006

Counterpoint: if you can automate API calls on the client side, why can't you automate billing caps? If you want a machine that can run 24-7 and make money for you while you sleep (which let's face it is the motivation for a lot of AI takeup), isn't the onus on you to install cicuit-breakers?

Yes and no. I suspect many of the hard limits were set arbitrarily, and we'll see a relaxation of limits as people get frustrated with the limited use they get out of them. And some services will genuinely need to be re written to support higher rps or risk losing customers

Cloudflare also doesn't have any hard budget caps.

The solution is to not give agents access to MCP servers.The entire MCP ecosystem is ludicrous. You’re paying for inference for an agent to make the same decisions over and over again, and yet the actions they’re taking can be so easily written by those same agents into a bash script you can run again and again, deterministically and for free.MCP is the problem. Having agents “use a product on your behalf” is the problem.The pattern you’re looking for is that agents should write scripts that use products for us, and that doesn’t need a new protocol.