Simon Willison argues that default hard budget caps — hard, error-returning limits with an explicit opt-out rather than warning emails — must become the standard control on pay-by-usage services and agent platforms, citing AWS's September project spend limits and Google Cloud's July Spend Caps as the start of a trend; platform and harness adoption of default-on caps confirms it, quiet fade refutes it.

state: watchingheat: highuncertainty: mediumconvergesscott: highagent-budget-caps runaway-cost agent-harness-safetySimon Willison

Surfaced 2026-10-05T14:31:59Z — "We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa — The initial wave crested and flattened — the velocity spikes were the launch surge, and current rate is ~0 pts/h at the 25th percentile with no new evidence beyond the original post and its single HN thread. Discussion added two substantive counterarguments (vendor incentive misalignment; practitioner reports of hard caps severing organically-growing services, triggering support load and legal threats) that temper but don't overturn the trend thesis; the case now waits on the months-scale confirmation condition of actual default-on cap adoption.

What is this?

On 3 Oct 2026 Simon Willison published 'We're going to need default hard budget caps on pretty much everything', arguing that pay-by-usage services and APIs should ship hard $X/month cutoffs (error-returning, with an explicit opt-out) as the default instead of soft warning-email budgets, and suggesting agents should bias toward recommending capped providers. He cites AWS's September 2026 project-level spend limits (which pause a project at the limit, in limited release) and Google Cloud's July 2026 Spend Caps (per-service monthly caps) as the start of a trend; the post drew a large Hacker News thread (~600 pts / ~300 comments per the case, 552 in the first day per one snippet). Follow-up coverage adds two wrinkles the original didn't stress: enforcement on several providers is lagged rather than instantaneous (Google Cloud bills overages normally, OpenAI says enforcement is 'not instantaneous', Vercel polls every few minutes), and a cap doubles as a self-inflicted outage an attacker or retry storm can trigger — while no major platform has yet shipped caps default-on, keeping Willison's 'becomes standard' claim open.

Why it matters to Scott

Willison is publicly arguing the principle Scott's own wikis already hold — hard deterministic caps over soft warnings is Manners-vs-Physics and can't-beats-shouldn't applied to spend, with Autonomy Budget as the harness-side version — making this a dated-receipts convergence from one of the most influential voices in exactly Scott's territory, not a repetition: Willison adds the default-on/opt-out provider-policy layer and AWS/GCP trend evidence Scott's canon doesn't carry. The strongest HN objection (hard caps sever production at the worst moment) is answered by refinements Scott already holds — pause-and-escalate caps and budget-exhaustion fallback routing rather than a kill switch — giving him a differentiated entry into the debate, while the open condition (no platform yet default-on) is tracked by sibling radar episodes, so AWS/GCP adoption moves would directly update it.

ip:concept.autonomy-budgetip:concept.manners-vs-physicsip:concept.architectural-containmentdev:concept.cost-tiered-llm-routingradar:aws-project-spend-limitsradar:openai-spend-limit-enforce-flagradar:tokenops-whole-run-budgetradar:concept.usage-limitsradar:concept.inference-economics

queries asked of Scott's wikis

agent harness runaway cost guardrails spend ceiling
coding agent max iterations loop safety limits
LLM API cost control budget kill switch
agent platform pay-per-use billing patterns
harness design defense-in-depth fail-safe defaults
tool call loop retry storm protection

Measured heat

now 0 pts/hpeak 94 pts/hcomments 0/hpeers p14momentum: steady2 platformsage 218h

points/hour across evidence · reading as of 2026-10-12 02:59:37.977291+11:00 · deterministic, not a model opinion

How the heat travelled

10-02 14:00	⭐ origin echo-reconstructed	"We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa Simon Willison on blog (echo) · attributed from hn.story.49949235	—
10-04 00:20	first on hacker news · published · +34.3h	We're going to need default hard budget caps on pretty much everything elffjs	—
10-04 00:20	amplified on hacker news 👑	hn.story.49949235 elffjs	peak 650 · 313 comments · 100% of case engagement
10-04 01:20	our radar first saw it · +35.4h	discovery anchor: hn.story.49949235	—
10-05 05:30	reached heat=high · +63.5h · via queue+ledger	—	—

pace: p91 vs 1188 stories at the 168h mark (now 218h old) — ahead of siri-private-model-substitution (1.0x), behind crofai-model-substitution-shutdown (1.0x)

Evidence (2) — ⭐ canonical anchor

