额度当天就用完了：把手上任务重排，别让一整天停工

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

**额度当天用完导致停工，八成不是额度不够，而是你把当天所有任务都默认交给了最强的那个模型。**真正的损失也不在被中断的那一次调用上，而在你接下来两小时里的反应：反复重试、换账号、翻配置、找中转，一圈折腾完发现手上还有五六件根本不需要强模型的活儿一直没动。额度是外部约束，你能控的只有任务排序和降级路径。

站内已经有三篇分别讲单个产品的额度机制怎么算、怎么看用量、什么行为最烧额度，分别是 Claude Code 额度用完了怎么办、Cursor 额度用完了怎么办 和 Copilot 额度用完了怎么办；如果你要做的是系统层面的自动切换，那属于 多模型回退怎么设计 的范围。这篇不重复这些，只讲一件事：额度已经没了、今天必须继续干活，接下来一小时你按什么顺序做判断和动作。

一、先分因：额度用尽和它的四个冒充者

工具界面提示额度已用尽，这句话本身不可靠。很多时候你看到的是同一个入口对多种失败的统一兜底文案，真实原因可能完全不同。在动手做任何降级之前，花五分钟分清成因，比直接换工具划算得多。

需要分开的至少有五种情况：

一是真的用尽。周期内可用量确实归零。各家的计量口径、重置节奏、是否区分模型档位都不一样，规则也会调整，以官方最新说明为准。特征是换网络、换项目、换请求内容都没用。这里要再分一层：如果这家服务是按模型档位分别计量的，高档位归零后降档往往还能继续工作；如果它是所有模型共用一个池子，那降档只是让每次消耗变小，池子空了就是全线不通。搞不清自己用的是哪种，就用一条最小请求在低档模型上试一下，一次就试出来了——这一层没分清，你会在”为什么换了便宜模型还是不行”上白耗时间，以为是自己配置写错了。

二是短窗限流。你在极短时间里打出大量请求（多开几个会话、跑了批处理、循环重试没加退避），触发的是速率限制而不是总量耗尽。特征是等几分钟自己就好了，直连 API 时通常看到 HTTP 429。

三是鉴权失效。密钥过期、被轮换、组织权限变更、订阅状态没同步。直连 API 时通常是 401 或 403，而不是 429。这类最容易被误判成额度问题，因为很多客户端把两者的提示文案写成了一样的。

四是网络与证书。公司代理、DDoS 防护、TLS 中间设备都可能让请求根本没到服务端。特征是错误里带 ETIMEDOUT、ECONNRESET，或出现证书链校验失败——后者常见于代理做了 TLS 解密而它的根证书没进你的信任库，报错讲的是自签证书不受信任，跟额度毫无关系。这几个大写错误码来自 Node 运行时，所以你在编辑器插件、桌面客户端的日志里看到的是这个形态；同一个故障用 curl 复现时，文案会变成连接超时、连接被对端重置、证书验证失败这类描述，别因为字面不一样就以为是两回事。判断依据是有没有拿到 HTTP 状态行：拿不到状态行，说明请求压根没走完到服务端这一段，任何跟额度有关的推测都是无根据的。

五是区域限制。几家主流的海外编程工具与模型服务，官方对中国大陆有区域限制、不支持直连，账号归属、支付方式、出口网络任一环节变化都可能让原本能用的路径突然不通。市面上确实存在第三方中转服务，稳定性、合规性和数据流向都由对方决定，我不推荐也不给具体渠道，只提醒一句：把这类通道当成生产依赖，等于把停工风险外包给一个你无法追责的对象。

判别表

