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". The only people who really want this are hobbyists and it's not a market segment that's worth chasing. Easier to do the status quo of forgive afterwards then even open the can of worms of deleting all of a business's data and all their backups just because they had a 100k overrun.

A very charitable take, in light of tech industry habits of exorbitant rent-seeking in scenarios of Platform Dominance (e.g. Google and Apple on the app store). We should remember AWS and Google companies are among the best in the world at A/B testing and extracting revenue from cloud services.

When you're one of only two real options out there, you can afford to demand users put up with things that on their surface seem ridiculous. Such as a billing system that (oops!) makes it difficult for customers to see where their costs are coming from, trim their largest sources of spend, notice meaningful changes in line item prices, or limit their spend. Wild how they can figure out a million different advanced services but gosh-darn-it can't figure out the hardtech of displaying line items.

Large enterprises can afford employees who are tasked full time with unwinding this capacity to mitigate the impact of these billing headaches. But I think this measure is introduced now because LLMs introduced a risk that these billing specialists could not control without caps.

> While one could be cynical, I doubt it’s an intentional business/product decision

Why is egress more expensive than ingress in clouds? To lock in users.

Why cloudformation in some cases leaves s3 buckets laying around after destroy? To keep charging those cents.

Why no caps? To get the user into the mindset of we ll pay whatever they say, and charge the ones that dont notice or dont ask for the refund. Same reason why my newspaper subscription autorenews.

Nothing cynical about both of these. I think assuming it is technical is naive.

I had a $.20/month recurring charge from AWS that I could only remove¹ by completely deleting my AWS account. That was enough to get me to give up on AWS for personal projects.

⸻

1. The key word was “I.” Maybe someone more skilled at navigating AWS’s menu structure than I could would have done it quickly and easily, but even though I knew what it was for, turning it off and not getting billed for it turned out to be a huge challenge. Thankfully it was only $.20, but if I were using the service for something that generated actual bills, that $.20 (and possibly more) would end up quietly siphoning money out of my pocket into Amazon’s).

It's definitely technically difficult. You can't easily estimate how much an operation is going to cost before you kick off that operation, which means as soon as you get close to the limit you are at risk of tripping it.

Consider something like a "select * from bigtable" SQL query that might process a trillion rows. Hard to know that's going to cost $100 until after you have run it.

If these cloud providers had needed a standard customer acquisition strategy to grow to their current size, hard caps and other “training wheels” features would already be in place to get people interested in and comfortable using the platform, with the hope of eventually getting a foothold into Enterprise like most SaaS startups have to do (“enjoy our product on a side project and then recommend us to your CTO!”). But AWS and GCP got to start as in-house providers for their own constellations of massive sites and back out from that to serving other hyper scale businesses first. The lack of friendly on-ramps and starter account features is a reflection of that origin more than anything.

Because most enterprise users would much rather have overages in billing than outages. The opportunity costs on any serious service I deploy dwarfs usage pricing, at least at the level a generic cloud can determine.

So it’s a feature the best customers don’t want, that adds risk to those customers deployments, to appease the worst customers.

At least historically. Perhaps Simon is right that the calculation has changed.

This is one of those features that customers think they want without having thought it through:

“Never let me spend more than $X” also means, “Shut down my business-critical app/service/solution at 2 am on a Sunday morning because Joel in IT forgot to plan for the new report runs.”

The product design work to let customers have the first thing without risk of major pain from the second thing is non-trivial.

It is a technical reason. Basically cloud billing is much more granular and across many more services / line items than most things that basically the pipelines that figure out how much you have spent take a long time to know how much you have consumed. I believe all cloud providers with granular usage based billing have this problem.

> 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.

GCP did have a budget cap previously. I think the new one is just more fine-grained to apply to specific services.

How do you hard-cap S3 and other persistent data storage?

"Sorry, you had a hard cap on AWS spend so we deleted all your S3 data on August 27th". Yeah not going to fly.

As a hobbyist, I pulled completely out of AWS when I realized the billing issues could never be resolved. Even/especially with tight monitoring and hard caps.

Even as a hobbyist, even as a most careful and judicious architect and admin, I could not prevent my VPS from incurring costs beyond my control. That means that the entire Internet, anyone with some kind of material access to the VPS, and especially any user or authorized entity, they could incur costs to me without bound and without notice until slapped with a bill.

Even something as simple as egress charges aren't under your control. So if people download enough data, you pay for all of it? It seems like an absurd proposition.

