干到一半 Codex 提示五小时额度没了，多数人第一反应是升档或充值，其实先要分清是额度真耗尽、还在排队处理，还是短窗口被临时打满。这篇按「先判断、再决定、后复盘」的顺序给一套动作，帮你当天把活干完，也避免为一次卡顿多付一整个月的钱。
干到一半 Codex 提示五小时额度没了，多数人第一反应是升档或充值。其实先花两分钟分清三件事：是短窗口真用满了，是周额度也见底了，还是报错压根跟额度无关。这三种情况的处理方式完全不同，混在一起判断，很容易为了一个下午的卡顿多付一整个月的钱。
这篇按「先判断、再决定、后复盘」的顺序给一套当天就能上手的动作：先确认额度到底卡在哪，再看五小时窗口是怎么被吃掉的，然后列出不等窗口恢复也能继续干活的办法，最后把换路要算的账和几条常见坑讲清楚。目标很朴素——把当天的活干完，别为一次卡顿做长期决定。
先花两分钟确认：是真的耗尽，还是卡在别的环节
额度提示出现时，先别急着掏钱。打开站内的额度查看与重置说明页，把当前用量、刷新节奏和提示原文对上号。同时留意报错文本里有没有鉴权、限流、服务不可用之类的字样：这类属于故障或配置问题，按排查流程走，升档解决不了，反而会把问题掩盖掉。
| 表象 | 大概率原因 | 先做什么 |
|---|---|---|
| 提示五小时额度已满，但当天早些时候还能用 | 短窗口用满，等刷新即可 | 记下提示时间，按站内说明页的刷新节奏推算恢复点 |
| 连续几天都在同一时段卡住 | 整体用量偏高，或有大任务在吃额度 | 翻一遍最近的任务记录，看是不是长上下文任务在拖 |
| 报错带鉴权、密钥、权限字样 | 账号或密钥配置问题 | 按故障排查走，先换密钥或核对权限，不要动套餐 |
| 请求一直转圈或超时 | 网络或服务端波动 | 换网络重试，看站内状态说明，别当成额度问题 |
还有一种容易误判的情况：任务本身太重。长上下文、整仓库全量读取、反复失败重试，都会让短窗口掉得特别快，这是额度机制的正常表现，不是账号出了毛病。判断标准很简单——同样的任务以前跑得动、现在刚开就满，多半是任务变重了，不是额度变少了。
五小时窗口是怎么被吃掉的：三个放大器
想把额度用得更久，得先知道它怎么没的。五小时窗口的消耗不是线性的，有几个放大器会让它掉得比预期快很多。下面这三条是最常见的，对照一下自己最近的任务，基本能找出主因。
- 上下文放大器：对话越长，每一轮都要把前面的内容重新带一遍，多轮下来成本是叠加的，不是相加的
- 工具调用放大器：一次任务里频繁读文件、跑命令、看结果，每个来回都是一次请求，一次任务能变成十几次
- 重试放大器：出错后自动重试，看起来只点了一次，实际在后台连发了好几轮，额度掉得悄无声息
对应的省额度动作也很直接：把大任务拆成小步，每一步只喂必要的文件，别一股脑把整个仓库塞进去；能一次性说清的需求别来回追问；失败重试前先看错误原因，别让它自动重跑。这些动作当天就能见效，比换套餐快得多。
一个简单的自查顺序
- 看提示原文把报错文本抄下来，对照站内说明页的三种表象分类，先确定是哪一类，别凭感觉判断
- 翻最近几个任务找出额度掉得最快的那一个，看它是不是长上下文或高频工具调用，通常一两个任务就能解释大半消耗
- 改一处分法再试只改一个变量，比如把全量读取改成按文件读取，跑一次看消耗有没有明显下降，有效再推广
额度耗尽当天还能做的四件事
确认是短窗口用满之后，当天并不是只能干等。先做不花钱的那几件，再看要不要动预算。顺序很重要：先落盘、再拆分、再考虑换路，最后才看是不是要改套餐。
- 把中间结果落盘已经跑完的部分立刻存成文件或笔记，写清做到哪一步、下一步从哪接。这样窗口恢复后不用从零开始，省下的是下一轮额度
- 能手工补的收尾先手工补剩下的是改几个文件、跑一次格式化这类机械活，手工做完比等窗口快，也避免为小事多付费用
- 把剩余任务切成小碎片按「一个小目标一次提问」切开，每片只带必要上下文，能用更轻的模型就用更轻的模型过一遍
- 临时切到自备 API 通道前提是代码上下文能迁移。配置和习惯重建成本高的时候，不如等窗口恢复，硬换反而更慢
- 到站内重置追踪页看刷新节奏看清当期刷新时间点，判断是等二十分钟还是等半天，再决定要不要换路。数字以页面当时显示的为准
这里有一个判断标准：如果离刷新只剩很短一段时间，等待几乎总是最优解；如果离刷新还有大半天，而你手上是必须今天交付的活，才值得启动换路。反过来，手上只是可做可不做的优化任务，等就是了。
换路之前先算清三笔账
很多人卡在这一步：一着急就升档、就充钱、就换渠道，事后发现多花的钱够用很久。换路本身没问题，问题在于没算账。下面三笔账算完，值不值得换基本就有答案了。
| 要算的账 | 怎么算 | 什么时候不值得 |
|---|---|---|
| 订阅档位差价 | 多付的是整月费用，对照的是你这次卡住损失的时间 | 只是偶发一次卡顿，升档大概率亏 |
| 按量调用成本 | 拿你实际的输入输出量，去站内模型成本计算器和单价换算页代一遍 | 用量说不清、波动很大时，先记一周再算 |
| 迁移成本 | 配置、插件、上下文习惯要重建，估算要花多少时间 | 一天里第二次卡住才划算，第一次卡住就换太早 |
按量成本这块最容易算错，因为账面单价和实际支出能差出一截。缓存命中率高的场景实际更便宜，输入远多于输出的场景又不一样。别拿别人晒的数字套自己，到模型成本计算器按自己的用量代一遍，结果才有意义。
继续靠订阅额度，还是转按量：判断标准
这个选择没有标准答案，但有几个可操作的判断维度。把下面几条对照自己或团队的情况，多数人很快能定位到该走哪条路。
- 用量波动大
- 经常撞短窗口、单日峰值高，按量计费更可控，用多少付多少
- 用量平稳
- 每天都在跑、时长稳定，订阅档位更省心，不用天天盯消耗
- 多人共用一个账号
- 窗口压力会被放大，多人场景应考虑按人或按项目分账，别让一个人拖垮整个窗口
- 涉及代码保密
- 换第三方通道要先过合规这一关，成本不是第一顺位
多人团队还有一个容易忽略的点：共用一个账号时，大家在同一个五小时窗口里抢额度，谁跑了大任务，别人就跟着卡。这不是额度不够，是分配方式的问题。按项目拆账号、或者把重任务固定安排在固定时段，往往比直接升档更有效。
避坑要点：这几件事别做
额度耗尽的时候人容易急躁，急躁时做的决定多半要返工。下面几条是踩过坑的人反复提到的，照着避开能省不少事和钱。
- 别为了续上连开多个账号或渠道，费用和排障成本都会翻倍，出了问题也不知道该查哪个
- 别在额度快满时启动长任务，中途断掉比没开始更费时间，还会留下一堆半成品
- 别只看单价不看计费口径，缓存命中、输入输出比例不同，账面单价和实际支出能差出一截
- 充值和升档前，先到官方 API 价格与套餐页核对当期口径和档位，别按旧印象下单
- 别信任何口头承诺的额度数字，以站内当时显示的为准
另一条常被忽略的坑：换渠道后以为万事大吉，结果发现新通道的稳定性、限流策略、计费方式都不一样，反而要多花时间适应。换之前先看站内中转站可信度检测和速度测试的结果，确认通道质量再迁。
下一次别再卡：把额度当预算来管
前面讲的都是补救。真正省心的是把它当预算来管：知道每次任务大概烧多少，知道哪类任务最吃额度，提前安排而不是撞上再慌。
- 按任务记一笔每跑完一个大任务，记下大概消耗和卡在哪一步。一周下来就能看出哪类任务最费额度，下次提前拆
- 给长任务设预算闸开跑前先估一下这次大概能烧多少，超过就拆成两段跑，别让一个任务吃掉整个窗口
- 把重复性工作交给轻量模型读写、格式化、改样板这类活不需要最强模型，额度留给真正难的推理部分
- 定期回看价格与档位到站内价格追踪和官方价格页看当期数字，档位和计费口径会变，半年不看的印象往往已经过时
如果团队共用账号，再加一条：把窗口分配写进流程，重任务固定时段跑，谁要跑大任务提前说一声。这比任何省额度技巧都管用。
下一步想看清自己实际该花多少，先把当期的计费和档位数字核对清楚，再拿自己的用量去代一遍，比凭印象做决定靠谱得多。→常见问题
Codex 五小时额度用完了，是不是要等到明天？
不一定，短窗口和周额度是两套节奏。先到站内额度查看与重置追踪页确认当前是哪一种用满，短窗口通常会自己恢复，周额度见底才需要考虑换路或升档。
额度用完了切 API 划算吗？
看用量形态。临时补一两个任务按量花不了多少，长期高频跑则可能比订阅贵。建议先用模型成本计算器按自己一周的实际用量代一遍，再决定切不切。
用完了还会不会在我没注意的时候继续扣？
订阅额度一般不会因为超额自动转成按量扣费，但具体口径要看当期说明。稳妥做法是把任务分成小段，每段跑完确认状态，别让长任务在无人看管时一直重试。
为什么感觉额度掉得比预期快？
最常见的原因是上下文太长和重复重试。每轮都带全量文件、失败后自动重跑，都会成倍放大消耗。先砍上下文、减少工具调用轮次，通常比换档位更有效。
多人共用一个账号，额度总是不够，怎么办？
多半是窗口被几个人同时打满。按项目或按人拆开使用、约定好长任务的启动时间，比直接升档更省钱；如果真的每天都不够，再看站内团队档位的额度口径是否匹配。