现象	大概率成因	怎么验证	处置动作
客户端提示额度已用尽，直连 API 报 429，停手几分钟后同一条最小请求能通	短窗限流，不是总量耗尽	停手三到五分钟再发一条最小请求，通了就是限流；同时查有没有循环重试或多会话并发在偷偷打请求	加指数退避、把并发降到 1，继续原计划
直连 API 报 429，但停手十分钟后同一条最小请求还是 429，响应体也不指向请求过密	周期配额归零，不是限流	隔十分钟再试一次最小请求确认不是抖动；换低档模型跑同一条请求	走本文第三节的降级路径，重试没有意义
直连 API 报 401 或 403	鉴权或权限问题	用一条最小请求单独试密钥，见下方命令	换新密钥或修组织权限，不要去买额度
报错含 ETIMEDOUT / ECONNRESET，或提示证书链校验失败	网络、代理、TLS 拦截	检查代理环境变量；在同一台机器上换网络重试	修代理与信任库配置，别改模型
换网络、换项目、换内容都一样，降到便宜档位后可用	高档位额度确实用尽	对同一请求换低档模型跑一次	走本文第三节的降级路径
昨天能用今天全不通，且同事在别的网络能用	区域或账号状态变化	对比出口网络与账号归属地	切换到本地可用的国内服务，别在通道上耗时间
只有某个大文件或某个长会话失败，其他请求正常	单次请求过大，被上下文或单请求限制挡住	换一个短请求验证同一模型	拆任务、清会话，见第五节

验证鉴权用最小请求，不要拿真实业务请求去试，那样分不清是内容问题还是密钥问题：

export API_BASE="https://你的端点域名"
export API_KEY="你的密钥"
export MODEL_ID="你要试的模型 id"

curl -i -X POST "$API_BASE/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"$MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"ping\"}],\"max_tokens\":8}"

这里把端点和模型放进环境变量，不是为了好看：占位符如果直接写成尖括号形式贴进终端，shell 会把它当成重定向符号，你收到的会是一个跟接口毫无关系的本地报错，白白多绕一圈。路径按 OpenAI 兼容格式写，如果你用的服务不是这个风格，请求路径和参数名以它自己的官方说明为准。

-i 会把状态行、响应头和响应体一起打出来。第一件事是看状态行是 429、401 还是 200；第二件事同样重要——429 不能直接读成”限流”。同一个 429 在不同服务里既可能表示单位时间请求过密，也可能表示周期配额已经归零，两者在响应体里给的错误类型不是同一个，具体字段名和取值以对应服务的官方最新说明为准。所以真正能定性的是状态码加响应体两层信息：状态码告诉你被谁挡了，响应体告诉你等一等有没有用。

顺手确认一下代理是不是在捣鬼：

env | grep -i proxy

grep -i proxy 会同时命中 http_proxy、HTTPS_PROXY、no_proxy 这些变量，大小写都覆盖到。没有任何输出是正常结果，说明当前 shell 没设代理——注意这只代表这个 shell，编辑器和桌面客户端可能有自己的代理设置，它们不读你终端里的环境变量。

关于 429 的处理细节，DeepSeek API 429 限流 那篇给了退避和并发控制的具体写法，这里不重复。

二、把当天任务按需不需要强模型重排

分因结束、确认是真用完之后，第一个动作不是找替代品，而是重排任务。原因很实在：你手上的活儿里，大概只有一小部分离不开最强的那个模型，其余的用中低档模型、甚至根本不用模型都能推进。停工感来自你把它们混在一个队列里。

我一般把当天任务分成四档，纸上花三分钟排完：

**A 档，必须强模型。**需要跨多个文件建立因果链、需要读懂一段你自己也没看明白的历史代码、需要在模糊需求上做设计判断。比如重构一个纠缠的模块、排查跨服务的偶发故障。这类活用弱模型做，产出看着像样但埋雷，返工成本远高于等一等。

**B 档，中档模型够用。**边界清晰、输入输出明确：写单元测试、补类型定义、按现成模式加一个接口、按报错定位一处明显的类型错误。验收标准是机器可判的，模型弱一点你也能立刻发现问题。

**C 档，不需要模型。**这一档常被严重低估。手动改配置、跑一遍完整回归、把昨天堆着的分支合掉、读别人的 PR、把上周那个临时方案的技术债记录下来。额度耗尽的时段正是干这些的最佳窗口，因为它们平时总被”顺手让 AI 做”挤掉。

**D 档，能推到明天。**没有外部依赖、也不卡别人。判断标准只有一个：推迟一天有没有人被卡住。没有就推，别为了清空列表去用不合适的模型硬做。

