就在昨天，我又在 Codex 里撞上了那条已经把很多人逼疯的提示：Selected model is at capacity. Please try a different model.第一次看到这串英文时，我第一反应是账号是不是被风控了，于是跑去查订阅、看网络、重登账号，折腾了大半天，最后发现根本没用。后来用多了才摸清规律——这不是你个人账号的问题，而是当前请求撞上了模型的容量瓶颈。
这篇文章我不打算给你灌鸡汤，也不会说“等等就好了”这种废话。我会把从实际使用中反复试出来的方法完整拆开：为什么会有这个报错、切换模型到底怎么切才能不吃亏、重试节奏怎么设计才科学、以及怎么从上下文和任务拆分入手减少触发次数。不管你是刚接触 Codex 的新手，还是已经被它折磨了一阵子的老用户，照着后边的步骤调整，基本能把“撞容量”的频率降一个量级。
1. 先搞懂“capacity”是什么意思：这口锅不背在你身上
1.1 模型容量背后是一大堆 GPU 在排队
很多人一看到 “at capacity” 就以为是账号欠费、网络异常或者触发了什么安全策略，其实都不是。这句话翻译成人话就是：你选中的这个模型，此刻的推理资源已经被塞满了。
一个大模型并不是一台电脑在回答你的问题，而是服务商在云端维护了一个大规模的 GPU 集群，每个集群同时只能承载一定数量的请求。你可以把模型容量想象成一家餐厅的座位：座位有限，客人一多，门口的迎宾就只能说“稍等”或者“请换一家”。Codex 返回这行提示的时候，等于服务员在告诉你：现在这个模型的前面已经排了很多人，你挤不进去。
这个机制是设计出来的，不是故障。服务端宁可拒绝新请求，也要保证已经接住的请求能稳定跑完，否则全体用户都会体验崩盘。所以遇到这个报错，先别急着给自己“判刑”，大概率只是运气不好，撞上了高峰。
1.2 哪些场景最容易触发这个报错
我观察了很长一段时间，发现自己被 “at capacity” 堵门的场景高度集中在这几类：
- 热门模型的上新初期：每次有新模型放出，大家都想尝鲜，容量瞬间被挤爆。这个阶段几乎任何时间段都可能报错。
- 工作日白天：从上午九点到下午六点左右，是使用人数最多的时候，容量水位会一直偏高。
- 上下文超长的会话：如果你在一个会话里堆了几万甚至十几万 token 的历史内容，每次请求都要重新处理这一大坨信息，单请求占用的推理资源会明显上升，更容易被判定为“太重了”。
- 并发任务过多：同时开五六个 Codex 窗口，每个窗口都在提问，等于一个客户同时占了好几张桌子，被拒的概率自然更大。
我把常见的触发场景整理成了下面这张表，方便你对号入座：
| 场景 | 触发概率 | 主要原因 |
|---|---|---|
| 工作日白天提问 | 高 | 在线用户多，资源紧张 |
| 新模型发布初期 | 极高 | 尝鲜用户集中涌入 |
| 长会话连续提问 | 中高 | 单请求 token 量太大，占用资源多 |
| 多窗口并行操作 | 高 | 个人并发请求叠加 |
| 凌晨或深夜提问 | 低 | 在线用户少，容量释放 |
搞清楚这些，你就能明白一个道理：所谓“缓解”不是找一个万能按钮，而是错开高峰、减少单请求体积、降低并发这三件事的组合。
2. 切换模型不是将就：备选模型怎么选才不亏
2.1 先搞清楚手上有哪些“座位”
遇到报错时，提示本身就给了你一个方向：Please try a different model。所以最直接的办法就是换模型。但很多人的换法是闭着眼睛在模型列表里随手点一个，结果发现任务质量明显下降，或者干脆换了个更堵的模型，继续报错。
以我实际使用的经验，Codex 这类 AI 编程工具通常会给几个不同定位的模型选项。我把它们粗略梳理成三类：
| 模型定位 | 特点 | 适合任务 | 高峰期容量表现 |
|---|---|---|---|
| 主力模型 | 推理强，代码生成质量高 | 架构设计、复杂重构、跨文件修改 | 最容易撞容量 |
| 快速模型 | 响应快，质量略低于主力 | 补全函数、写单测、简单解释 | 相对宽松 |
| 轻量模型 | 占用低，生成结果偏保守 | 格式化、重命名、小范围改动 | 通常最稳 |
我的建议是：不要在同一个任务上死磕主力模型。遇到报错，第一时间切到快速模型试试，如果任务本身不复杂，用轻量模型也能扛过去。很多看似需要“高级推理”的任务，其实拆开之后都是一个个简单的小操作，用快速模型完全够用。
2.2 切过去之后要注意的细节
切换模型不是一个无害操作，它会影响输出质量，所以有几个细节需要盯住。
第一，切换模型后，先做小范围验证，别直接批量生产。我会把一个任务里最核心、最刁钻的那一小段先丢给新模型试跑，比如一个复杂算法的核心实现，或者一个跨文件的改动。如果这一步的结果能看，再继续往下走；如果结果明显跑偏，就说明这个备选模型撑不起当前任务，该做的是等，而不是硬着头皮用。
第二，注意会话上下文是否继承。在大多数界面里，切换模型不会清空历史对话，但新模型看到的上下文计算方式和主力模型可能不一样。这会导致同一个会话里，前半段用的是主力模型的思路，后半段新模型“接不上茬”。我踩过几次坑之后学乖了：切换模型的同时，会顺手把当前一轮的需求重新描述一遍，不给模型留“猜上下文”的空间。
第三，把“切换模型”也当成策略，而不是应急。如果你知道今天要处理的任务都不复杂，那就一开始就用快速模型，别等主力模型报错了再切。主动选择低配模型，反而能减少中途被打断的次数。
3. 重试也有节奏：盲目连点只会越点越慢
3.1 为什么不建议卡住时疯狂重试
人一着急就会狂点重试，这很正常。但这个操作恰恰是最差的应对方式。每次点击重试，你都在向服务端发起一次新的请求，而服务端此时已经过载，你越点，队列越堵，最后可能连原本能通过的请求也被带崩。
更重要的是，高频重试在某些场景下会触发更严格的限流策略。我之前有一段经历特别典型：某个上午连续遇到报错，我不信邪地隔几秒点一次，点了大概十几次，结果接下来十几分钟里连快速模型也开始报错，态度反而更坚决了。等我把手停下来，过一阵子再试，才恢复正常。
3.2 一套亲测可用的退避重试节奏
正确的姿势是退避重试：每次失败后，等待时间逐步拉长，给服务端一个释放资源的时间窗口。我自己常用的节奏是一组等差数列：15 秒、30 秒、60 秒、180 秒。前三轮失败还可以理解，到第三轮还失败，说明当前确实是资源洪峰，不如先停五分钟再回来。
如果你常用终端环境里的 Codex，完全可以把这个节奏写进脚本。下面是一个简单的 bash 示例，会在命令失败后按递增间隔重试：
#!/bin/bash for attempt in 1 2 3 4 5; do # 这里替换成你实际的 codex 调用命令 codex "按照项目规范重构 user_service.py" if [ $? -eq 0 ]; then echo "任务完成" break else wait_time=$((attempt * 15)) echo "第 $attempt 次失败，等待 ${wait_time} 秒后重试..." sleep "$wait_time" fi done这个脚本的逻辑很简单：命令返回 0 就认为成功，直接结束；否则根据当前是第几次尝试，等待 15、30、45、60 秒。你可以根据自己的网络状况和任务时长调整倍率。如果在图形界面里操作，就自己盯着时间点，别凭感觉乱点。
3.3 错峰使用：把高难度任务安排到低峰期
重试只是治标，真正治本的方法是错峰。我在记录了一段时间的报错时间之后发现，本地时间的上午十点到下午四点是最容易撞容量的时候，而凌晨两点到早上七点之间，几乎很少见到这个提示。如果你手头有可以延后的批量任务，为什么不把时间调到晚上？
我现在的做法是：白天只处理那些交互性强、需要我盯着看的小任务，遇到报错就切轻量模型；一到晚上，再把那些重型的重构、迁移、批量代码生成任务集中放出来。用时间换容量，这是成本最低的缓解方案。
4. 把请求“变瘦”：上下文管理才是隐藏开关
4.1 上下文越长，请求越重
很多人没意识到，“at capacity” 不只是服务端整体资源的问题，还和你发送的请求本身有多重直接相关。Codex 在回答你当前问题时，会把整个会话的历史内容都带进计算，包括你之前的提问、它的回答、你贴进来的文件源码、中间出错时的报错信息……这些内容加起来可能是一个极其庞大的 token 包。
一个调用如果携带了 5 万 token 的上下文，和一个只携带 500 token 的请求，在服务端占用的推理时间完全不同。在高峰期，服务端会优先保障轻请求的吞吐，而那些“大胖子”请求就容易吃闭门羹。这也是为什么同一个时间段，有的人发简短问题能通，有的人发长会话却一直报错。
4.2 任务拆解：大任务变成小任务
我用的最顺手的优化方法，是把大任务拆成小任务，并且每拆一步就开一个新会话。举个例子，我要重构一个支付模块，如果直接丢给 Codex 说“把这个模块重构一下”，它会需要加载整个模块的代码、理解业务逻辑、再输出一大堆修改，上下文自然爆炸。但我如果把它拆成四步——先定义接口，再迁移数据库字段，再改核心业务逻辑，最后补测试——每步单独开对话，只带必要的文件，成功率就会高很多。
拆前和拆后的对比非常明显：
| 处理方式 | 单次请求携带的上下文 | 单次请求耗时 | 高峰期报错概率 |
|---|---|---|---|
| 一次性重构整个模块 | 数万 token | 长 | 高 |
| 拆成四步逐步完成 | 每次数千 token | 短 | 低 |
拆任务还有一个额外的好处：即使某个环节因为容量问题失败，损失的也只是一个小步骤，不会让整次对话的上下文全部报废。
4.3 别把整个代码库塞进对话
另一个常见的错误习惯，是习惯性地把多个文件甚至整个项目目录拖进上下文里。看起来省事，实际上是在给自己制造容量障碍。正确的做法是只带和当前改动有直接关系的文件，然后再用一句精准的描述来定位需求。
比如，不要贴一个 1000 行的服务文件然后说“帮我优化一下”，而是说“在 payment_service.py 的 charge 方法里，修复当余额不足时返回的错误码”。前者会让模型把整个文件都当作背景信息处理，后者则能把注意力集中在真正需要的代码段上。请求变轻了，服务端处理得更快，撞容量的概率自然下降。
5. 让等待变成自动化：本地队列与重试脚本实践
5.1 一个可复用的 Python 重试调度器
如果你经常在终端里使用 Codex，与其每次手动盯着报错重试，不如写一个本地调度脚本。下面是我自己用的一段 Python 思路，它会自动切换模型、按指数退避重试，并把每次失败的时间记录下来：
import time import subprocess import logging logging.basicConfig(filename="capacity.log", level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s") models = ["model-a", "model-b", "model-c"] retry_limits = [15, 30, 60, 120, 240] # 每次重试前等待的秒数 def run_task(task_command, task_name): for attempt, model in enumerate(models * 3): cmd = f"codex --model {model} \"{task_command}\"" logging.info("任务 %s 第 %d 次尝试，模型 %s", task_name, attempt + 1, model) result = subprocess.run(cmd, shell=True, capture_output=True, text=True) if result.returncode == 0: logging.info("任务 %s 成功", task_name) return True if attempt < len(retry_limits): time.sleep(retry_limits[attempt]) logging.error("任务 %s 最终失败", task_name) return False这段代码的意思是：每个任务最多尝试 3 轮，每轮都会换一个模型；每次失败后等待的时间从 15 秒开始逐步增加到 240 秒。这样即使高峰期资源紧张，脚本也能自己“磨”过去，而你完全不用守在屏幕前。
实际操作中，你只需要把task_command换成自己真正要给 Codex 的指令，把models列表改成当前账号可用的模型标识即可。
5.2 把非紧急任务放进“深夜批处理队列”
比重试脚本更进一步的思路，是干脆把任务计划到低峰期执行。我个人的习惯是使用系统自带的定时任务功能，在凌晨统一跑一批不太紧急的代码生成和重构任务。比如在 Linux 或 macOS 环境下，可以用 cron 写一个简单的定时任务：
# 每天凌晨 2 点执行任务队列脚本 0 2 * * * /usr/local/bin/codex_batch_jobs.sh >> /tmp/codex_batch.log 2>&1这样做的逻辑很简单：凌晨的容量水位通常很低，跑同样一批任务，成功率更高，速度也更快。你只需要在白天下班前把任务清单准备好，剩下的事情交给定时器。
5.3 不要同时开十个窗口
还有一个我反复踩过的坑：为了提高效率，同时打开一堆 Codex 窗口并行推进多个任务。结果每个窗口都在高频发请求，加起来的并发量很容易把容量顶爆，最后所有窗口一起报错，反而越“并行”越慢。
正确的做法是限制并发：同时只维持一到两个活跃会话，把其它任务排进队列。这就像你不可能同时在三家餐厅各占一个位置还都满意一样，集中资源办一件事，才是和数据中心打交道的正确姿势。
6. 现场排障的几条经验：什么有用，什么纯属玄学
6.1 这些操作基本没用，别再浪费时间
遇到报错时，我见到太多人把市面上能试的“偏方”全都试了一遍。这里帮大家排除一些基本没用的操作：
- 刷新页面、清理浏览器缓存：这个报错在服务端，不在你本地，缓存再干净也不影响容量。
- 反复重新登录：除非界面同时提示你登录过期，否则重新登录不会改变任何服务器资源分配。
- 更换浏览器或设备：这个操作除了能让你换个心情，对服务端容量一点作用都没有。
- 把报错内容截图反复阅读/翻译成中文：不会让你更接近解决办法，只会浪费几分钟。
我理解大家在遇到问题时的“求生欲”，但请把这些时间留给真正有效的调整。
6.2 真正值得检查的三件事
那到底什么是有效的？下面三件事值得你在报错时逐一确认：
- 看服务提供方的状态页。很多时候报错不是因为你撞上了普遍高峰，而是某些模型或服务发生了局部故障。如果状态页标注了异常，你要做的是等待，而不是反复重试。
- 检查当前会话是否已经接近上下文上限。如果会话里塞的东西太多，模型处理负担会加重，间接提高报错概率。这时候哪怕只是开一个新会话，把需求重新描述一遍，成功率都会立刻改善。
- 确认任务是不是真的需要主力模型。有些任务看起来高级，实际上全是套路化操作。试着把同样的需求发给快速模型，说不定十几秒就出结果了。
6.3 我给自己的“容量管理守则”
在反复跟这个报错打交道之后，我给自己定了几条规则，现在几乎成了习惯：
- 白天只用轻量模型处理短平快任务，重任务全部留到晚上或凌晨；
- 一条任务最多重试三轮，三轮不过就切换模型，而不是继续跟同一个模型硬磕；
- 每完成一个步骤就另开新会话，保持上下文精简；
- 遇到报错的间隙不干等着，而是顺手去审查已经生成的代码 diff，把等待时间变成生产力。
这几条规则听起来简单，但每一条都是从实际挫败里提炼出来的。你不需要全部照搬，挑两三条能落到自己工作流里的，就足够明显改善体验了。
最后再分享一个小习惯：我手边常备一个叫capacity.log的文件，每次遇到报错就顺手把时间、所在时段、使用的模型、任务类型记一笔。坚持记录一周之后，你自然会发现自己和这个报错打交道的规律——哪个时段最容易堵、哪类任务最容易被拒，全都在数据里写着。根据这些规律去安排自己的任务，比任何应急方法都更治本。工具再智能，也得顺着它的脾气来，希望这篇经验能让你少几次血压升高的瞬间。
