我们几乎需要对所有东西设置默认的硬性预算上限

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

西蒙·威利森 Simon Willison · Simon Willison's Weblog · 2026-10-03 · Simon Willison's Weblog ↗

打开互动全文版(逐段中英对照 + 针对本篇提问)→

摘要 · Abstract

本文主张,按用量付费的服务和 API 亟需默认的硬性预算上限:一旦达到消费阈值,就切断使用并返回错误,而不是像软性上限那样只发送警告邮件。随着编码智能体和个人智能体让开通计费服务变得轻而易举,用户可能一觉醒来,发现自己在睡梦中已产生数百甚至数千美元的失控费用。尽管企业可能不喜欢应用抛出错误,但作者认为,比起收到一张超过一万美元的意外账单,大多数企业更愿意看到错误,因此硬性上限应成为默认设置,而危险的无上限使用则应作为显式选择加入。文章指出,AWS 最近推出了支出限额,Google Cloud 也在 7 月推出了 Spend Caps,这表明趋势向好;并总结道,智能体应推荐带有硬性预算上限的提供商,并警告缺乏经验的开发者远离无上限的服务。

The article argues that pay-by-usage services and APIs urgently need default hard budget caps, which cut off usage and return errors once a spending threshold is reached, rather than soft caps that merely send warning emails. As coding agents and personal agents make it easier to spin up billable services, users risk waking to runaway costs of hundreds or thousands of dollars incurred while they slept. While businesses may dislike applications throwing errors, the author contends most would prefer errors to a surprise bill exceeding $10,000, so hard caps should be the default with dangerous uncapped usage as an explicit opt-in. The piece notes that AWS recently launched spending limits and Google Cloud introduced Spend Caps in July, suggesting a positive trend, and concludes that agents should recommend providers with hard budget caps and warn inexperienced builders against uncapped services.

核心贡献 · Key contributions

局限 · Limitations

章节 · Sections(共 1)

全文 · Full text(逐段中英对照)

我们需要对几乎所有东西设置默认硬性预算上限 We’re going to need default hard budget caps on pretty much everything

未来数月乃至数年,世界将越来越需要一种产品功能:默认硬性预算上限。我指的是按使用量付费的服务和 API 中的功能,让你可以设定“每月超过 X 美元后,切断服务并返回错误”。这些必须是硬性限制。软性上限,即“每月超过 X 美元后,给我发警告邮件”,是不够的。

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.

编码智能体和个人智能体(包装在较不具威胁性 UI 中的编码智能体)极大地降低了启动能执行有用任务的代码的摩擦。有时这些任务会花钱——调用付费 API、托管 Web 应用,或可能对额外存储和算力计费的系统。

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.

反对这一点的理由是,企业不希望其托管应用因为超出预算而开始抛出错误。我预计大多数企业和个人宁愿选择错误,也不愿收到意外的 10,000 美元以上账单。

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:

我最希望看到提供这种服务的公司是 AWS。我听过很多人的故事,他们拒绝在个人项目中使用 AWS,因为(有理由地)担心某个失控的服务可能会让他们破产。我也听过一些人的故事,他们 _没有_ 预料到这一点,结果遭受了严重损失。

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.

……结果发现 AWS 几周前终于推出了支出限额!根据他们 9 月 16 日的公告“新的 AWS 体验帮助构建者快速上手并更快部署”:

... 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" on 16th September:

另请参阅“在 AWS 设置中创建支出限额”,不过该页面警告称“我们目前正在向有限数量的客户发布新体验。”希望这能尽快面向现有账户全面开放。

See also "Create a spend limit in AWS Settings", 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 在 7 月推出了类似功能,称为 Spend Caps,它允许你“为项目中的特定服务设置每月财务上限”。看起来这正在成为一种趋势!

Google Cloud launched a similar feature 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.

互动版:针对本篇提问 →

接着读 · Read next