当天节奏于是清楚了：先把 C 档做掉，它完全不受额度影响，做完你已经有实质进展；同时 B 档挂在中低档模型上跑；A 档留到额度恢复，或按下一节的路径谨慎降级。

有个反直觉的点：**A 档任务在额度紧张时最该做的是写清上下文，而不是急着开跑。**把问题背景、相关文件路径、已排除的可能、期望的产出形式整理成一段说明，恢复后一次到位地问，比反复试探省得多。这件事本身属于 C 档，不花额度。

三、四条降级路径和它们各自的代价

A 档任务实在等不了，就得降级。可选的路径不多，关键是清楚每条的代价，别拿一个坏结果换另一个坏结果。

**路径一：同一工具内降档。**多数编程工具允许在会话里换用更便宜的档位。代价是能力落差，尤其在跨文件推理和长链条排查上。适用条件是任务能拆细：把一个大问题手工拆成若干边界清晰的小问题，弱模型做每一个都胜任，你自己承担串起来的判断。这个拆分不是纯将就——很多时候拆完你会发现问题本来没那么复杂。

**路径二：换到国内可直连的服务。**如果你自己调 API、或用支持自定义端点的客户端，切到国内服务是最稳的一条路，不用担心区域限制和支付通道。代价是指令习惯和输出风格要重新适配，同一段指令在不同模型上的差异比很多人预期的大，尤其是长指令遵循和结构化输出。所以这条路要提前试，不要留到断供当天第一次试。

**路径三：把 AI 从回路里摘出去，人工顶上。**听起来像退步，对某些任务却是最快的。比如你已经知道该改哪三行，只是习惯性想让模型确认一下；或者要写的是模式化样板代码，照同项目既有实现抄一遍更快。代价是手感和速度，收益是零不确定性。

**路径四：换任务不换工具。**承认这个任务今天做不了，把时间给别的。这条经常是最优解，但最少被选，因为它看起来像放弃。

选择顺序我的判断是：先看任务能不能拆（能拆走一），拆不动看有没有现成可用的国内端点（走二），都不行就问自己”不用模型我会做吗”（会就走三），还是不行说明这任务对强模型有真实依赖，走四推到明天。

一个提醒：路径一和二都涉及换模型，**换模型之后验收标准不能跟着放松。**弱模型给的代码更需要跑测试、更需要读一遍 diff。换完就跳过检查，降级的隐性成本会在两周后以 bug 的形式还给你。

四、什么情况下别再折腾

额度问题最大的时间黑洞不是等待，是不肯认。下面几个信号出现，就该停手换路。

**同一个错误重试超过三次，且错误信息没有任何变化。**重试对短窗限流有效，对总量耗尽和鉴权失效完全无效。第三次还是同样的报错，说明成因判断错了，回到第一节重新分因。

**你开始动生产配置。**为了绕开额度去改线上环境变量、临时关掉某个校验、把密钥硬编码进代码里”先跑通再说”，这是明确的止损点。这类临时改动的回滚率极低，绝大多数会留下来变成事故的引信。

**你开始考虑注册第二个账号绕限制。**多账号是否违反服务条款、会不会牵连主账号，风险不由你决定、后果全由你承担。团队场景更麻烦，一旦形成事实依赖，想改回来会牵扯到别人。

**你在找中转通道，且已经超过二十分钟。**找通道的时间成本确定、收益不确定，找到之后还要评估数据流向和稳定性。二十分钟没结果，说明这条路今天不通。

**任何一个动作，你想不清楚出问题怎么退回去。**这是通用止损标准，比上面几条都重要。改配置前先确认能回滚，改代码前先确认工作区是干净的：

git status --short      # 有没有未提交的改动，一行一个文件
git diff --stat         # 改了哪些文件、各改了多少行
git stash list          # 之前有没有暂存过东西，别覆盖掉自己

git status --short 什么都不输出，才叫工作区干净。如果你在额度耗尽的焦虑里连着改了好几处试探性的代码，它一定不是空的。这时候不要继续叠加改动，先把这些试探性修改带说明单独收起来：

