API Key 泄露被刷、Agent 跑了一整夜，能限住账单的只有会拒绝下一个请求的东西：在请求执行时就生效的花费上限、不会自动充值的预付余额，以及一把随时能删的 Key。提醒只能告诉你钱已经花掉了；平台能替你调高的上限，也不是你的上限。在 Router One 上，每把 Key 的消费上限（maxSpend）由你自己设、平台不会自动调高，并且在钱包计费的请求执行前，连同在途请求的预占额度一起检查；但它管不到套餐额度覆盖的请求，所以有套餐的账户要全部停掉，得删 Key。
2026 年，OpenAI、Google Cloud、Cloudflare AI Gateway 和 OpenRouter 都有了会拦下请求的花费上限，其中多数在文档里写明，拦截生效之前花费可能超出上限。
本文只讲出事之后：Key 泄露或 Agent 失控时，什么能限住损失，第一个小时该做什么。日常怎么给每把 Key 设上限、按 Key 归因花费，见 LLM 成本追踪 和 每个应用、agent 与环境各一把 Key。
截至 2026-10-23
- OpenAI、Google Cloud、Cloudflare AI Gateway 和 OpenRouter 都有会拦下请求的花费上限；OpenAI、Google 和 Cloudflare 的文档都写明，拦截生效之前花费可能超出上限。
- Gemini API 账户达到下一档条件后，Google 会自动调高它的档位花费上限。
- Router One 的钱包是预付的，不会自动充值，也没有充值 API；银行卡支付的套餐按固定价格每月自动续费，直到取消。
- Router One 每把 Key 的消费上限是累计的、由你自己设，在钱包计费的请求执行前连同在途预占一起检查；套餐额度覆盖的请求不计入。
- 删掉 Key 之后，这把 Key 上的新请求一律被拒，不论是钱包计费还是套餐覆盖的请求。
适合谁
- 你在 LLM API 上跑 Agent、脚本或后端服务，希望 Key 泄露或程序死循环时，最坏的损失不超过你自己放进去的钱。
- 你能给每个应用、环境和 Agent 各发一把 Key，并且愿意让请求以 HTTP 402 失败，而不是继续计费。
这些情况请看别家
- 你要的是每天、每周或每月自动重置的上限：Router One 的 Key 上限是累计的，不会自动重置。OpenAI 和 Google Cloud 的花费上限按月重置，OpenRouter 的 Key 上限和 Cloudflare 的花费上限可以按你选的周期重置。
- 你要给一组 Key 设一个共同的上限：Router One 只按 Key 限额，钱包余额是唯一覆盖整个账户的上限。
- 公司规定必须直接向 OpenAI、Google 等厂商采购：请用下表里它们自己的上限，并设在你承受得起的金额以下。
2026 年的两起事故，问题出在哪
约 13 小时被刷 5.4 万欧元（2026 年 4 月）。 一把没有设 API 限制的 Firebase 浏览器端 Key 被拿去调用 Gemini。按开发者在 Google AI 开发者论坛的帖子（2026-04-15），80 欧元的预算提醒和费用异常提醒都晚了几个小时才到；等他们反应过来，费用已经到了约 2.8 万欧元，随着延迟的费用数据陆续到账，最终超过 5.4 万欧元。Google Cloud 支持团队拒绝了他们的账单减免申请；之后一位 Google 员工请他们发邮件说明，截至 2026-10-23，帖子里没有后续结果。（Hacker News 讨论）
一夜约 1.8 万美元（2026 年 4 月）。 按 Tom's Hardware（2026-04-22）引用当事人自己发的帖子：攻击者找到他几个月前从 AI Studio 发布的一个 Cloud Run 服务，通过它的公开地址发请求；这个服务用存放在容器里的 API Key 调用 Gemini。账单达到 A$25,672.86，约合 18,400 美元。账户设的是 A$10、只发提醒的预算；事故期间花费越过门槛，Google 自动把账户升到了更高的 Gemini 档位，花费上限也随之调高。Tom's Hardware 报道说，这笔费用看起来已被免除。（Hacker News 讨论）
这两次为什么没拦住，Google 自己的文档写得很清楚。预算文档原文："Setting an alerts-only budget doesn't automatically cap Google Cloud or Google Maps Platform usage or spending."（只发提醒的预算不会自动限制用量或花费。）Gemini API 计费文档写明，账户满足下一档条件时，"you will be automatically upgraded to the next tier (subject to processing times)"（会被自动升到下一档）。
由此得出两条结论：提醒告诉你的是已经发生的花费；平台能替你调高的上限，不是你的上限。真正保护你的，是只有你能调高、并且在下一个请求执行前就检查的上限。
2026 年各家的花费控制对照
「大厂只会发提醒」的说法已经过时：下表每家都有会拦下请求的上限。区别在于什么时候检查、管多大范围、谁能调高。每一行都在 2026-10-23 对照厂商自己的文档核对过。
| 控制项 | 能否挡住花费 | 何时检查 | 管多大范围 | 谁能调高 | 是否承认可能超出 |
|---|---|---|---|---|---|
| OpenAI 花费上限 | 能：请求返回 HTTP 429，错误码 organization_spend_limit_exceeded 或 project_spend_limit_exceeded | 不是即时生效 | 一个组织或一个项目，按月周期 | 有权管理该组织或项目设置的人 | 承认："recorded spend can slightly exceed the configured amount" |
| Gemini API 档位上限（Google） | 能：该账单账户下所有项目暂停服务，直到下个周期 | 按账单账户的当月花费 | 一个账单账户，按月 | Google，在账户满足下一档条件时自动调高 | 档位上限未说明；AI Studio 里实验性的项目上限写明可能超出 |
| Google Cloud 花费上限（2026-07-29 以公开预览版推出） | 能：该服务暂停到当月结束，除非你手动解除上限 | 按估算费用；文档写明不是即时生效 | 一个项目加一个支持的服务（Gemini API 在内），按自然月 | 拥有花费上限权限的人，例如账单账户管理员 | 承认："any cost overages are billed as normal" |
| Cloudflare AI Gateway 花费上限 | 能：默认返回 HTTP 429，也可以改为切到你配置的备用模型 | 请求发往供应商之前，按已记入的花费检查；费用在每个请求完成后才记入（最终一致） | 按网关规则：可按供应商、模型或自定义元数据，固定或滚动周期 | 能管理该网关设置的人 | 承认：并发请求集中到达时 "can briefly exceed the limit" |
| OpenRouter Key 上限与护栏 | 能：先触到的上限拦下请求（护栏上限返回 403） | 请求时：先查工作区预算，再查护栏 | 每把 Key 的额度，可按日、周、月重置；护栏按成员或按 Key | Key 上限由 Key 的所有者设；护栏由账户所有者或组织管理员设 | 工作区预算写明可能 "run slightly over"；Key 上限未说明 |
| Router One 钱包 | 能：余额不够时，账户下每把 Key 上需要钱包付费的请求都返回 HTTP 402 INSUFFICIENT_BALANCE | 每个钱包计费的请求执行前 | 整个账户 | 只有你自己充值；不会自动充值 | 不会：任何请求的扣费都不会把余额扣成负数 |
| Router One Key 消费上限（maxSpend） | 对钱包计费的请求能：返回 HTTP 402 API_KEY_SPEND_CAP_EXCEEDED；套餐覆盖的请求不计入 | 每个钱包计费的请求执行前，对照 Key 剩余额度并扣除在途预占 | 一把 Key，累计，不重置 | 你自己，在控制台 → API 密钥；平台不会自动调高 | 不会：超出预占的部分只从 Key 剩余额度里扣 |
出处与原文，均于 2026-10-23 核对：
- OpenAI。 按 OpenAI 的花费上限文档，组织上限 "applies to API traffic across all projects in the organization"，项目上限 "applies only to API traffic billed to that project"，上限在下一个月周期重置，并且 "Enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount."。OpenAI 支持团队在 2026-09-07 的论坛回复里确认已支持项目上限。
- Gemini API 档位。 按 Google 的 Gemini API 计费文档（2026-09-28 更新），"Each tier has a maximum monthly spend limit"，上限在账单账户这一层执行（"at the billing account level"），触顶后 "for all projects linked to that billing account until the start of the next billing cycle" 暂停服务。同一页还提供 AI Studio 里实验性的项目上限，并提示："You may experience overages beyond your project cap if billing data hasn't processed before more charges are accrued."
- Google Cloud 花费上限。 Google 在 2026-07-29 宣布以公开预览版推出，Gemini API 在支持的服务之列。按花费上限文档，一个上限只管 "a single Google Cloud project and a single eligible service"，预算周期按月，触顶后该服务在本预算周期（当月）剩余时间内暂停（"paused for the remainder of the budget period"），除非你手动解除上限，并且 "the enforcement of spend caps isn't instant and any cost overages are billed as normal."
- Cloudflare AI Gateway。 花费上限于 2026-06-05 推出。按花费上限文档，上限在请求发往供应商之前检查，被拦下的请求返回 429，"Spend limits are eventually consistent"，并且 "a burst of concurrent requests can briefly exceed the limit before enforcement catches up."
- OpenRouter。 按 OpenRouter 的花费控制文档和它关于花费治理的文章（2026-09-24 更新），每把 Key 的额度可以按日、周、月重置，护栏按成员或按 Key 生效，"the first limit reached blocks the request"；按它的护栏文档，护栏预算拦下的请求返回 HTTP 403。
- Router One。 2026-10-23 对照网关的计费代码核对，细节见下文。
Router One 怎么给泄露的 Key 和失控的 Agent 封顶
钱包是预付的，不会自动充值
钱包计费的请求从你充进去的余额里扣。没有自动充值，也没有充值 API，所以 Key 泄露也不会让账户多花你没充进去的钱。任何请求的扣费都不会把余额扣成负数：余额不够时，账户下每把 Key 上需要钱包付费的请求都返回 HTTP 402，而不是先欠着。唯一会重复扣钱的是套餐：银行卡支付的套餐按固定价格每月自动续费，直到你取消；用余额支付的套餐只开通一个周期。两者都不会随用量变多。
每把 Key 由你自己设上限
每把 Key 的消费上限（maxSpend）限的是这把 Key 能从钱包扣的钱：累计扣费到上限后，这把 Key 上需要钱包付费的请求返回 HTTP 402。套餐额度覆盖的请求从账户共用的套餐额度里扣，不计入任何 Key 的上限。
出事时有三点最要紧：
- 上限归你管。 在控制台 → API 密钥里设置、调高或清除，不管账户花了多少，平台都不会替你调高。调低后，从这把 Key 的下一个请求起生效。
- 上限是累计的。 它把这把 Key 自创建以来从钱包扣的钱全部算进去，不按自然月重置，所以泄露的 Key 到了下个月也不会凭空多出额度。
- 请求执行前就检查。 每个钱包计费的请求，网关都先为它预占一笔额度，再对照这把 Key 还剩多少：上限，减去已经扣掉的，再减去这把 Key 上其他在途请求预占的。所以并行的 Agent 调用不会同时花掉同一笔余量。这把 Key 剩下的额度不够一个请求时，请求在调用任何模型之前就以 HTTP 402 被拒。请求结算时，没用完的预占会释放；实际费用超出预占的部分，只从这把 Key 和钱包还剩的额度里扣。
客户端会看到什么
Key 到上限时返回 HTTP 402，错误类型为 billing_error；在 OpenAI 格式的端点上错误码是 API_KEY_SPEND_CAP_EXCEEDED，所有端点的错误消息都以 api key spend cap reached 开头，并说明给钱包充值不会解除这个上限。钱包余额不够时返回 HTTP 402，错误码 INSUFFICIENT_BALANCE。响应里带 X-Billing-Funds-Reason 头时，可以用它区分这两种情况。两者都是 402，而不是 429，所以遇到 429 就退避重试的客户端，不会把「花费已被拦下」当成该继续重试的信号。详见 API 错误码。
限流只能放慢死循环，管不住花费
每把 Key 和每个账户还有平台默认的每分钟请求数与每分钟 token 数限流。它们能让失控的循环慢下来，但跑一整夜照样会花钱。限流是平台默认值，不是 Key 上能自己设的项；需要更高时，可以发邮件给支持团队申请调高。
到期日
Key 可以设到期日，到期后的请求一律被拒。测试、演示、短期合作用的 Key 都应该设上到期日，这样日后就算泄露，Key 也已经失效。到期但没删的 Key 仍占账户的有效 Key 名额，用不到了就删掉。
有套餐的账户：只设上限还不够
Pro、Max、Ultra 套餐的额度属于整个账户，账户下每把 Key 都从同一份额度里扣。套餐覆盖的请求不从钱包扣钱，所以不计入任何 Key 的上限：Key 上限已用完、钱包已空，这些请求照样能用。泄露的 Key 在有套餐的账户上，可能把你自己要用的套餐额度用光。真金白银的损失仍然有底：已付的套餐费用加上钱包余额。调低上限停不掉套餐覆盖的请求，删 Key 才行。
怎么发现泄露或死循环
- 按 Key 看用量。 控制台 → 用量按所选时间段，把各 Key 按花费、Token 和请求数排序。你没想到的 Key 排到前面，就是第一个信号。
- 按 Key 看日志。 在控制台 → 日志里按 API Key 筛选，看有没有你从来不用的模型、深夜等没人在用的时段出现的流量，或者几秒一次、几乎一样的请求——这是 Agent 卡在死循环里。
- 上限提醒。 Key 用到 maxSpend 的 80% 以及触顶时，控制台会发站内通知。Key 额度提醒只在站内，也没有 webhook。
- 自己的监控。 服务端可以用账户下任意一把 Key 轮询
GET /v1/balance；余额掉得比平时快，就是信号。它只报钱包余额，不报单把 Key 的花费，也不报套餐额度（见余额监控指南）。 - 日志里看不到的。 在调用任何模型之前就被拒的请求没有日志记录：已删除或已到期 Key 的 401、触顶或钱包为空时的 402、触发你自己限流的 429。删掉泄露的 Key 之后，日志变安静，说明拦截在起作用。
第一个小时：止损步骤
- 删掉这把 Key：在控制台 → API 密钥里删除。这把 Key 上的新请求一律被拒；已经在跑的请求会跑完并照常计费。有套餐的账户上，只有删 Key 能连套餐覆盖的请求一起停掉，调低上限做不到。
- 换一把新 Key：给它设好上限，临时用途的再设上到期日。放进密钥管理或服务端环境变量后重新部署，别再放回客户端代码里。
- 核对损失：在控制台 → 日志里按被删的 Key 筛选事故时段，导出 CSV：请求 ID、模型、Token、费用和时间，就是这次事故的记录。同一时段的钱包流水也导出一份。
- 找到漏洞：查这把 Key 放在过哪里：前端打包产物、移动端应用、公开仓库及其提交历史、CI 日志、共享的
.env文件，或者任何人找到就能调用模型的公开接口。放在同一处的其他 Key 全部换掉。 - 查看钱包：用
GET /v1/balance或控制台查看余额，确认漏洞堵上之后再充值。 - 联系支持：如果有对不上你自己流量的扣费，把 Key 名称、时间段和请求 ID 发邮件到 support@router.one 。
预防：让下一次泄露的损失变小
- Key 不进客户端。 不要把 Key 打进浏览器代码、移动端应用或公开仓库。放在服务端也只和调用它的接口一样安全：上面第二起事故，就是通过一个存着 Key 的服务的公开地址被刷的。所以凡是会花你的 Key 的接口，前面都要有身份验证和你自己的按用户限额。
- 每个应用、环境和 Agent 各一把 Key，各自的上限按「有人发现之前，这个任务最多能花多少」来定。这样预发环境的死循环会停在预发 Key 的上限，生产环境照常运行。
- 短期用途的 Key 设到期日：测试、演示、CI 任务、黑客松。
- 在 Agent 里也设限：限制循环次数、每次调用设
max_tokens、同样的工具调用反复出现时就停。见 AI Agent 生产环境指南。 - 不用的 Key 及时删掉。 到期但没删的 Key 仍占账户的有效 Key 名额。
每个任务的上限怎么定、怎么按 Key 看花费，见 LLM 成本追踪 和 每个应用、agent 与环境各一把 Key。
这套做法做不到的
- 不会按月重置。 Key 的上限是累计的。想给某个任务一份新额度，就调高它的上限，或者换一把新 Key。
- 不能给一组 Key 设共同上限。 只能按 Key 限额；钱包余额是唯一覆盖整个账户的上限。
- 没有推送告警。 Key 额度提醒只在站内；没有 webhook，也没有用量 API，用量数据只在控制台和它导出的 CSV 里。
- 管不到套餐额度。 套餐覆盖的请求不计入任何 Key 的上限。
- 别指望事后退款。 充值积分一经到账即不可退款，我方计费错误及法律强制要求的情形除外（见退款政策）。泄露的 Key 产生的用量就是你账户的用量（见服务条款），所以真正的保护是事先设好的上限和预付余额。
常见问题
API Key 泄露后，前 10 分钟该做什么？ 删掉 Key，而不是只调低上限：删除的 Key 会拒绝新请求，而只设了上限的 Key 仍能跑套餐覆盖的请求。然后从密钥管理里换上新 Key，在日志里按旧 Key 筛选并导出 CSV，找到泄露的地方之后再充值。
泄露的 Key 被刷掉的钱能退吗？ 不管哪家都别指望：上面那起 5.4 万欧元的事故，Google Cloud 支持团队就拒绝了开发者的账单减免申请。在 Router One 上，泄露的 Key 产生的用量就是你账户的用量，充值积分一经到账即不可退款，我方计费错误及法律强制要求的情形除外。能保护你的，是事先设好的上限：设了上限的 Key 和预付余额。
Key 的消费上限能挡住泄露 Key 上的所有请求吗？ 不能。每把 Key 的消费上限（maxSpend）限的是这把 Key 能从钱包扣的钱：累计扣费到上限后，这把 Key 上需要钱包付费的请求返回 HTTP 402。套餐额度覆盖的请求从账户共用的套餐额度里扣，不计入任何 Key 的上限。有套餐的账户上，触顶的泄露 Key 仍能用套餐额度；删掉 Key 才能两边都停。
并发请求或 Agent 死循环会不会让 Router One 的 Key 超出上限？ 每个钱包计费的请求执行前，网关都先预占额度，并对照这把 Key 的剩余额度检查，同时扣除这把 Key 上其他在途请求的预占，所以并发请求不会同时花掉同一笔余量。如果请求的实际费用超出预占，超出的部分只从这把 Key 和钱包还剩的额度里扣。
给钱包充值能解除 Key 的上限吗？ 不能。钱包和 Key 上限是两回事：钱包为空时，每把 Key 上需要钱包付费的请求都返回 HTTP 402，错误码 INSUFFICIENT_BALANCE；Key 触顶时，即使钱包有余额，它需要钱包付费的请求也返回 HTTP 402，错误码 API_KEY_SPEND_CAP_EXCEEDED。要在控制台 → API 密钥里调高或清除上限。
一把 Key 泄露了，要不要把所有 Key 都换掉？ 和泄露的 Key 放在同一处的都要换，比如同一个仓库、同一个 .env 文件、同一套 CI 或同一个应用安装包，因为暴露了一把，多半也暴露了其他的。放在别处的 Key 可以保留，在日志里看一下它们的记录再确认。
有花费提醒还不够吗？ 提醒告诉你的是已经花掉的钱。上面那起 5.4 万欧元的事故，提醒晚了几个小时才到，那时已经扣了约 2.8 万欧元；另一起的预算只发提醒，事故期间 Google 还自动调高了账户的档位上限。提醒用来发现问题，止损要靠会拒绝请求的上限：只有你能调高的 Key 上限、预付余额，以及短期 Key 的到期日。
下一步
- 替公司采购：Router One 公司采购须知 把付款、发票和限额放在一页里讲清楚。
- 给研发团队上编程 Agent，每人一把带上限的 Key：研发团队怎么上 Claude Code 和 Codex
- 日常的上限与归因：LLM 成本追踪 和 每个应用、agent 与环境各一把 Key
- 在服务端盯钱包：余额监控指南 和余额接口说明
- 读懂 402 和 429：API 错误码；Key 怎么保存：安全；套餐与单价：定价
到 router.one 建 Key，在用得上之前就给每一把设好上限。