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

我们几乎需要在所有事物上设置默认的硬性预算上限

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.

在接下来的几个月乃至几年里，世界将非常需要这样一种产品功能：默认的硬性预算上限。我指的是那些按使用量付费的服务和 API 所具备的功能，它允许你设定“每月消费超过 X 美元后，切断服务并返回错误”。这必须是硬性限制。软性上限，即“每月消费超过 X 美元后，给我发一封警告邮件”，是远远不够的。

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.

编程智能体（Coding agents）以及个人智能体（即包装在更友好界面下的编程智能体），极大地降低了运行有用代码的门槛。有时这些操作会产生费用——比如调用付费 API、托管 Web 应用程序，或者会产生额外存储和计算费用的系统。没人希望在半夜醒来时看到一封关于预算超支的警告邮件，并发现当自己睡觉时，失控的服务已经多消耗了几百（甚至几千）美元。

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.

反对这一观点的理由是，企业不希望托管的应用程序因为预算超支而报错。但我认为，大多数企业和个人宁愿看到报错，也不愿收到一张意料之外的 1 万美元以上的账单。我认为硬性预算上限应当成为默认设置。如果有人想“冒险”，他们当然可以这样做，但这必须基于主动选择（opt-in）。在显眼位置设置一个清晰的复选框：“移除预算上限。如果我超过了设定的预算限额，我的应用程序不会被关闭，我将承担后续产生的费用。”

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 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.

我最希望看到 AWS 提供此功能。我听过很多人的故事，他们因为担心失控的服务会导致破产（这种担心是合理的），而拒绝在个人项目中使用 AWS。我也听过一些人因为没有预料到这一点而损失惨重。……结果发现，AWS 几周前终于推出了支出限额功能！根据他们 9 月 16 日发布的公告《全新的 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 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!

另请参阅 AWS 设置中的“创建支出限额”（Create a spend limit），尽管该页面提示“我们目前正向有限数量的客户发布这一新体验”。希望它能尽快向现有账户全面开放。Google Cloud 在 7 月也推出了类似功能，称为“支出上限”（Spend Caps），允许你“为项目内的特定服务设置每月财务上限”。看来这正在成为一种趋势！

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.

在理想情况下，我们的智能体可以为此提供帮助。如果智能体开始倾向于推荐那些提供硬性预算上限的供应商，并警告新手开发者不要部署那些可能导致麻烦的无上限服务，那将是非常棒的。