预算耗尽

B 层——第三方归属供应商——按调用计费。预算的存在是为了让流量尖峰、重试风暴或写错的循环无法产生一张无上限的账单。它是成本控制，而和这套系统里的其他控制一样，它的降级路径是 HOLD。

你会看到什么

在裁决接口上：HTTP 200，verdict: HOLD，reason code BUDGET_EXHAUSTED。

不是 402，不是 429，不是错误。预算用完是关于你账户的一个事实，由此产生的裁决是一条真实的裁决，有真实的 decision_id 和真实的证据引用。

盯住花费

billable_units 在 POST /v1/screen/address 与 POST /v1/decide/deposit 上都会返回。

• A 层从不计费。只走 A 层的筛查响应是 0。
• 幂等重放不再计费。它带 Idempotency-Replayed: true。
• 请求 depth: B 不保证真的发生了供应商调用——你的路由规则、成本闸门与缓存都挡在前面。没有发生供应商调用时，layer_b 为 null。

对燃烧速率告警，不要对耗尽告警。等你看到 BUDGET_EXHAUSTED，挂起已经在堆积了。

怎么恢复

两条路，而且它们不等价。

等周期滚动。 正确，且免费。因 BUDGET_EXHAUSTED 挂起的入金，required_actions 里带 RE_DECIDE_AFTER_RECOVERY——预算恢复后用一个新的幂等键重新裁决。

调高预算。 在有人判断新的额度就是对的额度时，也正确。让它成为一个有署名的决定，而不是对某个阈值的自动反应。

自动加额是危险的那一种

由 BUDGET_EXHAUSTED 触发的自动加额，会拆掉防止失控循环的最后一道兜底。把预算烧穿的那个条件，通常不是「业务一夜增长四成」，而是每次尝试换一个新幂等键的重试循环、忘了关的全速影子模式部署，或者某人启动后忘掉的一次回填。

调高任何东西之前，先查三件事：

1. 每笔入金的 billable_units 是不是你预期的数，还是一笔入金产生了好几条裁决？
2. 你的幂等键是每笔入金稳定，还是每次尝试都新的？
3. 有没有只需要 A 层的东西在按 depth: B 筛查？

多数预算事故是这三者之一，而它们没有一个能靠加预算解决。