结论：费用告警不等于硬限额。 以 OpenAI API 为例，达到 spend alert 只会发出通知，API 请求仍可继续；需要在组织或项目的月度预算中另外启用 Enforce a hard limit，才会拦截受该预算约束的新请求。即使启用了，官方也说明执行并非即时，记录的费用可能略微超过设定值。不要把邮件阈值、仪表盘数字或任意 HTTP 429 都当成“已经封顶”。
本文面向使用 OpenAI API 或 OpenRouter 的应用负责人，依据 2026-10-13 查阅的官方文档写成。产品界面、账户权限和计费规则可能变化，执行时以自己账户的设置和账单为准。下面的数字是演示，不是实测费用或价格。
先判断你需要哪一种控制
| 控制 | 到阈值会发生什么 | 能否据此承诺精确停在金额上？ | 验收证据 |
|---|---|---|---|
| 费用告警 | 通知负责人，允许调查与人工处置 | 不能 | 通知渠道、收件人、测试送达记录 |
| 服务商强制限额 | 服务商按其规则拒绝受限的新请求 | 不能保证精确金额；可能有执行延迟或在途请求 | 限额开关、作用范围、拒绝错误码与时间 |
| 应用侧额度 | 应用在发请求前原子地预留额度并限制并发 | 只能约束你控制的入口；预留上界仍需覆盖真实用量 | 预留/结算账本、并发测试、绕过入口清单 |
这三层可以同时存在。若目标是“超支时有人知道”，告警足够；若目标是“服务商拒绝后续请求”，核对强制开关；若目标是“在多租户产品中按用户分摊并提前阻止”，还需要应用侧账本。任何一层都不应被描述为绝对的账单上限。
OpenAI：检查预算数字旁边的开关
- 确认当前使用的组织、项目及 API key 对应关系；不要在另一个项目的预算页验收。
- 在组织或项目的预算设置中分别检查告警阈值和 Enforce a hard limit。只有预算金额而没有启用该开关，不能认定请求会停止。
- 记录限额作用范围、月度重置周期、负责人和告警收件人。若多个项目共享组织预算，两层设置都要核对。
- 在受控测试环境使用足够低且可恢复的测试限额，观察新请求是否被拒绝；不要通过生产流量“撞限额”。恢复配置后保留错误响应与用量记录。
OpenAI Spend limits 指南列出了两种强制限额错误：organization_spend_limit_exceeded 与 project_spend_limit_exceeded，响应状态为 HTTP 429。它也说明启用硬限额后执行可能不即时。另有组织使用上限、预付余额等约束；排错说明给出了 organization_usage_limit_exceeded 与 credit_balance_exhausted 等不同错误。只看 429 状态码无法判断该重试、加预算还是补余额。
| 实际错误或观察 | 先查什么 | 默认动作 |
|---|---|---|
| 收到告警，调用仍成功 | 告警与强制开关是否分开配置 | 按预案通知；不要声称已停机 |
project_spend_limit_exceeded |
当前 key 对应的项目、预算和执行开关 | 暂停相应任务，人工决定预算或任务优先级 |
organization_spend_limit_exceeded |
组织范围及其他项目是否也受影响 | 暂停组织内受影响调用 |
credit_balance_exhausted |
余额和付款状态 | 停止重复重试，处理余额问题 |
| 其他 429 | 错误体、速率限制信息及重试时间 | 按限流规则有界等待，勿自动提高费用限额 |
一个已经发出的请求即使客户端断线，也不等于服务端停止处理或不计费。应用应保存任务 ID、请求时间、可用的服务商请求 ID、错误码和最终用量，随后与账单核对；遇到未知结果不要把“无响应”记成零费用。关于多层自动重试和未知费用，见重试与对账指南。
OpenRouter：核对 API key 的美元限额和重置规则
OpenRouter 的创建 API key 文档提供可选的 limit（美元）与 limit_reset（daily、weekly、monthly 或不重置），并可设置 include_byok_in_limit。这属于 key 级额度，不要把它误读成全站预算，也不要假设 BYOK 用量必然计入。limit_reset 的重置时间按官方文档所述处理。
对正在使用的 key，可通过当前 API key 查询接口核对 limit、limit_remaining、limit_reset 和 include_byok_in_limit。仅查询配置不会证明所有应用入口都用了该 key；还要列出生产、后台任务、备用 key 和直连服务商的路径。对账时区分 OpenRouter key 限额、账户余额和模型供应商侧限制。
应用侧预留：一个并发算例
假设某租户的演示额度为 100 单位，已经结算 87 单位；两个并发任务各自估计最多会消耗 10 单位。如果二者都只读取“剩余 13”再发送，就都可能放行，形成 20 单位的在途承诺。正确的方向是在同一个事务中预留：第一个预留 10 后，可用额度剩 3，第二个应被拒绝或排队。若第一个最终结算 7，则释放未用的 3，可用额度变成 6。
这一算例依赖“每个任务有可信的预留上界”。若实际费用可能高于预留值，或后台任务能绕过该账本，依旧可能超支。记录 已结算 + 已预留 + 可用额度，并给失联任务设置可审计的对账状态，而不是在超时后直接释放额度。限制最大输出、并发和总尝试数可以收窄风险；仍需用服务商实际用量结算。如何先估算单次与任务成本，见API 成本预算表。
上线前做四个验收
| 场景 | 合格结果 | 不合格信号 |
|---|---|---|
| 仅跨过告警阈值 | 通知送达；系统明确标记“仍可调用” | 将告警当成自动停机 |
| 强制限额拒绝 | 保存状态和错误码；任务暂停，不无休止重试 | 将所有 429 当作临时限流 |
| 两个并发任务争同一额度 | 原子预留只允许额度内的任务发送 | 两个请求都在读取旧余额后放行 |
| 请求超时、回包丢失 | 标记费用未知并进入对账 | 立即记零并重试到成功 |
用模拟计费和受控测试账户验收应用行为；不要为了验证阈值产生无必要的真实调用。保存配置快照、测试请求数、拒绝响应和对账结果。真正对外承诺前，写明限额作用范围、执行延迟与人工处置人。
官方来源（2026-10-13 复核）：OpenAI Spend limits、OpenAI usage/spend 排错、OpenRouter 创建 API key、OpenRouter 查询当前 API key。