request quota exhausted 怎么恢复：DeepSeek Harness 配额耗尽、等待与切换模型

request quota exhausted 只说明「这一条被配额拦下了」，没说明配额来自哪一层。 账号额度、上游速率、插件并发，三层的恢复方式完全不同。

三层配额，先分清

同一个提示，可能来自三个地方。

账号额度是「总量」。 用完需要充值或等周期重置；等待几分钟通常无效。

上游速率是「频率」。 短时间请求太多会被拦，窗口过去自动恢复；降频比等待更有效。

插件并发是「本地限制」。 有的插件或网关会限制同时请求数；表现为高峰期失败、低峰期正常。

先做三个对照

不急着重试，先做三个单变量对照。

1. 换模型： 换一个模型再发，仍报错偏账号或全局；只有原模型报错偏该通道。
2. 换通道： 换提供方或插件实例，能通说明原通道受限。
3. 换时间： 隔一分钟再试，能通偏速率限制；仍不通偏额度耗尽。

三个对照做完，层基本就定了。 只重试不换变量，永远不知道是频率还是额度。

记录对照结果。 哪个模型、哪个通道、什么时间，三样齐全才能复现。

恢复顺序：从轻到重

按代价排序，先做不改变配置的。

1. 等一个短窗口。 只对速率限制有效；一分钟内两次失败，就不要再等。
2. 降频与降并发。 减少同时请求，拉长间隔；团队与子代理任务尤其明显。
3. 切换模型。 换一个额度充足的模型；注意上下文窗口差异。
4. 切换提供方或通道。 官方、第三方网关、本地模型之间切换；确认配置与鉴权。
5. 充值或等额度重置。 账号额度问题只能这样解决。

不要一上来就切换提供方。 配置差异会引入新变量；先确认是配额问题，再换。

切换后新开一轮验证。 旧会话可能仍持有旧模型引用，继续发消息不一定走新通道。

等待无效的三种情况

三种情况等多久都没用，应该直接换方案。

1. 额度已耗尽且没有重置时间。 等待不会产生新额度。
2. 账号被限制并发或总量。 需要改配置或换账号体系，不是时间问题。
3. 插件自身限流写死。 只能改插件配置或换实现。

判断方法是看错误里有没有时间信息。 有重试时间，偏速率；没有，偏额度或配置。

等待的成本要算。 长任务卡在等待上，不如提前准备备用通道。

切换模型：注意上下文

切换模型能绕过配额，但会带来上下文差异。

1. 先保存关键结论与未完成事项。
2. 查看目标模型的上下文窗口，长会话可能被压缩。
3. 新开一轮，带上必要背景，而不是直接续旧会话。
4. 验证工具调用与结构化输出是否兼容。
5. 记录切换原因，方便恢复原通道后对照。

窗口不同，行为就不同。 大窗口模型换小窗口模型，早前内容会被压缩；不要假设切换后完全一致。

能力差异也会影响插件。 视觉、工具调用与 JSON 输出支持程度不同；切换后先跑最小功能。

预防：把配额当资源管理

配额问题可以提前发现，代价是日常多看一眼。

1. 监控用量： 用余额或用量类插件，设置阈值提醒。
2. 控制并发： 团队与子代理设置上限，不要一次拉满。
3. 准备备用通道： 至少一个可切换的模型或提供方。
4. 错峰执行： 批量任务避开高峰，减少速率限制。
5. 记录失败时间： 找出高发时段，调整调度。

配额是资源，不是故障。 把它当容量规划的一部分，比临时救火有效。

下一步

先分层，再对照，最后换通道。 想看错误分类与传输问题的区别，看《本轮运行失败 transport failed》；想看密钥与模型发现错误，看《API 密钥无效与模型发现 404》；想看余额与用量监控，看《DeepSeek Harness 余额插件有哪些》。

来源：DeepSeek Harness 官方文档、dsh CLI README、deepseek-harness 仓库