Simon Willison 呼吁按用量计费服务默认提供硬性预算上限

这是一个在未来几个月和几年里，世界将会极度需要的产品功能：默认硬性预算上限。我说的是按使用付费的服务和 API 的功能，它允许你设置“每月 $X 之后，切断此服务并返回错误”。这些必须是硬性限制。软性上限，例如“每月 $X 后，发送警告邮件”，是不够的。

编码代理，以及个人代理（在较不具威胁性的用户界面中封装的编码代理），可以大大降低启动能做有用事情的代码的摩擦。有时这些事情会花钱——调用付费 API，或托管的 Web 应用程序，或者能为额外存储和计算收费的系统。

没有人想在半夜醒来收到一封关于预算限制的邮件警告，却发现自己睡觉时，脱离控制的服务已经消耗了几百（或几千）美元的使用费用。

反对这一点的论点是，企业不希望其托管的应用程序因为超过预算而开始抛出错误。我预计大多数企业和个人会宁可选择错误，也不愿面对意外的 $10,000+ 账单。

我认为硬性预算上限需要成为默认设置。如果有人想冒险，他们应该可以这样做，但必须是选择加入的方式。页面上某个显眼位置应该有一个清晰的复选框：

移除预算上限。如果我超过配置的预算上限，我的应用程序不会被关闭，并且我将负责随后的费用。

我最希望看到这项功能的服务是 AWS。我听到过很多人因为（合理的）担心失控的服务可能导致破产，而拒绝在个人项目中使用 AWS。我也听说过一些人没预料到这一点，结果严重受损。

... 结果 AWS 在几周前终于推出了消费限制！根据他们发布的公告《New AWS experience helps builders get started and ship faster》: https://aws.amazon.com/about-aws/whats-new/2026/09/New-AWS-Builder-Experience/ 2026 年 9 月 16 日:

当您准备升级到付费计划时，可以根据您的使用模式为项目设置每月支出上限，以确保不超出预算。如果项目的使用量达到其支出上限，该项目将在当月暂停。

另请参见在 AWS 设置中创建支出上限：https://docs.aws.amazon.com/accounts/latest/reference/create-spend-limit.html，不过该页面提醒，“我们目前正在向有限的客户发布我们的新体验。”希望该功能能尽快向现有账户全面开放。

Google Cloud 在七月推出了类似功能：https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets，称为支出上限（Spend Caps），让您可以“为项目中的特定服务设置每月财务上限”。看起来这正在成为一种趋势！

在理想情况下，我们的代理可以提供帮助。如果代理开始倾向于推荐具有严格预算上限的服务提供商，并警告新的和没有经验的开发者不要使用没有上限的服务以避免潜在问题，那将会非常好。

这是西蒙·威利森（Simon Willison）在 2026 年 10 月 3 日发布的《我们几乎需要对所有项目设置默认的严格预算上限》：/2026/Oct/3/。

以前：OpenAI DevDay 2026 现场博客：/2026/Sep/29/openai-devday-2026-live-blog/

赞助我每月 10 美元，即可获得精选的当月最重要的大型语言模型（LLM）发展电子邮件摘要。

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.

This is We’re going to need default hard budget caps on pretty much everything by Simon Willison, posted on 3rd October 2026：/2026/Oct/3/.

Previous: OpenAI DevDay 2026 live blog：/2026/Sep/29/openai-devday-2026-live-blog/

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