管钱 · 熟练
AI 一晚上能烧掉多少，你知道吗？
上限不是事后看账单，是调用时就挡住
订阅费是可以预期的，按次调用不是 —— 一本月费账单封得住前者，封不住后者。真正让人翻车的场面已经被统计过：有人让 agent 跑了一晚，账单超过一万美元，而他在中途没有任何办法叫停。这一页做的是一道装在最外层的闸门：先分清两种花费 → 定三个数字（单次 / 每小时 / 每天）→ 把上限写进调用层而不是写进心里 → 到点先停再决定要不要抬。它要解决的只有一件事：让「花超了」变成一次中断，而不是一条通知。
方法 · 一图看懂
1
先分清两种花费 — 订阅费按月可预期，按次调用费没有天花板；要装闸门的是后者
2
一次先定三个数字 — 单次上限 + 每小时上限 + 每天上限；先设窄、再按实际放宽
3
闸门写在调用层 — 上限要落在脚本参数与工作区配置里，⛔ 不靠人盯屏幕
4
到上限的动作是「停」 — 停下 · 留痕 · 再决定抬不抬；⛔ 不设自动重试绕过去
原理 · 为什么有效
为什么「盯账单」防不住这类花费 —— 因为它不是一条线性的账，是一条指数曲线。订阅是每月扣一次，你随时看得见余额。而 agent 的花费发生在「它自己决定再调一次工具」的循环里：一次失败的重试、一个忘了退出的轮询、一段被反复喂回去的长上下文 —— 每一步都合理，合起来就是一夜之间十万次调用。更麻烦的是，这类花费没有「当前余额」这个界面：控制台里的数字是延迟汇总的，等你看到，钱已经花完了。而闸门的价值恰恰在于它不依赖任何后置的观测 —— 它是在请求发出之前就拒绝的那一下。这也解释了为什么这条建议的表述是「默认就开」而不是「按需开启」：能被事后发现的花费，本来就不是这类花费。
适用场景
适合：把 agent 挂成定时任务或常驻服务的人；跑批量调用（批量改写 / 批量生成 / 批量抓取）的人；把 API key 交给了脚本、甚至交给了第三方的团队；以及任何「一个人管着好几个自动化任务、却说不清它们一个月花多少」的处境。不适合：只做单次问答、每月按固定额度付费的人 —— 你已经在闸门里面了，再加一层只是白配。也不不适合用于「本来就要花大钱」的科研批跑 —— 那种场景要的不是上限，是分段 checkpoint 与预算审批，两者形状不同。
自测 · 4 问
我能不能说出手上每个自动化任务一个月大概花多少？说不出的，先做这一条
我设的是不是三个数字，而不是只有一个？（只设每天，等于给了它一夜的时间花完）
上限落在哪里？写在脚本参数 / 工作区配置里 ⇒ 算；写在我记得要盯 ⇒ ⛔ 不算
到上限时它会停还是继续？如果脚本里有自动重试，先确认重试不会绕过上限
怎么上手 · 验证步骤
上手顺序：先量，再设闸，最后才谈优化。第一步，量 —— 把手上所有会调 API 的东西列出来（脚本 · 定时任务 · 常驻服务 · 别人给你配好的自动化），每一条写「谁在用 / 调什么模型 / 大概多久跑一次」。第二步，分清两条账：按月扣的走预算，按次扣的进闸门。第三步，给每一条按次扣的设三个数 —— 单次上限、每小时上限、每天上限；窄一点没关系，先让它响一次。第四步，把这三个数写进调用层：脚本的启动参数、定时任务的配置、或者平台侧的花费上限。第五步，故意压到上限试一次，看它是干净地停下并留下记录，还是静默重试。
设完一周内做三件事：① 挑一个任务，把它今天的调用次数与实际花费对一遍，看两者是否同量级（差一个数量级说明你的估算口径错了）；② 人为制造一次到限，确认它停下来了，并且在日志里留下了「因上限停止」这类可检索的记录；③ 打开平台侧的花费上限页面，确认它记的是你刚刚测试的那一天 —— 三方对得上，才算这套闸门真的装上了。