项目进行中充值：加 USDC 时如何不重启 key 和客户端

余额和 key 是两套东西

在聚合站里，API key 代表身份，账户余额代表支付能力。这两者在后端是分开管理的：

• key 本身不存余额，它只绑定到一个账户。
• 每次请求到达时，网关先验证 key 是否有效、是否被禁用或过期。
• 验证通过后，请求被转发到上游模型。
• 请求完成（或流式响应结束）后，系统按实际用量从账户余额扣费。

这意味着，给账户充值并不会改变 key 的状态。key 该有效还是有效，该禁用还是禁用。充值只是让账户余额数字变大。

正在跑的请求会不会因为充值失败？

不会。

一个已经通过鉴权、正在执行的请求，它的扣费发生在请求结束之后。你在请求进行中加余额，对这条请求没有影响，它不会因为“充值动作”而中断或失败。

真正会导致请求失败的是余额不足，而不是充值本身。具体来说：

• 如果请求发起时余额已经低于某个阈值，网关可能直接拒绝，返回余额不足错误。
• 如果请求发起时余额够，但在请求执行期间余额被其他并发请求扣完，那么这条请求结束后可能扣费失败，导致账户变成负余额或触发后续限制。
• 流式请求（stream）持续时间较长，如果余额在流式过程中被耗尽，有的实现会切断连接，有的会允许完成但记账为欠费。具体行为取决于站点的实现。

所以，充值不会打断请求，但余额不足会。

客户端环境变量要注意什么

大多数客户端（OpenAI SDK、Anthropic SDK、各类 CLI 工具）通过环境变量读取 API key 和 base URL。加余额时，你不需要修改这些环境变量，因为 key 没变。

但有几个常见坑：

• 不要为了“刷新”而重启客户端。重启不会让余额生效更快，余额是服务端账户状态，客户端无法缓存。
• 不要重复设置 key。有些工具会同时读多个环境变量（比如 OPENAIAPIKEY 和 ANTHROPICAPIKEY），如果你只想用一个聚合站的 key，确保这些变量指向同一个值，避免请求被路由到不同的端点。
• base URL 要指向聚合站，而不是官方地址。充值到聚合站账户，但请求发到官方，官方不会认这个余额。
• 如果用了多个 key（比如团队里不同人各自一个 key），充值只能充到对应账户。A 的 key 不会因为 B 充值而受益。

余额不足时会发生什么

不同站点的处理方式不同，但常见的有：

• 请求直接返回 4xx 错误，提示余额不足。
• 请求被排队，直到余额恢复。
• 流式响应中途断开。
• 账户进入“只读”状态，无法发起新请求，直到充值。

这些都不影响 key 的有效性。充值后，key 立刻恢复可用，不需要轮换或重新生成。

实操建议

• 提前充值：如果你知道接下来会跑大批量任务，先确保余额足够覆盖预计用量，避免请求执行到一半余额耗尽。
• 监控余额：很多聚合站提供余额查询接口或控制台，可以定期检查。如果客户端支持，可以在请求前检查余额。
• 不要频繁轮换 key：轮换 key 会导致所有客户端需要更新配置，增加出错概率。加余额不需要轮换 key。
• 流式请求留余量：流式请求持续时间长，扣费在最后，建议余额留出比预估用量更多的余量。
• 客户端重试策略：如果遇到余额不足错误，不要无限重试，应该先充值再重试。

关于扣费比例

聚合站按官方价 ×1.3 扣费，贡献 key 按官方价 ×1.1（优质 ×1.2）返 USDC。这意味着你的实际成本取决于你是纯消费者还是也贡献 key。充值只是增加余额，不改变扣费比例。

总结

加余额不会让 key 失效，也不会打断正在跑的请求。关键在于确保请求发起时余额充足，并在流式请求中留出余量。客户端环境变量不需要因为充值而改动，只需要确保 base URL 和 key 指向正确的聚合站账户。