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

31 points by frontsideair 14 hours ago on lobsters | 11 comments

Worth noting that the AWS limits only work if you use the new signup "experience". This "experience" comes with a number of limitations, including, surprisingly, the inability to use multiple regions. If you want to remove the limitations, you have to enable "advanced features", which makes the spend limits go away

simonw | 6 hours ago

Ouch! I saw it was limited but I didn't realize how limited.

(Amusingly enough I only learned the feature existed when I ran my proof reading prompt against the first draft with Claude and it fact checked my claim that AWS didn't have the feature.)

k749gtnc9l3w | 5 hours ago

Why is it that surprising? They have throughput-optimised eventual consistency, with pretty significant global convergence delays (apparently at some point they did the same with warehouse inventory data…). So making limits across regions work is significantly harder.

I would not be surprised if decision flow was «we need hard limits for small users (or regulation forces the limits for everyone)» → «we need to define small users as single-region» → «how do we market the new account option»

Student | 5 hours ago

They could just allow limits per region

k749gtnc9l3w | 4 hours ago

I guess marketing didn't want to draw too much attention to them not being able to do things across regions?

k749gtnc9l3w | 10 hours ago

I think soft caps on AWS were not just insufficient, they also plain didn't work: many of the horror stories included the first notification when the bill was already way past the configured limit. I guess this became enough of a regulatory risk to introduce hard caps and eat the difference when their billing system cannot stay close to realtime.

But also, assuming LLMs can do standard well-known things, there is a solution with hard budget cap by default and inavoidably. Install stuff on VPSes with purely monthly pricing, do not give agent access to order more (so no hoster management UI access, just SSH access to VPS). There are clauses in ToS about things that get your VPS shut down, and in some cases your account terminated (like on AWS, of course), but what you pay is known in advance.

landon | an hour ago

I expect that most businesses and individuals would prefer errors to a surprise $10,000+ bill.

These businesses have no say in the matter, they are serfs. Why on earth would a business that stands to collect on these massive mistakes put up guardrails against them? That's leaving money on the table.

If somebody tripped and dropped $10k on your patio you'd probably give it back, you're also not a product designer for a cloud host, and this is why. Think like a ravenous greedy ghoul with an unending thirst for money and no integrity or decency, and you'll start to understand how these "experiences" are designed.

simonw | an hour ago

Plenty of these businesses do offer a hard budget limit now, so they clearly see value in not losing a potentially long-lasting commercial relationship with a customer over a one-time mistake.

It's also common for surprise overages to result in a customer support case that eventually ends up with the customer being refunded.

The fact that this isn't the default everywhere is wild to me. "Bankrupt my company in service of itself" seems like behavior nobody would opt in to if if was opt-in.

andersmurphy | 3 hours ago

Wonder if this makes VPS and dedicated servers more popular. You can scale so far on a single machine these days. Kinda makes things much simpler.

I guess the other option is just to write code by hand.

Return an error like a 429? Seems sensible enough. Alternatively software businesses may actually have to have workable unit economics. It will be interesting to see what happens as software if software becomes a commodity market. Maybe margins will shrink.