--- title: We’re going to need default hard budget caps on pretty... description: Simon Willison argues that pay-per-usage services and APIs need default hard budget caps that actually cut off service once a spending limit is reached, rather... canonical: https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: We’re going to need default hard budget caps on pretty much everything | daily.dev og:description: Simon Willison argues that pay-per-usage services and APIs need default hard budget caps that actually cut off service once a spending limit is reached, rather... og:url: https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa og:image: https://api.daily.dev/og/posts/wPtapK6pA.png og:image:alt: We’re going to need default hard budget caps on pretty much everything og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # We’re going to need default hard budget caps on pretty much everything **[Simon Willison](https://daily.dev/sources/simonwillison)** · 3 min read · 0 upvotes · 0 comments ## Summary Simon Willison argues that pay-per-usage services and APIs need default hard budget caps that actually cut off service once a spending limit is reached, rather than soft caps that merely send a warning email. He notes coding and personal agents make it easy to spin up applications that can rack up large bills unexpectedly. He points out that AWS quietly launched spend limits in mid-September 2026 as part of its new builder experience (currently limited rollout), which pauses a project once its monthly spend limit is reached, and that Google Cloud launched a similar Spend Caps feature in July 2026. He hopes hard caps become opt-out defaults and that AI agents start steering users toward providers offering them. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does AWS have a hard spending limit feature that stops services once a budget cap is hit? Yes. AWS launched a new builder experience on September 16, 2026 that lets you set a monthly spend limit for a project; once usage reaches that limit, the project is paused for the rest of the month rather than just sending a warning email. It is currently being rolled out to a limited number of customers, not yet generally available to all existing accounts. _daily.dev surfaces updates like this for developers tracking AWS cost-control features before deploying agent-driven apps._ ### What is Google Cloud Spend Caps and when did it launch? Spend Caps is a Google Cloud budgeting feature launched in July 2026 that lets you set a monthly financial cap on specific services within a project, automatically restricting usage once the cap is reached rather than merely alerting you. It mirrors the hard-cap approach AWS later introduced with its new builder experience in September 2026. _Developers comparing cloud cost controls across AWS and Google Cloud can follow these changes on daily.dev._ ### Why do AI coding agents increase the risk of runaway cloud bills? Coding agents and personal agents lower the friction of spinning up applications that call paid APIs or hosted services, making it easier for a rogue or misconfigured service to rack up hundreds or thousands of dollars in usage overnight before anyone notices, since most cloud platforms historically only offered soft spending alerts rather than hard cutoffs. _Anyone building with coding agents can track emerging safeguards against runaway costs via daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 464 comments across lobsters, hackernews (as of 2026-10-04). **TL;DR:** Discussion largely agrees hard spending caps are overdue and technically tricky to implement well, but splits sharply on whether hard cutoffs or alert-based soft limits are the right default, especially for storage and business-critical workloads. **Sentiment:** 20% positive · 45% mixed · 35% skeptical **The case for** - Hard caps would protect hobbyists and small businesses from bill shock or bankruptcy from runaway/bugged/attacked spend. - A simple opt-in checkbox (e.g., 'no spending limit' for enterprises/hospitals) could satisfy both camps. - Alert-only systems suffer from alert fatigue and are often ignored until it's too late. - Even a loose cap (e.g., 10x normal spend) is better than no cap at all. - Today's cost-conscious hobbyists become tomorrow's enterprise decision-makers, so good defaults matter long-term. **The pushback** - Hard caps risk shutting down business-critical services at the worst possible time over a budget technicality. - Cloud billing is technically asynchronous and granular, making real-time hard enforcement very difficult to implement correctly. - Enterprises with thousands of budgets find simple alerts or a single global cap largely useless or actually harmful. - Deleting or locking persistent storage (S3, databases) when a cap is hit is far riskier than pausing compute, and several commenters felt this weakened the overall argument. - Most paying businesses reportedly prefer a surprise bill over an outage, since outages have reputational and revenue costs that dwarf overage costs. **By community** - lobsters (mixed): No comments were provided, so sentiment can't be assessed beyond the discussion existing. - hackernews (heated): Extensive back-and-forth between those who want opt-in hard caps as an obvious consumer protection and those who argue hard caps are technically fraught and dangerous for business-critical infrastructure, especially around storage deletion. **Hottest debate:** Whether hard budget caps should pause/shut off services by default, versus relying on alerts, given that an unexpected outage can be more damaging to a business than an unexpected bill. **Open questions** - How can hard caps be implemented for persistent storage (S3, databases) without risking data loss or unacceptable lock-in periods? - Can AI-driven cost estimation ever get precise enough to warn users before an operation runs rather than only after? - Should cloud providers offer per-service or per-project granularity for caps rather than a single global account limit? **Highlights** > 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. > — [ButlerianJihad on hackernews](https://news.ycombinator.com/item?id=49951247) > 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. > — [motionlessveloc on hackernews · 14 comments](https://news.ycombinator.com/item?id=49950196) > 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. > — [Anon1096 on hackernews · 11 comments](https://news.ycombinator.com/item?id=49949984) > A hospital needs to be able to handle a full cloud outage. So I'd be worried if they're near the top of the list of how much they'd be willing to pay here. > — [Dylan16807 on hackernews](https://news.ycombinator.com/item?id=49950648) > Simple: when data is added to S3, immediately bill the full cost of storing that data until the end of the month (or fail the upload request if there's not enough quota left). If the data is deleted before the end of the month, refund the remaining storage time. To prevent cases where users can upload an excessive amount of data on March 31 that they then can't afford the April bill for, AWS should also maintain a "next month's balance" limit that gets handled in the same way. It would take a bit more work to correctly handle things like ephemeral data and tiered storage classes, but it's not insurmountable. You could apply the same kind of billing to most other long-lived resources, including VMs that run business-critical services. > — [csande17 on hackernews](https://news.ycombinator.com/item?id=49951813) **Source threads** - [lobsters](https://lobste.rs/s/xkwswd/we_re_going_need_default_hard_budget_caps) · 17 points · 2 comments - [hackernews](https://news.ycombinator.com/item?id=49949235) · 395 points · 462 comments ## Similar posts on daily.dev - [Introducing Firebase spend caps](https://daily.dev/posts/introducing-firebase-spend-caps-iygfnrfcv) · Firebase · 0 upvotes · 0 comments - [Tokenminimizing: firms cap staff AI use as bills bite](https://daily.dev/posts/tokenminimizing-firms-cap-staff-ai-use-as-bills-bite-lykjugt2t) · The Next Web · 1 upvotes · 0 comments - [GitLab 18.11: Budget guardrails for GitLab Credits](https://daily.dev/posts/gitlab-18-11-budget-guardrails-for-gitlab-credits-dtn7kgt6u) · GitLab · 0 upvotes · 0 comments --- Tags: [#aws](https://daily.dev/tags/aws), [#ai-agents](https://daily.dev/tags/ai-agents), [#gcp](https://daily.dev/tags/gcp) [View this post on daily.dev](https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"We’re going to need default hard budget caps on pretty much everything","url":"https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa"},"datePublished":"2026-10-03T23:34:49.250Z","dateModified":"2026-10-04T14:33:34.342Z","description":"Simon Willison argues that pay-per-usage services and APIs need default hard budget caps that actually cut off service once a spending limit is reached, rather...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Simon Willison","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Simon Willison","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/cf12b897300740218b35f49a6309ec5b","url":"https://daily.dev/sources/simonwillison"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"aws,ai-agents,gcp","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Simon Willison","item":"https://daily.dev/sources/simonwillison"},{"@type":"ListItem","position":3,"name":"We’re going to need default hard budget caps on pretty much everything"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/we-re-going-to-need-default-hard-budget-caps-on-pretty-much-everything-wptapk6pa#faq","mainEntity":[{"@type":"Question","name":"Does AWS have a hard spending limit feature that stops services once a budget cap is hit?","acceptedAnswer":{"@type":"Answer","text":"Yes. AWS launched a new builder experience on September 16, 2026 that lets you set a monthly spend limit for a project; once usage reaches that limit, the project is paused for the rest of the month rather than just sending a warning email. It is currently being rolled out to a limited number of customers, not yet generally available to all existing accounts. daily.dev surfaces updates like this for developers tracking AWS cost-control features before deploying agent-driven apps."}},{"@type":"Question","name":"What is Google Cloud Spend Caps and when did it launch?","acceptedAnswer":{"@type":"Answer","text":"Spend Caps is a Google Cloud budgeting feature launched in July 2026 that lets you set a monthly financial cap on specific services within a project, automatically restricting usage once the cap is reached rather than merely alerting you. It mirrors the hard-cap approach AWS later introduced with its new builder experience in September 2026. Developers comparing cloud cost controls across AWS and Google Cloud can follow these changes on daily.dev."}},{"@type":"Question","name":"Why do AI coding agents increase the risk of runaway cloud bills?","acceptedAnswer":{"@type":"Answer","text":"Coding agents and personal agents lower the friction of spinning up applications that call paid APIs or hosted services, making it easier for a rogue or misconfigured service to rack up hundreds or thousands of dollars in usage overnight before anyone notices, since most cloud platforms historically only offered soft spending alerts rather than hard cutoffs. Anyone building with coding agents can track emerging safeguards against runaway costs via daily.dev."}}]} ```