1. 先别急着怀疑自己的账号：拆开这条报错，看它究竟卡在哪一层
大概每个长期用 Codex 干活的人都被这句话打断过：Selected model is at capacity. Please try a different model.我第一次看到时，第一反应是去检查自己的 API 额度和网络，结果额度充足、网络正常、代码也没问题。后来才慢慢意识到，这个报错说的根本不是"你不行"，而是"我这边忙不过来"。这篇就把这条报错背后的机制讲清楚，再给出从临时救急到长期规避的完整方案，希望能帮你少走我当初走过的弯路。
1.1 我实际撞上这个报错三种现场
先描述几个我真实遇到过的情况，方便你对号入座。
第一种，团队协作型。某个工作日下午，办公室里五六个人同时在用 Codex 改同一个代码库，有人改前端、有人改后端、有人让 Codex 帮忙写测试。没过多久，几个人先后开始报这个错，而且越来越频繁。
第二种，长会话积累型。我连续开了四五个小时的会话，让 Codex 反复分析一个大型模块，从项目结构聊到具体实现，又让它帮我梳理迁移方案。到了后半程，几乎每次交互都可能撞上"at capacity"。
第三种，新模型尝鲜型。某个新模型版本刚出来，大家都在抢着用，那几天几乎每次请求都可能在排队。你甚至不需要做什么大操作，随便问一句"这段代码什么意思"都可能被弹出来。
这三个场景的共同点很明显：请求都打到了一个当前比较热门的模型上。Codex 作为一套服务端推理系统，容量不是无限的。用户越多、请求越密集、单次请求的上下文越长，模型服务端就越接近满载。一旦饱和，调度器不会让你的请求无限排队，而是直接甩给你一句"换一个模型试试"——这话听起来像建议，实际上是服务端在自我保护和快速失败。
1.2 "at capacity" 到底指什么满了
我拿一个生活化的类比来解释。你可以把某个模型想象成一家热门餐厅：餐厅的座位就是同时能处理的请求数，后厨的出菜速度就是推理速度。饭点一到，全城的人都来排号，餐厅只能告诉你"现在没位子了，要不你去隔壁那家看看"。隔壁那家就是另一个模型，翻台率可能低一些、口味略有不同，但至少能让你吃上饭。
落到技术层面，"容量满了"通常由这几个因素叠加造成：
- 单模型并发上限：服务端为每个模型设定了并发额度，超出部分的请求会被快速拒绝，而不是排队等待。
- 请求上下文过长：Codex 的会话会积累大量文件内容、对话历史、工具输出。请求越长，占用计算资源越多，同样的服务容量能承接的请求数就越少。
- 时段性峰值：开发者普遍白天集中工作、下午和晚上达到高峰。全球不同时区的峰值叠加，让某些热门模型更容易满载。
- 组织级共享资源池：如果是组织账号，整个团队共享同一个容量池，一个人开了十几个线程，就会加速池子被耗尽。
搞明白这一层，你就明白了为什么"换模型"是最直接的解法：它本质上是在把你的请求从爆满的队列挪到尚有富余的队列。不是你的请求有问题，是入口被堵住了。
1.3 快速判断：这次是临时波动还是配置故障
这个报错通常属于临时性故障，不是封禁，也不代表代码有问题。我给自己定了一个判断标准：
- 报错是间歇性的，过几分钟再试又恢复了，那就是容量波动，不用过度反应，也不需要改什么配置。
- 连续一两天、换了好几个时段都稳定复现，那就要往账号配置、API 密钥有效性、网络连通性这些方向排查，而不是继续跟容量较劲。
提示：报错原文里的"try a different model"是服务端给出的标准提示，不代表你的账号被限制。只要你的请求偶尔能成功，说明账号状态健康。
2. 五分钟见效的操作：切换模型与搭一条自动降级链
既然报错的核心是"你选的模型满了"，那最快见效的方向就是模型选择。这里分两层说：会话期间的临时切换，和配置文件里的长期降级链。
2.1 交互式会话里的即时切换：/model 怎么用
Codex 的交互式会话里，直接输入/model就会弹出模型选择列表。选中一个不同的模型，后续的对话就会切到新模型上继续，不需要重启会话，之前聊过的内容也还在。
这个操作本质上就是服务员告诉你 A 餐厅还在排队，你可以直接去 B 餐厅的窗口点单。Codex 会把当前会话的上下文带过去，你贴过的文件、提过的需求都还在对话历史里，只是推理引擎换了。
我的个人建议是：报错出现后，先别急着重试，先切模型。因为如果你一直死盯着同一个满载模型反复请求，大概率是持续失败，白白消耗耐心。切一次模型，通常十几秒内就恢复了。我甚至有段时间把/model当成一个习惯动作，只要看到报错就切，几乎形成条件反射。
2.2 config.toml 里的 fallback 配置与版本差异
临时切换适合偶发情况。如果你一天要撞上好几次，那就该在配置层面把"降级链"搭好，让 Codex 自己知道"首选模型满了就自动换下一个"。
Codex 的配置文件通常位于用户目录下的~/.codex/config.toml。核心配置长这样：
model = "gpt-5-codex" model_fallback = ["gpt-5-mini", "o4-mini", "gpt-4o"]第一行是首选模型，第二行是降级链。当首选模型返回容量已满或暂时不可用时，Codex 会按顺序尝试列表里的下一个模型。这样即使你不在电脑前手动切，它也能自己绕开拥堵。
需要提醒的是，不同版本的 Codex 对配置项的命名可能有差异。我见过有版本用model_provider_fallback，也有版本要求 fallback 列表里的模型必须属于同一个服务商，否则不生效。改完配置后，务必执行一条真实请求验证效果，别想当然地以为"改了就生效"。验证方式很简单：在会话里跑一个小任务，然后故意观察日志或者使用/model查看当前实际生效的模型。
提示：不要把两个同样热门的模型同时放在 fallback 链的前两位。通常的做法是"能力较强但可能拥挤"的模型放第一位，"稳定但稍弱"的放第二位，既保质量又保可用性。
2.3 备选模型怎么排优先级：一张取舍参考表
在配置降级链之前，先搞清楚不同模型的定位，不然容易排错顺序。我整理了一张简单的对比表，方便你按自己的需求排优先级：
| 模型定位 | 优点 | 需要留意的点 |
|---|---|---|
| 顶级代码模型 | 复杂任务表现最好，跨文件理解深入 | 用户多、容量紧张，高峰期更容易满载 |
| 同系列小型模型 | 响应快、容量相对充足 | 复杂重构和长链路分析会吃力 |
| 通用对话模型 | 稳定性好，几乎不撞容量 | 代码结构化能力稍弱，需要给更具体的指令 |
| 经济型模型 | 便宜、快、几乎不排队 | 长上下文分析容易偷工减料 |
我自己的取舍逻辑：日常小需求直接走稳定型模型，不纠结；大的重构、跨文件修改、技术方案设计才用顶级模型，而且尽量安排在低峰时段。把顶级模型的使用频率降下来，撞容量的概率自然就降下来了。这不是让你降低质量，而是把宝贵的顶级算力用在刀刃上。
3. 从"撞容量"到"绕开容量"：重试节奏、上下文瘦身与任务拆分
如果切了模型还是偶尔碰到，或者你因为某些原因不想换模型，那就得从请求层面做文章。这部分是工程思维，核心是三个词：重试、节流、拆分。
3.1 换掉"无脑重试"：指数退避的实际节奏
遇到报错，人的本能是立刻再发一次请求。连续点几次发现还是不行，于是更用力地反复试。这种做法对容量问题毫无帮助，反而会加重服务端压力——你一个人就把自己那点请求变成了一股小型流量冲击。
正确做法是指数退避（exponential backoff）。简单说就是：第一次失败后等 2 秒，第二次失败等 4 秒，第三次等 8 秒，依次翻倍，最多等 60 秒左右就停手，过一段时间再开启下一轮。
如果你在脚本里调用 Codex 的 API，可以直接把这个逻辑写进代码。如果你用的是交互式会话，那更简单：失败一次后先去整理需求、看文档、写下一个任务的说明，过几分钟再回来。我实测下来，大部分容量报错在 5 到 10 分钟内会自动缓解，根本不需要一直盯着刷新。等待期间做点别的，比干等高效得多。
3.2 会话瘦身为什么能直接降低报错概率
容量问题与请求的上下文长度是强相关的。Codex 的每个会话都会把历史对话、文件内容、工具输出打包进后续请求里。会话越长，上下文越长，单次请求占用的推理资源越多，被拒绝的概率也越高。
所以治本的一招是"会话瘦身"。我给自己定了几个规矩：
- 一段任务完成后，及时新开会话，而不是一直聊到下班。
- 新会话开始时，不要把上一轮的分析结果原封不动贴回来，只带关键结论。
- 如果只是让 Codex 修改某个大文件，明确告诉它"只看第 X 到 Y 行"或"只关注某个函数"，而不是让它反复读整个文件。
- 需要它了解项目结构时，给目录树和关键文件的摘要即可，别一次性贴几十个文件内容。
这个习惯一开始会有点反直觉，因为你觉得"多给点上下文它理解得更清楚"。实际上，上下文越长，模型越容易在无关信息里丢失重点，而且请求成本更高、更容易撞容量。做到会话瘦身之后，响应速度和稳定性都会肉眼可见地提升。
3.3 自治模式与 API 层的多模型兜底
Codex 有两种工作方式：一种是你盯着它一步步改，另一种是给它一个明确目标，让它在后台自主迭代，完成后回来汇报。
第二种方式对容量问题的好处是天然降低了请求频率。它会在内部合理安排推理节奏，不会因为你站在旁边等而频繁发起请求。如果中途遇到容量报错，它通常会自行重试，你只需要在最后检查结果。大批量的代码迁移、技术债务清理这类任务，用自治模式远比手动一步步催更稳定。给它的指示越清晰，它自主工作的成功率越高，也越不容易因为来回对话把上下文堆得很长。
如果你直接调用 API，而不是用交互式界面，那可以在调用层做一层更细的兜底：
import time models = ["gpt-5-codex", "gpt-4o", "o4-mini"] for attempt in range(5): for model in models: try: result = client.responses.create(model=model, input=user_input) return result except CapacityError: print(f"{model} 容量不足，尝试下一个") continue wait = min(2 ** attempt, 60) time.sleep(wait)核心逻辑是：先依次尝试多个模型，全部失败后等一段退避时间再进入下一轮。多轮下来，只要服务端容量恢复，请求就能被接住。实际落地时，要根据对应 SDK 的异常类型做判断，我这里用的是示意写法，关键思路就是多模型尝试 + 退避等待，不要一棵树上吊死。
4. 治本思路：错峰调度、会话卫生与更稳的长期路径
前面几招属于"战术"，能解决大部分偶发问题。如果你长期高频使用 Codex，还得从使用习惯和整体工作流上做调整，这一节讲"战略"。
4.1 摸清高峰规律，把重活挪到低峰时段
容量问题有明显的时段规律。根据我长时间观察，工作日的下午和晚上是全球开发者的活动高峰，某些模型在这个时候最容易满载。相比之下，清晨和深夜的容量通常非常宽松。
如果你手头有大量不紧急的任务，比如批量重构、生成测试用例、整理接口文档，完全可以挪到空闲时段批量执行。我自己经常把重活安排在晚上，第二天早上起来看结果，效果出奇地稳。这不是让你非要在深夜加班，而是把不同性质的任务分配到正确的时段：
- 重要且紧急的任务：放在容量稳定时段，或者干脆用稳定型小模型边做边调。
- 重要但不紧急的任务：可以放在低峰时段跑顶级模型，质量优先。
- 不重要但耗时的任务：随时可以丢给自治模式慢慢跑，不占用你的工作时间。
错峰不是玄学，本质上是让请求避开容量波峰，用最小成本换取最稳定的可用性。
4.2 一个任务一个会话：我的会话卫生规则
前面提到过会话瘦身，这里再展开一下"会话卫生"。很多人喜欢一整个上午都开着同一个 Codex 会话，从项目背景一路聊到收尾。这样做最直接的后果就是上下文爆炸，请求体越来越重，服务端越来越容易拒绝。
我给自己定的规矩非常死板：
- 一个任务一个会话，任务结束立刻关掉，不恋战。
- 会话持续超过一小时，主动开新的，把关键结论用几句话转述过去。
- 每个新会话开头先用一两句话说明"当前代码库背景 + 我要做的事"，而不是一上来就贴代码。
- 每次只给 Codex 完成当前步骤所需的信息，做完一步再给下一步的信息。
坚持这套规则之后，容量报错的频率肉眼可见地下降。更重要的是，每次请求的响应速度也更快了，因为服务端不需要处理一个巨大的上下文堆。代码要讲卫生，会话也要讲卫生。
4.3 频繁满载时，值得考虑的长期替代方案
如果你的团队规模较大，或者业务对可用性要求极高，云端推理容量的波动可能已经成了真正的瓶颈。这时候可以考虑几条更稳的路径：
- 本地部署代码模型：在自己或公司的 GPU 服务器上跑开源模型，完全不受云端容量影响，隐私性和可控性也更好。代价是需要硬件投入和运维成本。
- 混合模式：日常简单任务走本地模型，复杂任务走云端顶级模型。本地扛住高频请求，云端只承接少量高质量请求，容量压力会小很多。
- 独立容量池：如果是组织级使用，可以考虑申请独立的资源池，把容量波动从共享资源池中隔离开来，费用更高但稳定性最好。
这几条路径的投入都不小，但如果容量问题已经影响到交付节奏，就值得认真评估。我的建议是：先把前面章节的战术性方法用足，真不够了再上战略级方案。大多数个人开发者和中小团队，把配置降级链和会话卫生做到位，就已经能解决九成的问题了。
5. 实测验证：我的固定流程与最容易踩的四个误区
讲到这里，把实战部分做个总结。哪些方法我实测有效，哪些方向我踩过坑，以及一张可以直接存下来用的速查表。
5.1 我一直在用的组合拳
我现在应对容量报错的固定流程是这样的：
- 报错出现，先在交互式会话里输入
/model切到稳定型模型，一般立刻恢复。 - 如果临时切换不方便，就等 5 到 10 分钟再试，同时利用这段时间整理思路、拆解下一步任务。
- 长期项目一定在
config.toml里配好model和model_fallback，让降级自动化。 - 重要任务安排在容量稳定时段，批量任务放在低峰时段后台跑。
- 坚持一个任务一个会话，绝不在一个会话里无限堆积上下文。
这套组合拳用下来，容量报错的出现频率比最初下降了大约八成。剩下的两成属于极端高峰，直接错峰处理，完全没有心理负担。
5.2 最容易误判的四个方向
有几个坑我自己踩过，也看别人反复踩，分享出来帮你绕开：
坑一：以为是额度问题，疯狂升级套餐。容量报错和配额超限不是一回事。配额超限通常会明确提示"rate limit"或"quota exceeded"，而"at capacity"是服务端暂时没有可用资源。升级套餐对前者有效，对后者基本无用，别花冤枉钱。
坑二：反复重启客户端以为能刷新状态。重启客户端不会改变服务端容量。你重启一百次，服务端该满还是满。真正有效的是换模型、等一等，或者拆小请求。
坑三：只改配置不验证。很多人往config.toml里加了model_fallback就以为万事大吉，结果发现根本没生效。版本差异、配置项名写错、配置文件没被加载都可能导致无效。改完配置一定要跑一条实际请求验证，别信"改了就生效"。
坑四：误以为换模型会丢失所有上下文。切换模型不会清空当前会话的历史信息。Codex 会把上下文带过去，你只需要重新发起一次回复即可。别因为担心丢上下文而硬扛着不切，得不偿失。
5.3 排查速查表
最后是一张速查表，建议收藏备用：
| 现象 | 优先处理动作 | 备注 |
|---|---|---|
| 偶发容量报错 | 等待 5-10 分钟后重试，或切换模型 | 大概率是服务端容量波动，无需折腾 |
| 高频容量报错 | 配置 model_fallback 降级链，做会话瘦身 | 长期方案是错峰与任务拆分 |
| 换模型后仍报错 | 检查配置是否生效、API 密钥是否有效 | 按版本查文档确认配置项名称 |
| 报错伴随超时 | 检查网络连通性与请求上下文大小 | 网络层问题按网络层排查 |
| 组织内多人同时报错 | 协调团队错峰使用，或评估独立容量 | 共享容量池被多人打满 |
我在实际使用中最大的体会是：把容量报错当成服务端给的一个信号，而不是一个故障。它提醒你该切换、该等待、该调整使用方式。顺着这个信号去优化工作流，整个 Codex 的使用体验都会变得更稳，而不是每次都被这句话打断思路。下次再看到这条报错，先深呼吸，切个模型，整理一下上下文——大概率就解决了。