It's like opening a business somewhere in a war zone, and vandals and squatters are constantly attacking your storefront, and maybe you have a band of toughs as security and some good cops to defend awhile, but you're utterly in a war zone with adversaries acting far beyond your control.

As a hobbyist, I could never again justify running a pure VPS with the Linux and stack on top, as I ran before like the MediaWiki server. I was excited to learn all the vocabulary and skillsets of cloud services, but on the "free tier" uncapped, there was no telling when I'd be presented with costs beyond my ability to handle. And I do not see how a Fortune 500 would have any different calculus in this regard.

Most businesses in recent memory were "their own landlord" of on-prem equipment and machine rooms. Yeah, they began to outsource even their IT admin, but the machinery was in-house until the cloud services took over. Did we go through a phase of collective machine rooms or data centers with a collection of tenants? It seems we skipped from "homeownership" to "feudalism" with the Cloud Providers being the Princes [beyond mere Lords] who provide minimal resources to the serfs now. I can see many corporate execs who begin to hate "AI Data Centers" just for what they have become: a very attractive and irresistable way to reduce your capex and footprint and physical plant, by "migrating to the cloud" but is that really a better status quo after all your revenue is being pumped into AWS?

And in view of what I just wrote, a "hard budget cap" checkbox is even worse for you than runaway costs, because it will allow any determined adversary, butterfingered DevOps, or innocent fuckup, to shut you down and deny your service by hitting that cap. When a business experiences a service or infrastructure outage, they count that in dollars of revenue. Your "budget cap" will cost you money because it "paused your project" and your customers all got burned in turn.

Moving toward real solutions, just spitballing, but I can envision throttling and capping of everything, every billable service, monitored by the cloud provider and ensured that your services don't spill over into unmanageable territory. If your spend could be throttled and capped by-the-minute, by-the-hour, daily, then there is a start for it. But really, any service that incurs costs to you should have reasonable rate-limiting, throttling, caps and alerts that can help you manage it. I think all that stuff is currently missing but I am not a cloud admin, obviously. Cloud services obviously have perverse incentives to open the floodgates and bill as much as possible for any possibly legitimate usage that doesn't exceed their aggregate capacities. It's like LLMs today that just burn tokens like there's no tomorrow, because someone [you, not Mexico] will eventually pay for it all.

What that's awesome? Yeah they definitely waited until the competitors did it first...

Edit: sadface

The hard caps work on projects created in AI studio

That doesn't mean you couldn't have a service which by default has no hard cap, and people have to opt into it. You could even put a user interface thing where people have to type a whole sentence perfectly matching and hit OK, like "I understand that enabling a hard billing cap will shut off services if it exceeds my monthly quota". Wrap it in as much service agreement contract, TOS language as is necessary.

Heck, have it do the equivalent of send people a DocuSign equivalent PDF to sign acknowledging the risk before enabling it. Would it still stop pissed off people? Probably not. Would it help with the risk of lawsuits, very possibly.

I think it's not generally 'much better' to use alerts. People - end users - are by now quite used to seeing things go down for a while. No biggie. But a infra oopsie can kill a company in ways a short outage won't.

And its of course not just people yolo'ing with AI. People were quite capable of causing such outages themselves just fine. Distributed, serverless systems are hard.

Yes, this is an important point although it has changed with A.I. Software is traditionally very high margin and so a $10k bill can be written off by the provider without any meaningful loss.

As a customer, the big number is scary and causes panic but for the provider… customers constantly fail to pay bills, providers are constantly writing off bills because it just isn’t worth the cost to chase, if a customer says “hey that usage was a mistake” it’s usually worth it to write it off to save the relationship. If you write off a big bill that wouldn’t have been paid anyway, the customer will perceive you as wonderful and benevolent and be loyal for life when they are ready to spend their money.

With tokens though the actual cost being incurred is much, much higher. If your service is just a wrapper around tokens, and a customer incurs $10k of usage that you paid OpenAI $5k for, it becomes much more difficult to write off.

Google Cloud is one of the few services that actually pursues unpaid bills even on their high margin services.

> you can negotiate with the billing department at comparative leisure.

I'm curious. How likely is the billing department to waive off a huge bill as bad debt because an inexperienced builder misconfigured their infra or was hacked?

I mean, I understand why _you_ want it that way, but that doesn’t mean that there can’t be hard budget caps for other people. You could even have both, with alerts at a level lower than the cap. I just want some kind of control over it.

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.

