Cloudflare推出Spend Management测试版，率先支持按量付费客户为Workers和Durable Objects设置支出阈值，并在达到限制后暂停收费调用。由于费用计量与阻断异步执行，阈值并非零超支保证；当前控制仍以产品为单位，尚不支持单个应用或智能体的跨产品总预算。
Cloudflare于2026年11月13日宣布推出Spend Management测试版，面向按量付费（PayGo）客户，首先支持Workers和Durable Objects。开发者不仅可以接收费用提醒，还能主动设置支出阈值，让平台在评估支出达到限制后，暂停相应产品的收费调用。
这项功能为运行在Cloudflare上的AI应用增加了一层基础设施成本控制，但它并不是一个覆盖所有模型、计算和存储费用的统一预算系统。根据官方发布公告，目前的控制单位仍是产品；面向单个应用或智能体、跨多个产品汇总费用并单独暂停任务的能力，属于后续计划。
另一个关键限制是执行方式：费用计量和阻断政策异步流转。因此，设置支出限制有助于控制异常用量，却不等于账单绝不会超过所设金额。
从“提醒花了多少”到“暂停继续调用”
Cloudflare此前已经为付费套餐提供用量通知和预算提醒。两者与此次发布的区别，在于是否能够干预后续活动：提醒把信息交给管理员，阻断政策则允许平台暂停产生费用的调用。
按照公告，用户可以在控制台的账户管理、账单及Spend limits页面，为支持的产品启用控制，设置支出限额、一个或多个提醒阈值，以及接收通知的电子邮箱。控制台也会显示当前账期的估算费用和审计日志，供管理员查看谁在何时修改了限额，以及何时触及限制。
配置不限于网页界面。Cloudflare同时提供cf命令行工具和Spend Policies REST API。接口将通知与用量阻断列为不同动作，产品标识目前包括Workers和Durable Objects，阈值则以美分表示。这意味着开发者可以把预算政策纳入自己的管理流程，但需要明确选择希望执行的是提醒还是阻断。
预算周期也不应直接理解为自然月。Cloudflare解释，账期从付费订阅开始时计算，而不是从部署Worker或创建预算政策时重新开始。因此，在一个已产生费用的账期中设置限额，必须考虑该周期已经累计的支出。
触发阻断后，相关产品的新调用会被拒绝。官方特别说明，暂停对象是会产生费用的客户代码调用：以Workers为例，Cron定时触发和Queue队列消费者调用会暂停，但静态资源仍会继续提供。
恢复服务有三种路径：把限额提高到当前账期累计支出之上，停用或删除阻断政策，或者等待下一个账期开始、现有阻断到期。这使预算控制同时成为一项可用性决策——限额过低可能切断业务处理，而不只是改变账单页面上的数字。
为什么“低于10分钟”不是零超支承诺
Cloudflare称，控制台可以在近实时、低于10分钟的时间范围内呈现支持产品的当前账期费用。但这一表述不能理解为每次请求都先向计费系统核准余额，也不能视为所有情况下阻断都会在固定时限内完成的保证。
官方披露的处理流程说明了其中差别。请求、CPU时间、执行时长或存储操作等原始测量数据，会先在靠近来源的位置聚合。第一阶段通常使用一分钟窗口，第二阶段通常使用五分钟窗口，减少需要下游系统处理的数据量。
随后，Usage Engine把聚合结果转换为标准化用量记录；Rating Engine再结合订阅信息、价格、套餐内额度和舍入规则，将用量换算为累计费用。支出判断因此不是简单地把每个请求的标价相加，而要考虑账户在整个账期中的计费状态。
用量与订阅更新又是彼此独立的数据流。Cloudflare表示，如果用量先到、定价所需的订阅信息尚未到达，系统会保留这些待处理记录，之后重新计算，而不是把暂时无法定价的用量当成免费。
阻断同样不是同步完成。计费引擎判断达到阈值后，政策服务会把限制发送给运行时配置服务及Cloudflare内部的Quicksilver键值存储，再异步传播到全球节点。运行时在周期性刷新时取得政策，才开始拒绝受限调用。
这一架构让正常请求不必等待中央计费引擎，但也留下测量、聚合、评估、传播和刷新之间的时间差。API文档对此使用了明确限定：余额是异步估算，而不是同步读取的用量；政策状态还区分期望执行状态与实际下发进度。
据此，预算阈值更适合被理解为触发控制的条件，而不是不可突破的预付款余额。Cloudflare计划继续缩短从测量到执行的间隔，并希望降至一分钟以内，但这是未来目标，不是此次测试版已经实现的结果。
AI推理预算与基础设施预算，控制的是不同费用
对智能体应用而言，模型调用并不是唯一成本。任务还可能持续占用计算资源、保存状态、访问数据库或写入存储。只限制模型推理支出，不能自动限制这些外围资源。
Cloudflare现有的AI Gateway支出限制主要处理经过网关的AI请求。官方文档显示，它可以依据模型、服务商及自定义元数据设置预算，也可以让不同用户、团队或智能体拥有独立预算。累计费用达到相应时间窗口的限额后，网关会阻止后续请求并返回429响应，直到窗口重置。
这类限制与按请求数量设定的速率限制也不相同：不同模型、输入与输出令牌用量会产生不同费用，因此相同请求次数不代表相同支出。文档同时限定，AI Gateway的支出限制适用于统一计费请求，以及价格已知模型的自带密钥请求；它并不覆盖绕过网关发生的任意调用。
Spend Management则先把控制范围扩展到Workers和Durable Objects的产品支出。两者可以配合使用，分别约束推理入口和部分运行资源，但并未因此合并成同一个应用总账。
这也与选择更便宜模型的成本优化有所区别。此前AI Gateway Auto Router公测关注的是模型选择与能力、成本之间的取舍；本次支出控制关注的则是，在费用达到阈值后是否继续允许运行。预算控制本身不会判断一次调用是否值得，也不保证任务能在预算内完成。
距离“给一个智能体设置总预算”还有多远
Cloudflare在公告中提出，未来希望让应用或智能体的调用携带标签，并把相关元数据一路传递到计费引擎。这样才能把同一个任务在计算、数据库和存储等产品上的费用归到一起，并在触及预算时，只暂停该应用或任务，而不影响其他无关应用。
这个设想也凸显了当前版本的边界：目前仍按产品和基础服务衡量支出，不能把它当成已经上线的、面向单个智能体的跨产品预算隔离机制。共享同一产品的多个应用，在规划限额时需要考虑产品级阻断对整体服务的影响。
对开发团队而言，测试版最明确的变化，是多了一种由平台执行、而非仅靠人工查看提醒的成本控制手段。实际采用时，限额应与告警、任务取消、失败处理及恢复机制共同设计，既考虑异常调用的财务风险，也考虑暂停调用带来的业务后果。
目前可确认的是功能范围、公开接口和官方披露的架构；这些资料并不是独立的超支幅度或停用延迟测试。Spend Management让Cloudflare从“显示和通知费用”向“在阈值后限制运行”迈进一步，但能否进一步做到跨产品、细粒度且低延迟的任务预算控制，仍取决于后续交付。