Nobody is thinking about the stock owners, I see

> Of course it doesn't have to be perfect, but even approximating perfection doesn't look much different.

It's pretty easy to get right, if the provider allows you to go (slightly) negative before cutting you off.

> Also, can you imagine the kind of downtimes and complaints that would inevitably originate from a fully synchronous billing architecture?

Doesn't need to fully synchronous.

the planning-your-day-around-the-window thing is real and underrated as a cost. the limits don't just hit you at the moment you hit them, they change how you work for the entire day around them. we're building something called Traeco that tells you what's actually eating your limit per step so you can at least see what's burning fast vs what's fine — happy to share early access if you want to try it.

No you big dummy, that is especially when you want to limit your liability, lol.

Because these days it will be all worthless bot traffic.

Prepaid/paid limits with shutoff is appropriate for this though.

If you have per key limits, this is not possible, and even in a wild situation you should b able to expect that your firebase key will not use 50k.

Let me choose. This common point seems more like a rationalization for the default behavior of hyperscalers. AWS isn't avoiding prepaid due to concern about my site's virality, just that prepaid = less money.

You can also have both, a cap and one or more billing alert levels below it. Some providers do this (e.g. IIRC Backblaze B2).