source	object	author	score	comments
🟧 hn	We're going to need default hard budget caps on pretty much everything Retrieved article excerpt Open article · Retrieved 2026-10-04T01:24:32.165435+00:00 # [Simon Willison’s Weblog](https://simonwillison.net/) [Subscribe](https://simonwillison.net/about/#subscribe) Sponsored by: Deepgram — Flux TTS remembers the conversation, so your agent sounds right on reply 20. [Hear the demo](https://fandf.co/4dat4R0) ## We’re going to need default hard budget caps on pretty much everything 3rd October 2026 Here’s a product feature which the world is going to need a whole lot more of over the coming months and years: default hard budget caps. I’m talking about the feature of pay-by-usage services and APIs that lets you say “after $X/month, cut this thing off and return errors”. These need to be hard limits. Soft caps, “after $X/month, send me a warning email”, will not cut it. Coding agents, and personal agents (coding agents wrapped in a less threatening UI), greatly reduce the friction of spinning up code that can do useful things. Sometimes those things cost money—calls to paid APIs, or hosted web applications, or systems that can bill for additional storage and compute. Nobody wants to wake up to an email sent at midnight warning about a budget limit and find that, while they slept, their rogue service had consumed several hundred (or several thousand) more dollars of usage. An argument against this is that businesses don’t want their hosted applications to start throwing errors because some budget was exceeded. I expect that most businesses and individuals would prefer errors to a surprise $10,000+ bill. I think hard budget caps need to be the default. If someone wants to live dangerously they should be able to do that, but it needs to be on an opt-in basis. Have a nice, clear checkbox somewhere prominent: > Remove the budget cap. My application will not be shut down if I exceed the configured budget limit, and I will be responsible for subsequent charges. The service I most want to see this from is AWS. I’ve heard plenty of stories from people who refuse to use AWS for personal projects out of (justified) fear that a runaway service might bankrupt them. I’ve also heard stories from people who didn’t anticipate this and ended up seriously burned. ... and it turns out AWS finally launched spending limits a few weeks ago! From their announcement [New AWS experience helps builders get started and ship faster](https://aws.amazon.com/about-aws/whats-new/2026/09/New-AWS-Builder-Experience/) on 16th September: > When you’re ready to upgrade to a paid plan, you can set a monthly spend limit for your project based on your usage patterns so that you stay within your budget. If a project’s usage reaches its spend limit, your project is paused for that month. See also [Create a spend limit in AWS Settings](https://docs.aws.amazon.com/accounts/latest/reference/create-spend-limit.html), though that page warns that “We’re currently releasing our new experience to a limited number of customers.” Here’s hoping that hits general availability for existing accounts soon. Google Cloud [launched a similar feature](https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets) in July, called Spend Caps, which lets you “set a monthly financial cap on specific services within a project”. Looks like this is becoming a trend! In an ideal world, our agents could help with this. It would be great if agents started biasing towards recommending providers with hard budget caps, and warning new and inexperienced builders against deploying applications using uncapped services that might get them into trouble. Posted [3rd October 2026](https://simonwillison.net/2026/Oct/3/) at 11:34 pm · Follow me on [Mastodon](https://fedi.simonwillison.net/@simon), [Bluesky](https://bsky.app/profile/simonwillison.net), [Twitter](https://twitter.com/simonw) or [subscribe to my newsletter](https://simonwillison.net/about/#subscribe) ## More recent articles - [OpenAI DevDay 2026 live blog](https://simonwillison.net/2026/Sep/29/openai-devday-2026-live-blog/) - 29th September 2026 - [2026 in LLMs (so far)](https://simonwillison.net/2026/Sep/27/2026-in-llms-so-far/) - 27th September 2026 This is We’re going to need default hard budget caps on pretty much everything by Simon Willison, posted on [3rd October 2026](https://simonwillison.net/2026/Oct/3/). [amazon-web-services 83](https://simonwillison.net/tags/amazon-web-services/) [ai 2,259](https://simonwillison.net/tags/ai/) [coding-agents 254](https://simonwillison.net/tags/coding-agents/) Previous: [OpenAI DevDay 2026 live blog](https://simonwillison.net/2026/Sep/29/openai-devday-2026-live-blog/) ### Monthly briefing Sponsor me for $10/month and get a curated email digest of the month's most important LLM developments. Pay me to send you less! [Sponsor & subscribe](https://github.com/sponsors/simonw/) - [Disclosures](https://simonwillison.net/about/#disclosures) - [Colophon](https://simonwillison.net/about/#about-site) - © - [2002](https://simonwillison.net/2002/) - [2003](https://simonwillison.net/2003/) - [2004](https://simonwillison.net/2004/) - [2005](https://simonwillison.net/2005/) - [2006](https://simonwillison.net/2006/) - [2007](https://simonwillison.net/2007/) - [2008](https://simonwillison.net/2008/) - [2009](https://simonwillison.net/2009/) - [2010](https://simonwillison.net/2010/) - [2011](https://simonwillison.net/2011/) - [2012](https://simonwillison.net/2012/) - [2013](https://simonwillison.net/2013/) - [2014](https://simonwillison.net/2014/) - [2015](https://simonwillison.net/2015/) - [2016](https://simonwillison.net/2016/) - [2017](https://simonwillison.net/2017/) - [2018](https://simonwillison.net/2018/) - [2019](https://simonwillison.net/2019/) - [2020](https://simonwillison.net/2020/) - [2021](https://simonwillison.net/2021/) - [2022](https://simonwillison.net/2022/) - [2023](https://simonwillison.net/2023/) - [2024](https://simonwillison.net/2024/) - [2025](https://simonwillison.net/2025/) - [2026](https://simonwillison.net/2026/)	elffjs	650	313
🟧 echo.blog ⭐	"We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa	Simon Willison	—	—

source

object

author

score

comments

🟧 hn

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

Retrieved article excerpt

Open article · Retrieved 2026-10-04T01:24:32.165435+00:00

# [Simon Willison’s Weblog](https://simonwillison.net/)

[Subscribe](https://simonwillison.net/about/#subscribe)

**Sponsored by:** Deepgram — Flux TTS remembers the conversation, so your agent sounds right on reply 20. [Hear the demo](https://fandf.co/4dat4R0)

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

3rd October 2026

Here’s a product feature which the world is going to need a whole lot more of over the coming months and years: **default hard budget caps**. I’m talking about the feature of pay-by-usage services and APIs that lets you say “after $X/month, cut this thing off and return errors”. These need to be **hard** limits. Soft caps, “after $X/month, send me a warning email”, will not cut it.

Coding agents, and personal agents (coding agents wrapped in a less threatening UI), greatly reduce the friction of spinning up code that can do useful things. Sometimes those things cost money—calls to paid APIs, or hosted web applications, or systems that can bill for additional storage and compute.

Nobody wants to wake up to an email sent at midnight warning about a budget limit and find that, while they slept, their rogue service had consumed several hundred (or several thousand) more dollars of usage.

An argument against this is that businesses don’t want their hosted applications to start throwing errors because some budget was exceeded. I expect that most businesses and individuals would prefer errors to a surprise $10,000+ bill.

I think hard budget caps need to be the default. If someone wants to live dangerously they should be able to do that, but it needs to be on an opt-in basis. Have a nice, clear checkbox somewhere prominent:

> Remove the budget cap. My application will not be shut down if I exceed the configured budget limit, and I will be responsible for subsequent charges.

The service I most want to see this from is AWS. I’ve heard plenty of stories from people who refuse to use AWS for personal projects out of (justified) fear that a runaway service might bankrupt them. I’ve also heard stories from people who *didn’t* anticipate this and ended up seriously burned.

... and it turns out AWS finally launched spending limits a few weeks ago! From their announcement [New AWS experience helps builders get started and ship faster](https://aws.amazon.com/about-aws/whats-new/2026/09/New-AWS-Builder-Experience/) on 16th September:

> When you’re ready to upgrade to a paid plan, you can set a monthly spend limit for your project based on your usage patterns so that you stay within your budget. If a project’s usage reaches its spend limit, your project is paused for that month.

See also [Create a spend limit in AWS Settings](https://docs.aws.amazon.com/accounts/latest/reference/create-spend-limit.html), though that page warns that “We’re currently releasing our new experience to a limited number of customers.” Here’s hoping that hits general availability for existing accounts soon.

Google Cloud [launched a similar feature](https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets) in July, called Spend Caps, which lets you “set a monthly financial cap on specific services within a project”. Looks like this is becoming a trend!

In an ideal world, our agents could help with this. It would be great if agents started biasing towards recommending providers with hard budget caps, and warning new and inexperienced builders against deploying applications using uncapped services that might get them into trouble.

Posted [3rd October 2026](https://simonwillison.net/2026/Oct/3/) at 11:34 pm · Follow me on [Mastodon](https://fedi.simonwillison.net/@simon), [Bluesky](https://bsky.app/profile/simonwillison.net), [Twitter](https://twitter.com/simonw) or [subscribe to my newsletter](https://simonwillison.net/about/#subscribe)

## More recent articles

- [OpenAI DevDay 2026 live blog](https://simonwillison.net/2026/Sep/29/openai-devday-2026-live-blog/) - 29th September 2026
- [2026 in LLMs (so far)](https://simonwillison.net/2026/Sep/27/2026-in-llms-so-far/) - 27th September 2026

This is **We’re going to need default hard budget caps on pretty much everything** by Simon Willison, posted on [3rd October 2026](https://simonwillison.net/2026/Oct/3/).

[amazon-web-services
83](https://simonwillison.net/tags/amazon-web-services/)
[ai
2,259](https://simonwillison.net/tags/ai/)
[coding-agents
254](https://simonwillison.net/tags/coding-agents/)

**Previous:** [OpenAI DevDay 2026 live blog](https://simonwillison.net/2026/Sep/29/openai-devday-2026-live-blog/)

### Monthly briefing

Sponsor me for **$10/month** and get a curated email digest of the month's most important LLM developments.

Pay me to send you less!

[Sponsor & subscribe](https://github.com/sponsors/simonw/)

- [Disclosures](https://simonwillison.net/about/#disclosures)
- [Colophon](https://simonwillison.net/about/#about-site)
- ©
- [2002](https://simonwillison.net/2002/)
- [2003](https://simonwillison.net/2003/)
- [2004](https://simonwillison.net/2004/)
- [2005](https://simonwillison.net/2005/)
- [2006](https://simonwillison.net/2006/)
- [2007](https://simonwillison.net/2007/)
- [2008](https://simonwillison.net/2008/)
- [2009](https://simonwillison.net/2009/)
- [2010](https://simonwillison.net/2010/)
- [2011](https://simonwillison.net/2011/)
- [2012](https://simonwillison.net/2012/)
- [2013](https://simonwillison.net/2013/)
- [2014](https://simonwillison.net/2014/)
- [2015](https://simonwillison.net/2015/)
- [2016](https://simonwillison.net/2016/)
- [2017](https://simonwillison.net/2017/)
- [2018](https://simonwillison.net/2018/)
- [2019](https://simonwillison.net/2019/)
- [2020](https://simonwillison.net/2020/)
- [2021](https://simonwillison.net/2021/)
- [2022](https://simonwillison.net/2022/)
- [2023](https://simonwillison.net/2023/)
- [2024](https://simonwillison.net/2024/)
- [2025](https://simonwillison.net/2025/)
- [2026](https://simonwillison.net/2026/)

elffjs

650

313

🟧 echo.blog ⭐

"We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa

Simon Willison

—

Interpretation history

2026-10-05T05:37:11Z
grounded: converges/high — Willison is publicly arguing the principle Scott's own wikis already hold — hard deterministic caps over soft warnings is Manners-vs-Physics and can't-beats-sho
2026-10-05T05:30:01Z
magnitude valve eligible (multi-platform, top-decile engagement) and never alerted; deterministic escalation to deliver
2026-10-04T02:25:16Z
case created — A crystallizing thesis with concrete antecedents (AWS spend limits, GCP Spend Caps) and front-page traction that spans the individual cost-control episodes already open without reducing to any of them.

Decision trace

10-06 01:31push"We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa — The initial wave crested and flattened — t
10-05 16:37repriceThe initial wave crested and flattened — the velocity spikes were the launch surge, and current rate is ~0 pts/h at the 25th percentile with no new evidence beyond the original post and its single HN
10-05 16:37groundWillison is publicly arguing the principle Scott's own wikis already hold — hard deterministic caps over soft warnings is Manners-vs-Physics and can't-beats-shouldn't applied to spend,
10-05 16:30alert_held"We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa — The initial wave crested and flattened — t
10-05 16:30alert_route"We're going to need default hard budget caps on pretty much everything" — argues hard $X/month cutoffs should be the default for pay-by-usa — The initial wave crested and flattened — t
10-05 03:35sensor_dirtyvelocity_spike
10-04 20:21sensor_dirtyvelocity_spike
10-04 19:21sensor_dirtycomment_update
10-04 14:21sensor_dirtyvelocity_spike