> Generally speaking, it's much better to use alerts instead of hard limit.

Probably for companies and opportunistic individuals with a high risk tolerance. As for me, just give me hard budget caps. It shouldn't be a choice between supporting one of the approaches, when you could let each client pick what they want.

Want an alert? Configure one.

Want a hard limit? Configure one.

(just make the configuration easy and visible)

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.

My mobile phone contract reduces my speed a lot when the hard limit it reached. I still get some connectivity. What Never happens is that I have to pay extra. If a company can’t give me hard limits on the cost I have to pay, I will not do business with them. Notifications when close to the limit are fine, but when I don’t react to them I want things to crash rather than having to pay indefinite amounts.

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.

I can understand how that causes issues, but surely it also shows that alerts don't work either? These companies were presumably missing/ignoring alerts with scary messaging that they're about to get shut off, and would also miss/ignore alerts with scary messaging that their bill is getting too high.

I'm of course lacking specifics, but it sounds like this take-away might not be the best solution?

A better approach to that scenario might be to split into base load and peak load infra, similar to how we do it with the power grid.

Base load could be an actual metal server that you pay x amount of money for and is fully yours, with peak load being handled by autoscaling dynamic stuff.

Both things being on a fixed budget, if that budget would run out, the service would not degrade as in "grind to a halt" but as in "slows down", which is probably not a downtime as part of a communicated SLA.

My point being that cloud and on-demand is useful, but a hybrid approach might in many cases make more sense. Though of course YMMV. I do not know what the requirements of your product are.

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.

While you have a valid argument for why a customer would prefer the alerts...

It should be the choice of the customer.

Imposing one option: only hard budget cap or only alerts is the wrong design decision.

Why is this mutually exclusive. Is this even an argument? Some people complain becuase the hard cap kicked in. Others want hard caps. There is absolutely nothing stopping both from being implemented and offered as a choice. But we have spent decades being told "we know what's better for you". As an engineer, I think we need to come back down from the stratosphere.

> 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 don't see how it can be a problem if a service has mandatory settings for soft and hard limits. Those who don't want to disrupt services just unset the hard limit. Those who complain after the fact can be pointed at their explicit choices and have them explained to them - the service provider can hardly be held liable for a customer choosing the wrong value when it's easy to set the right value.

This is not rocket salad to implement correctly.

> Generally speaking, it's much better to use alerts instead of hard limit.

You can't extrapolate your own experience and generalize like that. There is a huge number of people who explicitly want hard caps, period. AWS giving in and finally offering this option after 20 years of people begging them to do that is a sign of that.

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.

Had a similar experience with OpenRouter, put 10$, goes -50$, I just stopped using it. To their credit support agreed to reset my balance (AI refusal at first, then re-contacted me months later to agree). I'm being more careful now but I shouldn't have to be IMHO.

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.

Mistaken view.

I was a member of AWS customer advisory board for years. Two dozen of largest enterprises and unicorns and so on. Nobody wanted the billing department "inline" of systems controls.

AWS provides all the controls you need to flip the switch yourself, and provides the CDK / TF / etc. patterns for it. Plenty GitHub projects to host your own light switch service.

Don't relinquish the switch.

>It’s such a basic thing, not having it has to be deliberate to make you accidentally spend more than you’d like.

This is unlikely. The big cloud providers routinely cancel bills based on accidental usage. The real explanation is just that it's technically difficult to calculate all usage in real time and shut down systems immediately as soon as a certain cap is reached.

The only way to deal with those is to blackhole the traffic at BGP level.

The fancy alternative is to anycast that network and do distributed filtering so that the flood is manageable.

The first can be done by your ISP but it does lead to the temporary loss of traffic via that IP.

The second one is what DDoS mitigation services do and AWS has a basic one built in ( AWS Shield ) and several additional services you can get.

Clearest explanation ever.

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

>One solution is banking apps that let you create extra cards and assigning hard limits to spending. Wise & Revolut apps can do that.

That's not a solution because not paying your debts doesn't make your debts go away.

It’s obviously all intentional and should be reason enough to not use a platform.

You can still rack up a bill even if you can't pay for it. That solution just means the card declines when the monthly bill needs to be paid, not that you don't owe money.

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.

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.

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

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

> We could call it a „Personal Computer“ ...

And you could complement people's personal computers with "dedicated servers" for companies (and even individuals).

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

It works for some non-B2Bs.

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.

Blocking the payment doesn't solve the problem, you may avoid your bank account being instantly emptied but you're still on the hook for the money.

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.

Thats great but no one does anything in europe

the answer is almost definitely "get on the leaderboard"

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

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.

Only sensible way is to have separate and put only amount of money your are willing to spend.

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

You could set the hard cap to a billion dollars. Everyone has a different hard cap — every company and person has an amount they simply couldn’t pay. This is just asking you to decide what that is and write it down.

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.

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

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.

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.

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?

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.

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