遇到 OpenAI API 余额不足，不宜马上反复重试或大额充值。调用失败可能涉及可用额度、项目预算、请求限速，也可能来自中转账户或上游渠道。先分清故障层级，再用小额、低并发测试验证，才能避免把计费问题误判为服务不稳定。
先确认：余额不足，还是请求被限流？
HTTP 429 不等于余额不足。它可能对应速率限制，也可能与配额耗尽有关，应结合响应正文中的错误类型、错误码、提示信息及请求 ID 判断。若出现 insufficient_quota 等提示，应检查实际调用账户的额度与计费状态；若提示 rate limit，则重点核对请求频率和 Token 吞吐限制。
- 确认 API Key 所属组织、项目与当前检查的计费账户是否一致。
- 查看可用余额、用量记录、预算设置及相关限制，不要仅凭单个页面数字判断。
- 核对请求的 base_url：直连官方接口与经过中转平台，可能使用不同的余额体系。
- 保存脱敏后的错误响应和发生时间，排查时不要发送完整 API Key。
聊天产品订阅与 API 计费通常属于不同体系，不应把订阅权益直接视为 API 余额。具体额度、扣费和充值生效情况，应以对应账户后台及当前计费说明为准。
低风险恢复：先做一笔可核对的调用
确认需要补充额度后，优先采用可承受的小额验证方式；如果平台不支持合适的测试金额，可先咨询计费与退款条件。不要为了排错同时更换 Key、模型和网关，否则难以定位是哪一步恢复了服务。
固定模型、短输入、限制输出，发送一次无敏感信息的测试请求。记录状态码、耗时、返回用量和账户扣费变化。测试通过后，再逐步恢复业务流量。对于明确的额度不足错误，持续自动重试通常无法解决问题；应暂停相关任务并触发余额告警，避免积压请求集中释放。
评估 API 中转稳定性与并发，不能只看能否返回
如果业务通过 API 中转接入，应分别核查平台账户余额与上游错误。平台有余额并不意味着每条上游线路都正常；一次调用成功，也不足以证明高峰期可用。评估时应关注错误是否透明、用量是否可查，以及支持人员能否根据请求 ID 定位问题。
- 先以单并发运行短请求，观察成功率、首个输出耗时与完整响应耗时。
- 在预算允许且符合服务限制的前提下，分档增加并发，每档保持相同请求规模。
- 统计超时、429、5xx 和扣费记录，区分请求数限制与 Token 吞吐瓶颈。
- 达到预设费用、错误率或延迟阈值就停止，不以压满额度作为测试目标。
并发能力不等于每分钟请求数。长输出、长上下文和流式连接都会影响资源占用，因此应使用接近真实业务的输入长度测试。对可重试的限流与临时错误，可采用有上限的指数退避；涉及写入或付费动作的任务，还需防止重复执行。
采购额度或 Token 批发前，先核对账单口径
在 openmagic.ai 规划模型接入与 API 中转方案时，建议先整理模型、峰值并发、日均用量和预算，再核对输入输出计费、失败请求处理、用量明细及告警方式。不要只比较展示单价，还要评估异常排查成本与迁移成本。
最终以小额验证、账单可追踪、故障可定位作为恢复调用和扩大采购的依据。余额告警、预算阈值与限流策略应一起配置，避免一次额度耗尽演变成整条业务链路中断。