api key 额度不足 请检查账户

半夜跑批任务，接口突然回一句「额度不足 请检查账户」，第一反应往往是去充值。但这类报错经常跟余额没关系：可能是 Key 绑错了项目、免费额度到期、限速被拒、或者账单欠费没结清。这篇给一套从外到内的排查顺序，让你先定位再动手，少花冤枉钱。

半夜跑批任务，接口突然回一句「额度不足 请检查账户」，第一反应往往是去充值。但这类报错经常跟余额没关系：可能是 Key 绑错了项目、免费额度到期、限速被拒，或者账单欠费没结清。先定位再动手，能少花冤枉钱。

下面按「先看报错原文 → 账户层 → Key 层 → 动手清单」的顺序走一遍。每一层都给判断标准，什么情况说明不适用也写清楚。数据类的东西一律不写死，让你自己去站内页面核对当时的数字。

先分清报错是「没钱」还是「没权限」

同一个提示文案，在不同平台的真实含义可能完全不同。有的平台把「Key 无权访问该模型」也归到额度不足里，有的把限速拒绝也塞进同一个错误码。所以第一步不是充值，是搞清楚这句话背后到底是哪一类失败。

• 把 HTTP 状态码和错误码字段一起记下来，别只截一句中文提示。
• 同一段文案在不同平台含义不同，去 /ai-dict/category/infra 把限速、配额、并发这几个词的真实口径对一遍。
• 记录报错原文和发生时间，后面查账单要对时间点。
• 不确定是哪一类时，先用最小请求打一次，也就是单轮、短提示词，排除是长上下文触发的额度校验。

账户层：余额、免费额度与账单状态

确认完报错类型，再往账户看。这里最容易踩的坑是：以为「有余额就不会报额度不足」，但实际计费里有预扣、结算、免费额度周期这些中间状态，任何一环卡住都可能拒绝请求。

• 分清当前消耗的是免费额度还是充值余额，两者的耗尽表现不一样，扣费先后顺序看 /ai-api-free-quota-guide 里的结论。
• 查有没有未支付账单，或者预扣了但还没结算的金额，预扣和结算的差别参考 /api-precharge-vs-settlement。
• 团队账号要确认是主账号有余额、而子 Key 归属的项目没有预算，这种情况充值到主账号也未必生效。
• 免费额度可能按周期重置，重置节奏去 /resets 看当时的记录，别凭记忆判断。

什么情况下这一层不适用？如果换成另一个 Key、另一个模型同样报错，基本可以跳过 Key 层，重点放在账户和账单上。反过来，如果只有某一个 Key 报错，账户层大概率是清白的。

Key 层：绑定、权限与用量归属

账户有钱，不代表这个 Key 能花。很多平台把「额度」和「模型权限」做成两个独立开关，权限没开，请求一样被拒，报错文案还可能跟余额不足长得一模一样。

项目绑定

Key 属于哪个项目，项目的预算和账户余额是两回事。

模型白名单

这个 Key 允许调哪些模型，通常是独立开关。

Key 状态

轮换或停用后的旧 Key 继续调用会直接报错，不会走扣费流程。

用量归属

一个账号下多个 Key 共用总额度，别只看当前 Key 的用量页。

1. 换 Key 打一次用同一账号下另一个 Key 发同样的请求，如果成功，问题就在原 Key 的绑定或权限。
2. 核对模型权限把报错里请求的模型名和该 Key 的可用模型列表对一遍，名字对不上也会报类似错误。
3. 核对用量归属用 /usage 的字段口径去核对自家日志，别只看平台汇总数，确认到底是谁在消耗额度。

排查顺序清单：从五分钟能确认的开始

把上面的排查压成一条行动线，从成本最低、最快出结果的动作开始，避免一上来就充钱或者重配环境。

1. 换模型或换 Key 打一次判断是账号级问题还是单 Key 问题，这一步一分钟内能出结论。
2. 看账单页确认有没有欠费、预扣未结算、或者异常大额消费，对时间戳看。
3. 判断是不是限速短时间请求过密会被拒，限速和计费的边界参考 /retry-billing-limits，看清楚再决定要不要退避重试。
4. 确认计费口径有没有变以上都正常，再去 /price-watch 和 /official-api 核对当时的单价与计费规则，别默认就是余额不够。

额度不足这四个字，一半时候说的是钱，另一半说的是权限和节奏。