My Dutch bank offers such a thing on SEPA direct debits. If a company sends a debit request, it must stay within X euros per month or otherwise it's not automatically accepted and I'll have to explicitly allow/reject it.

Rejection will block the payment and the company will likely go after you to settle the dispute.

Clearest explanation ever.

Plus, nobody wants to be the fired PM who said "I spent our eng. hours to achieve -20% revenue".

Virtual cards don't solve anything. They just get you sent an invoice instead.

It works for some non-B2Bs.

I thought Microsoft used to give student's some free Azure credits - say $200. Rumor is, Microsoft was very good at pulling the plug the instant you went over that billing limit.

the answer is almost definitely "get on the leaderboard"

  > “what did these people do with all those tokens?”

Then add the option, but make it default to soft caps. Or bake the default into the tiers. If I sub with a $20 spending limit, I will probably be ruined by a $2000 bill. On the other hand, if a company subs with a $1000 limit, it can probably cover the occasional $10000.

At the very least, there should be an optional hard limit that is obviously indicated in the UI. When you're signing up where you set your "usage cap" warning, next to it should be an optional hard cap with big bold red letters "THIS WILL CUT YOU OFF THE MOMENT YOU GO ONE CENT OVER". So I can set e.g. a warning at $20 and a hard cap of $100.

The west has long since let people who get off on usury hold too much sway.

Probably should also have spend controls for gambling too but seems like we're a long ways off from good legislation there.

Agreed. Or at least, customers should only be liable for expenses they incur up to the hard caps they set.

If you don’t have a mechanism for enforcing hard caps, you don’t get to send customers a bill for unlimited amounts.

Everyone in this thread should be vibe coding legislation with lean 4. We can at least have utopia for a couple months.

we should make it illegal to be unhappy too, that way we can solve depression!

Anytime someone says “there sight to be a law that…” there almost always shouldn’t be.

Damn. Did you end up having to pay all of that?

Who asked for what, specifically?

I can’t think of anyone saying they would hate for AWS to support hard spending caps.

Can you explain your train of thought here?

It seems like you’re saying “hey, you asked for a product, so you deserve for it to have a user-hostile feature”

Like hey, you asked for trains? Well, then you have no right to complain about any aspect of a train.

That's going to be a hard sell to service providers who rely on people basically ignoring overspend.

So if you use more electricity next month the CEO of the electric company should be put in jail?

Why do people think new laws are needed to solve every last problem in the world?

Google implemented caps because their competitors offered them. Before that, customers could choose one of several competitors, rent the GPUs at a fixed rate, or buy the GPUs and install them on-premises.

At no point was any law needed to solve any of this.

Because many cloud services have incredibly complex or opaque pricing structures that make it difficult to impossible to determine how much something is going to cost you ahead of time, especially if it's usage-based a la network egress (and the usage statistics don't update frequently enough to make such circuit breakers possible to implement client-side).

Last time I checked it was impossible to get relevant info from API, for example for AWS.

Or if there was info that was after potentially horrible expensive operation.

That was blocking automated checking.

This is how most services work...

This guy only ended up with a ~$6k bill from his agent, not too shabby: https://news.ycombinator.com/item?id=48500012

Ideally because I'll pick a different vendor who protects me from such mistakes.

Because it’s unlikely they’ll actually be able to collect that million dollars from a lot of those customers. Rephrased: why would your vendor want to make it harder to accidentally give you a million dollars of services in exchange for debt of dubious quality?

Because I would go to the vendor who does.

I don't think Simon means you should hand off the spending to agents/LLM (which would also make me uneasy) but that if you're probing one for hosting/SaaS providers they should default to recommending ones with budget caps

This is about budget caps (“I don’t want to spend more than $100, cut me off once I spend that much”) not price caps (“no one is allowed to charge more than this price per token”).

A bunch of vendors provide this exact feature already, so I'm clearly not weird in wanting it.

About desire to have hard caps, to avoid runaway costs for example due to misconfiguration.

This may happen also without vibecoding.

Article seemed clear on that?

> What on earth is Simon whittering on about?

Guy seems to have lost his mind to AI psychosis and is just posting unmitigated obvious low-grade crap of late, which gets picked up here by his fan base.

whttering / wittering: To chatter, babble, or ramble on at length about trivial matters. About right.

bro this is HN, the "open market" where willing customers can choose whether or not to buy a service is the root of all evil here.