最新资讯
dev.to 精简 MCP server 工具数量:更少工具、更小影响面,双重收益 dev.to 为什么 git checkout 无法撤销 AI 编码 agent 的改动? wechat AI短剧门槛降降降!实测即梦短剧工作室:剧本分镜预演一条龙,伙伴计划长期护航 dev.to 让模型改写文档前,先量化事实保真度 dev.to 回放 153 个 Claude Code 与 Codex 会话,审计 Agent 的生产影响范围 dev.to 银行 77 意图分类最便宜 LLM:GPT-6.1 Terra 每次成功任务 $0.000727 theinformation.com Chesky的副业:Airbnb向CEO新设AI实验室出售IP theverge.com OpenAI 宣布数据中心项目不再与公职人员签署保密协议 dev.to NVIDIA 发布四个开放 Cosmos 3 仿真模型 dev.to 真实 MCP 客户端击穿我们服务器的五种方式 theverge.com Airbnb 正在开发 AI 旅行 agent,计划 2027 年上半年推出 wechat 这可能是美国AI最魔幻的一天。
多元动态
登录 注册
智能体 simonwillison.net · @Simon Willison's Weblog

我们需要为几乎所有服务设置默认硬性预算上限

原文 我的收藏

Simon Willison 主张按用量付费的服务和 API 应默认提供硬性预算上限:达到每月 X 美元后直接切断并返回错误,而非仅发送警告邮件的软上限。他指出编码 agent 和个人 agent 降低了启动付费代码的门槛,可能在用户睡眠期间产生数百甚至数千美元的额外用量,并提到企业不愿托管应用报错是反对理由之一。

AI推荐理由 Simon Willison 提出按用量付费的 API 和服务应默认提供硬性预算上限(达到阈值即切断并返回错误),而非仅发警告的软上限;他给出的具体场景是编码 agent 和个人 agent 降低了启动付费代码的门槛,可能在无人值守时产生数百至数千美元的额外费用。这是有明确论点的观点文章,非官方发布或实测数据,文中也提到企业不愿托管应用报错的反对意见,属未决讨论。

72

正文

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. Tags: [amazon-web-services](https://simonwillison.net/tags/amazon-web-services), [ai](https://simonwillison.net/tags/ai), [coding-agents](https://simonwillison.net/tags/coding-agents)

来源报道 · 4 篇 · 以下链接均前往原始媒体

rss::Simon Willison's Weblog 我们需要为几乎所有服务设置默认硬性预算上限 10-04 · 原文发布
opmlrss::Simon Willison's Weblog 我们需要为几乎所有服务设置默认硬性预算上限 10-04 · 原文发布
Simon Willison's Weblog 我们需要为几乎所有服务设置默认硬性预算上限 10-04 · 原文发布
← 返回精选动态 原文

更多内容