Denial of wallet: what a hard budget cap actually stops

Simon Willison wrote on 2026-10-03 that we need default hard budget caps on pretty much everything. I agree.

Firebase has spend caps for some services. But its docs say they can take several minutes to kick in. Whatever gets spent in that time is still your bill.

So you set a limit, but you’re still not fully in control. That’s terrifying.

What denial of wallet means

Denial of wallet is when someone runs up your usage on purpose, so that the bill breaks before the service does. OWASP lists it under unbounded consumption for LLM applications: attackers “exploit the cost-per-use model of cloud-based AI services.” A retry loop or a misconfigured deployment can run up the same bill without any attacker.

OWASP’s mitigations include rate limits, quotas and timeouts. They slow the spending down. A hard cap is what stops it, at a number you chose.

What I want from a cap

I think financial control should belong to the user. Let me set a real ceiling. Stop spending when I reach it. Let me choose automatic or manual top-ups.

When I see “spend cap”, I expect a hard limit. Firebase’s docs explicitly say otherwise: its spend caps “are not ‘hard caps’”, and anything spent during the delay is billed as normal. If a provider calls it a cap and enforces it late, I think the provider should cover the difference.

Agents make this even more important. They can help you deploy an app without explaining everything that can generate a bill. They can miss details and make mistakes too. Sometimes they act without asking, like the tunnel my coding agent opened to get files into Google Slides.

Simon goes a step further: an agent that recommends a cloud provider should prefer ones with hard caps and warn inexperienced builders away from the rest.

What providers actually stop

Checked on 2026-10-21. These controls change often, so read the linked docs before relying on one.

Control	What happens at the limit	What it doesn’t cover
Firebase and Google Cloud spend caps	New usage of the capped service pauses for the rest of the month, after a delay that can be several minutes	Firebase: AI Logic, App Hosting, Cloud Functions and Extensions only, in Preview on the Blaze plan. Google Cloud: Gemini API, Agent Platform, Cloud Run and Cloud Run functions. Usage during the delay is billed, and fixed compute and storage keep billing
AWS project spend limits	A project’s resources stop when its pre-tax monthly cost reaches the limit	Limited rollout, not every account. At most 10 projects, and the limit can’t go below $20 or AWS’s own estimate, whichever is higher. Data in a project left paused for 90 days is deleted
Vercel Spend Management	Production deployments pause, if you turn that option on. A budget on its own only notifies	Pro and eligible Enterprise teams. Usage is checked every few minutes, so charges can pass the threshold. AI Gateway, v0 and stored resources can keep billing
Supabase Spend Cap	Covered usage past the plan quota is blocked, and the docs say it isn’t charged	Pro plan only. It follows the plan quota, not a dollar amount you pick. Compute, branching, read replicas and add-ons are excluded
Netlify credit-based plans	When credits run out, projects, deploys, requests and form submissions pause	Auto recharge keeps buying credits until you turn it off. Legacy plans work differently
OpenAI API spend limits	Requests get a 429 error once an organization or project limit is reached, if you choose enforcement instead of alerts	Enforcement isn’t instant, and OpenAI says spend can slightly exceed the limit
Claude API spend limits	The Start, Build and Scale tiers each have a monthly cap that pauses API usage, and you can set lower limits per organization or workspace	The Custom tier has no monthly cap; limits are arranged with the account team. The default workspace can’t have its own limit. Claude subscriptions and billing through cloud providers are separate
Cloudflare Workers Free	Worker requests past 100,000 a day get an error until midnight UTC, or skip the Worker if the route fails open	Other Cloudflare products have their own limits. Workers pricing lists a CPU limit per request for paid Workers, not an account-wide dollar cap

Several of these really do stop spending. Each one stops a defined set of things, though, and the right-hand column is where the bill can still grow.

What I chose for this site

This site runs on a plan with no paid overage, and the parts that agents or the public can trigger have hard daily limits and an off switch. Choosing that means a flood shows up as errors and unavailability rather than a bill.

That lowers my cost exposure. It doesn’t remove risk: the site can still be made unavailable or abused, and the caps don’t cover everything.

If you’re adding an agent to a business workflow, give everything it can trigger a hard limit and a way to switch it off.

Before you deploy

Check what your limit actually covers, what keeps billing after a shutdown, and how the provider handled past incidents. In more detail:

1. Scope. Write down the account, plan, project and services the limit applies to, and whether it’s in preview, in a limited rollout or switched on at all.
2. Every billable line. List what can bill: seats, requests, compute, database reads and writes, storage, egress, logs, backups, AI tokens and third-party APIs. Match each one to its own control. A paused frontend doesn’t stop an API key used somewhere else.
3. The action at the limit. An email, a webhook, a paused project and a rejected request are different things. A budget number on its own proves little.
4. The delay. Find out how long enforcement takes and what keeps running meanwhile. Set the cap below what you can afford to lose: a lower threshold buys headroom, not a guarantee.
5. Top-ups and resets. Check auto recharge, who can raise or remove the limit, and whether service comes back on its own next month.
6. What users see. Decide what happens at the limit: an error page, a queued order, a retry. Try it in a cheap test environment before real traffic finds it.
7. What keeps billing after a shutdown. Storage, fixed compute and subscriptions often continue. Check when paused data gets deleted: AWS deletes it after a project sits paused for 90 days.
8. Past incidents. Read how the provider handled earlier surprise bills in its own incident reports and refund terms, not in a thread about them.
9. If an agent deployed it. Ask for a list of everything it created and what each item bills for, then check that list against the provider’s console.

A shorter version of this first appeared on LinkedIn on 2026-10-04.