线上跑着跑着突然报额度不足，最怕的不是花钱，而是不知道现在到底能不能继续调、该先充值还是先换通道。这篇按「先确认状态、再选恢复路径、最后做防复发」的顺序，把额度用尽后的可选动作讲清楚，每一步都告诉你去看站内哪个页面核对当时的数字。
线上跑着跑着突然报额度不足，第一反应往往是慌：现在到底还能不能继续调？该先充值，还是先换条通道？其实这个问题没有统一答案，得先看你遇到的是哪一种「用完」。四种情况的处理动作完全不同，混在一起想只会浪费时间。
下面按「先确认状态、再选恢复路径、最后做防复发」的顺序讲，每一步都告诉你该去站内哪个页面核对当时的数字。全文只给判断标准和动作，具体金额、模型版本这些一律以你打开页面那一刻的显示为准。
先分清是哪一种「额度用完」
报错串长得都很像，但背后至少是四种状态。先定位是哪一种，再决定动作，比直接充值有效得多。很多人一看到额度不足就去充钱，结果发现是单个 key 的限额打满，账户里其实还有余额。
| 状态类型 | 典型表现 | 先看哪里 |
|---|---|---|
| 账户余额耗尽 | 整个账号下所有 key 都开始报错 | 站内 /usage 的账户级用量 |
| 单 key 限额打满 | 只有某一个 key 或某一个服务报错 | 该 key 的独立用量记录 |
| 赠送额度到期 | 之前一直能用，某个时间点后突然停了 | 后台的额度类型与有效期 |
| 平台侧限流 | 时好时坏，重试偶尔能通 | 站内 /ai-status 的异常公告 |
判断是不是软限制也很关键。有些平台余额为零后仍保留只读或低速通道，你的请求不会完全失败；有些则直接拒答。这个差异没法靠猜，只能看你所接厂商当期的口径说明，到 /official-api/providers 对一下。
从报错原文和后台页面对上号
最省事的办法是把报错原样复制去搜，重点看关键字：insufficient quota、rate limit、key 失效，这三种的动作完全不一样。前者是钱的问题，中间是频率的问题，后者是凭证的问题。搞错方向，充再多钱也没用。
- 第一步：看账户级打开 /usage，确认整个账号的余额和消耗曲线，先排除是不是系统性的余额问题。
- 第二步：看 key 级如果账户正常，再查具体那个 key 的限额和使用记录，确定是不是被单独打满。
- 第三步：看平台状态到 /ai-status 和 /price-watch 看一下当天是否有异常或调价公告，别把平台故障当成自己欠费。
- 第四步：看单次请求最后再排除是不是这一次塞的上下文太长导致被拒，这种情况跟额度其实没关系。
排查顺序建议固定成「账户级 → key 级 → 平台状态 → 单次请求」，每次都按这个顺序走，能省掉大量来回试错的时间。什么情况下不适用：如果你用的是自建或私有化部署，平台状态那一环要换成你们自己的服务监控。
额度用完了到底还能不能继续调
先给结论：能不能继续调，取决于你手上有没有「另外的路」。只有三类情况还能继续跑——还有未到期的赠送额度、有后备 key 或备用账号、愿意临时切到别的厂商或中转通道。除此之外，基本就是停机等恢复。
- 能继续的前提一：账户里还有未到期的赠送额度，需要先去后台确认有效期
- 能继续的前提二：项目里配了备用 key 或备用账号，能直接切换
- 能继续的前提三：愿意临时切到别的厂商或中转通道，代价是改配置和验证
- 不能继续的典型情况：账户余额为负、key 被平台禁用、套餐到期且未续费
- 灰色地带：部分平台保留只读或低速通道，能否用只能实测，不能靠猜
有个动作一定要忍住：不要在余额为零时反复重试同一个请求。高频失败重试可能触发风控，反而让账号状态更麻烦。想确认通道是不是还活着，用 /tools/verify 这类检测入口更划算，也更省请求。
四条恢复路径，按代价从小到大排
恢复不一定等于充值。把可选路径按代价排一下，你会发现很多时候有更轻的做法。下面四条从轻到重，能走前面就别急着走后面。
| 路径 | 适合场景 | 主要代价 |
|---|---|---|
| 等额度重置 | 非紧急、能停机到下一个周期 | 服务中断时间 |
| 充值或升级套餐 | 主业务不能停、用量可预测 | 直接成本上升 |
| 切备用 key 或厂商 | 有现成备用资源、能改配置 | 改配置与验证成本 |
| 降级模型或拆任务 | 临时救急、质量可暂时放宽 | 效果可能打折 |
走充值这条路时，到 /plans 和 /official-api 对照当期口径再决定，别凭记忆里的数字下单。价格和套餐内容会变，记忆里的那个数不一定还成立。
走切换这条路时，到 /ai-nav/category/ai-api 和 /providers 找可对接的替代入口。临时降级则是把任务拆小、换更便宜的档位先跑通，等额度补上再切回来。
切换通道的检查清单
切换通道最容易出问题的不是切不过去，而是切过去之后才发现能力不够或者账单翻倍。下面这份清单照着过一遍，能挡掉大部分返工。
- 能力覆盖：新通道是否支持长上下文、函数调用、结构化输出这几项，缺一项就可能要改代码
- 计费单位：按 token、按次还是按秒，单位不一致预算容易失控
- 接口改动：鉴权方式和 base_url 是否要改，改完先用一条最小请求验证
- 重试策略：切换期间的重试可能造成两份账单，事后到 /usage 核对
- 回滚方案：出问题时能不能一键切回原通道，别把自己堵死
切换完成不等于结束，最好在事后一到两天再到 /usage 看一次实际消耗，确认没有出现双份计费或者异常峰值。什么情况下不适用：纯离线批处理任务对实时性不敏感，可以放宽验证节奏。
下次别再被同一件事卡住
这次恢复之后，花十分钟把防复发做掉，比下次再慌一次划算得多。核心就三件事：有告警、有备胎、有节奏。
- 预算告警
- 给主账号设用量或预算提醒，具体阈值到 /usage 与厂商后台按当期规则配
- 备用通道
- 至少准备一条，写进项目配置而不是存在某个人本地
- 重置周期
- 把额度重置时间记进团队日历，到 /resets 看各家的重置节奏做参考
- 用量记录
- 高频任务留用量日志，别只记总花费，要能拆到任务维度
这里补一句：备用通道不要只在文档里写一句「可切到某某」，要实际验证过至少一次，否则真出事时你会发现配置早就失效了。
恢复之后顺手把成本压下来
额度用完往往说明用量在涨，这其实是复盘成本的好时机。不用做得很复杂，先把「必须的调用」和「顺手发的调用」分开看，重复请求通常占大头。
- 先分辨哪些调用是必须的、哪些是调试或重复请求，重复请求往往占大头
- 给不同任务配不同档位的模型，贵的那档只留给真正需要的环节
- 长上下文任务改成先检索再回答，减少一次性塞进去的内容量
- 降本动作留出效果验证窗口，别一上来全站切换，容易把质量一起降下去
降本的效果不要凭感觉判断，定一个观察周期，对比切换前后的用量数据。数据从哪看？还是 /usage 和 /price-watch。具体压下来多少，以你打开页面时的实际数字为准。
下一步把上面这套排查顺序走一遍，再去站内把备用通道和告警配好，下次遇到同样的问题就不用现查了。→常见问题
API额度用完了还能继续调用吗？
看额度类型。如果是赠送额度到期或套餐内周期额度用完，通常就只能等重置或充值；如果只是某个 key 的限额打满，换一个 key 往往还能继续。先看报错原文和控制台里的额度构成，再去站内用量页确认真实消耗，别用重试去试。
余额为负会被立刻停服吗？
多数平台是在余额不足以支撑下一次调用时开始拒答，不会因为你负了一点点就立刻清空数据，但具体行为各家不同。稳妥做法是发现余额见底就先充值或切备用通道，不要等着跑完再处理，避免任务跑到一半中断。
免费额度用完之后会自动扣费吗？
不一定，取决于你开通的是哪种计费和有没有绑卡。有的平台免费额度用完直接停，有的会走账户余额，还有的会转成按量计费。这个口径各家差异大，建议在你所用厂商的官方页面和控制台里确认，别靠猜。
能不能靠删除历史对话或重建账号恢复额度？
周期性的套餐额度一般跟账号走，删除对话不会让额度回来；重建账号又涉及数据迁移和合规问题，成本比充值高。更实际的做法是先查清楚额度是按周期重置还是按量累加，再决定等还是充。
怎么设置才不会再被额度卡住？
三件事：设预算告警、留一条备用通道、把重置周期记进日程。告警阈值按你的日均消耗来定，不要照抄别人的数字；备用通道要提前测通，不要等出事当天才试。