git stash push -m "额度中断期间的试探性改动"

带 -m 是为了半天后你还认得出这是什么。要注意 git stash push 默认不带走未跟踪的新文件，如果你这段时间新建了文件，要么先 git add 让它进入跟踪，要么加 -u 一起收走，否则你以为清干净了，实际上新文件还留在工作区里继续干扰你判断。真出现冲突标记 <<<<<<<、=======、>>>>>>> 残留在文件里，先解决冲突再谈别的，带着冲突标记提交是这类混乱时段的高发事故。

五、避坑清单

**坑一：把限流当额度用尽，直接去加购。**为什么会踩：客户端把 429 和额度归零显示成同一句话，你看不到状态码。怎么避：额度类问题一律先用一条最小请求直连验证状态码，看到 429 先看响应体、再等几分钟复测一次，别在提示文案上做决策。反过来同样要防：把配额归零当成限流，然后守在那里等一个永远不会自己好的东西，一下午就这么没了。区分方法只有一个，等待之后复测同一条最小请求，通了是限流，不通就别再等。

**坑二：无退避的自动重试把额度真的烧光了。**为什么会踩：很多脚本和插件的默认重试是立即重试固定次数，你自己再手动点几下，短窗内请求量瞬间放大，本来只是限流，重试完变成真的耗尽。怎么避：任何重试都必须带指数退避和上限，并发降到 1；出错时先停手看一眼日志，而不是继续点。

**坑三：换了模型没换验收方式。**为什么会踩：降档之后你的操作习惯没变，还是扫一眼就采纳。怎么避：把降级和”必须跑测试、必须读完整 diff”绑定成一条规则，写进项目约定里，而不是靠当时的自觉。

**坑四：会话越长越烧，还以为是模型变笨了。**为什么会踩：长会话每一轮都要带着历史上下文，用量随轮次累积，同时早期无关内容还会干扰判断，表现出来就是”越聊越不准还越费”。怎么避：一个任务一个新会话，任务切换就重开；长排查过程中定期把已确认的结论手工摘出来，作为新会话的起点。

**坑五：把中转通道当成生产依赖。**为什么会踩：临时用一次觉得挺好，就写进了脚本和 CI，之后所有人都在用。怎么避：临时方案必须留标记和时限，在配置里写明这是临时端点、计划什么时候撤掉，并在技术债记录里挂一条。

**坑六：断供当天才第一次试备用路径。**为什么会踩：备用配置配好之后从来没跑过，你以为它可用。怎么避：每次有新的备用端点或模型，当天就用一个真实任务跑通一遍；这事花不了几分钟，但它决定断供那天你是有路可走还是原地打转。

**坑七：把额度耗尽当成个人效率问题，闷着解决。**为什么会踩：不想显得依赖工具。怎么避：共享额度池下，谁在什么时段跑了什么应该可见，否则今天是你、明天是别人，反复踩同一个坑。在群里说一句”高档位今天没了，我先做别的”，比默默耗一下午有用。

收束

额度耗尽这件事，你控不了外部规则，能控的是三件：分因的速度、任务重排的果断、以及降级路径有没有提前验证过。前两件靠习惯，第三件靠平时。

断供当天，按这份清单走一遍：

• 直连一条最小请求，确认状态码是 429、401 还是 200，别看客户端文案；拿到 429 再看响应体，分清是请求过密还是配额归零；
• 排除代理与证书问题，确认失败真的发生在服务端；
• 把当天任务分成必须强模型、中档够用、不用模型、能推到明天四档；
• 先做不用模型那一档，同时把中档任务挂上便宜模型；
• 强模型任务只做两件事：整理上下文、评估能不能拆；
• 检查工作区是否干净，任何试探性改动单独收起来；
• 出现改生产配置、注册小号、找通道超时这三个信号，立刻停手。

平时留一件事就够了：给自己准备一条已经跑通过的备用路径，并且每个月真实用一次。它的价值不在省钱，在于让断供从事故降级成一次任务重排。