额度限制了怎么办

正干着活突然弹一句额度受限、请求被拒，很多人第一反应是充钱，结果充完还是被卡。额度这件事至少有四种完全不同的来源：订阅套餐的周期上限、按量的速率与并发限制、免费额度用完、账户余额为负。这篇给一套按顺序排查的方法，让你先定位到底卡在哪一层，再决定是等刷新、升级档位、还是把这条调用挪到 API 上，不花冤枉钱。

正干着活突然弹一句额度受限、请求被拒，很多人的第一反应是充值，结果钱花出去了还是被卡住。原因很简单：额度这件事至少有四种完全不同的来源，而报错文案往往长得差不多。订阅套餐的周期上限、按量调用的速率与并发限制、免费额度用完、账户余额为负，这四种卡法对应的处理方式完全不一样。

这篇不讲概念，只给一套按顺序排查的方法。你先定位到底卡在哪一层，再决定是等刷新、升级档位，还是把这条调用挪到 API 上。判断标准会写清楚，同时也会说明什么情况下这套顺序不适用，免得你照着套反而绕远路。

先分清卡你的是哪一层

第一步不是充钱，是分清卡点。最省事的判断顺序：先看是单次请求被拒，还是整段时间里所有请求都不能调；再看是不是所有模型都失败，还是只有某一个模型失败。前者多半是速率或并发问题，后者更可能是套餐额度或余额问题。这两条分清楚，后面的排查能省掉一大半时间。

套餐周期额度

按订阅周期计算的上限，到点或到量后锁住，行为上通常按自然周期重置

速率与并发限制

单位时间内允许的请求数或同时进行的连接数，超了会被短暂拒绝，滚动恢复

免费额度耗尽

试用或赠送部分用完，和付费余额是两套账，充值不一定能立刻解锁免费通道

账户余额为负

欠费或扣款失败导致，修复动作是补账，处理速度最快

• 把报错原文、发生时间、调用的模型名记下来，别凭记忆判断，记忆在这类问题上错得离谱
• 对照发生时间看是否集中在某几分钟，集中在短窗口内多是速率限制
• 换一个模型或换一个渠道试一次，用来区分是账号级限制还是模型级限制
• 如果一个都不通且余额正常，才考虑是平台侧的临时故障，这时候等比折腾有用

去哪看自己到底用了多少

定位完卡点，就要拿到真实用量。订阅类先看套餐页的额度口径，确认上限是按次数、按 token 还是按折算金额，这三者对同一份工作的消耗感受完全不同。按量调用看官方平台的用量与账单页，重点区分输入、输出、缓存三项分别消耗了多少，缓存项经常是被忽略的那一块。

用中转渠道的话，先去站内 /sites 找对应站点，再对照 /rankings 的可信度口径，确认它的额度是按官方折算还是自定倍率。这里有个容易踩的坑：不同站点的倍率口径不一样，你在 A 站看到的余量，不能直接拿来推断 B 站的消耗速度。具体数字到站内页面核对当时的数值，不要照抄别人的截图。

能走的三条路，以及各自代价

确认卡点之后，其实只有三条路：等、升、换。选哪条不取决于哪个听起来划算，取决于你这次卡住的是不是紧急任务，以及超量是不是常态。下面这个顺序建议照着走，它把代价最小的动作排在前面。

1. 先确认刷新规则弄清是自然周期重置还是滚动窗口恢复。滚动窗口的等待时间通常更短，但必须等到具体的时间点，早一分钟都不行。
2. 评估升档是否值持续超量才考虑升级。先把多花的成本和停工时间折算一下，如果停工时间对你的任务没有实际影响，等就是更优解。
3. 把超量调用挪走如果订阅只是被你当成便宜入口用，长任务和批量任务应该走按量 API 或另一个额度更宽的渠道。分开之后订阅里的对话额度就不会被批量任务吃掉。
4. 记录结果把这次是哪种卡点、用了哪条路、恢复了多久记一行。下次再遇到同类报错，直接翻记录，不用重新排查。

不建议的做法是为了绕限额跑去多个小平台分散调用。账面会更难核，出问题时也更难定位到底是谁的问题。价格追踪这类数据可以到 /price-watch 看当时的对比，但要不要铺开渠道，取决于你有没有精力维护这套账。

下次别在同一个地方再卡住

排查和解除只是一次性的，真正省事的是把上限换算成你自己的日均消耗。做法很朴素：拿最近一段时间的用量页记录，除以天数，得到日均值，再给上限留出两到三成余量。具体数字到站内用量页核对当时的数值，别抄别人的经验值，任务结构不一样，抄了也不准。

• 批量任务和交互任务分开走：批量走按量或批量通道，交互留在订阅里，别让长任务吃掉对话额度
• 设一个提醒阈值，在还剩两三成时就收到信号，而不是被硬中断
• 每周固定截一次用量页，比出问题时临时翻记录靠谱得多
• 换模型或换档位前先做一次小样本对照，确认新路径在你这类任务上真的够用
• 站内 /usage 的用量榜可以帮你判断自己的消耗处在什么水平，但只当参考，不当结论

这套方法有个前提：你的用量是可观测的。如果你的任务分布非常随机，今天几乎不动、明天突然爆量，那按日均留余量就不适用，更合适的做法是把爆量的那部分单独拆出来走按量通道，订阅只负责稳定那部分。