1. 这条报错到底在说什么从容量两个字拆开看第一次看到Selected model is at capacity. Please try a different model这条提示很多人的第一反应是我账号是不是被封了或者是不是网络出问题了。其实都不是。这句话的字面意思非常直白你当前选中的那个模型此刻的并发处理能力已经被占满了服务端建议你换一个模型再试。它和429 Too Many Requests是两回事虽然表现上都是请求失败。429通常指向你个人的调用频率超限比如短时间内发了太多请求触发了速率限制而at capacity更多是服务端侧的资源调度问题——某个特定模型尤其是新发布、热度高、或者算力配额有限的模型在同一时间被大量用户争抢池子满了新来的请求就被挡在门外。理解这个区别很重要因为它直接决定了你该等一等还是换一换。我在实际使用中遇到过好几次这个提示场景各不相同有一次是深夜批量跑代码重构任务连续几十个请求打到同一个模型上有一次是刚切换到一个新上线的模型结果那个模型当时正处于灰度放量阶段容量很小还有一次最离谱是我本地配置里模型名写错了一个字符客户端回退到了一个默认模型而那个默认模型恰好是当时最拥挤的。所以这条报错背后可能是服务端真的忙也可能是你本地配置在帮倒忙。这篇文章适合几类人看刚接触 Codex CLI、还在摸索配置的新手已经把 Codex 接进日常开发流、但偶尔被这条报错打断节奏的老用户以及那些在 VS Code 里用插件、遇到报错却不知道从哪下手排查的人。我会把这条报错的成因、排查链路、以及几种真正能落地的应对方案讲清楚包括模型切换、配置修正、重试策略以及怎么判断到底是服务端忙还是你配错了。需要先说明一点下面提到的所有操作都是基于常见的客户端配置实践总结出来的通用思路具体到你用的版本和平台字段名和路径可能有差异以你本地实际为准。核心逻辑是通的照着思路走就不会偏。2. 为什么偏偏是你被挡在门外容量报错的四种真实成因2.1 模型热度与算力配额的错配最直接的原因就是你选的模型太抢手了。新模型发布初期官方给的推理算力往往是分批放量的先小范围灰度再逐步扩容。这个阶段容量池很小稍微有点热度就会被挤爆。你如果在发布当天或者热度高峰期去调用撞上at capacity的概率非常高。这种情况有个明显特征换个时间段再试就好了。比如早上八点前、午休时段、或者深夜成功率会明显上升。因为这几个时间点整体请求量相对低。我自己的经验是工作日的上午十点到下午四点是最拥挤的尤其是周一大家都刚开工批量任务集中跑。判断是不是这个原因最简单的办法就是换一个模型试试。如果换成另一个模型立刻就能通那基本可以确定是原模型容量问题而不是你的配置或网络问题。2.2 客户端配置里的模型名不匹配这是最容易被忽略、也最坑人的一类。你的配置文件里写的模型名如果和服务端实际支持的名称对不上客户端可能会做两件事之一要么直接报错要么静默回退到一个默认模型。而那个默认模型往往就是当前最拥挤的那个。举个我踩过的坑我在配置里把模型名写成了带版本号后缀的形式结果那个后缀在当前服务端并不存在客户端没有明确报模型不存在而是回退到了通用模型然后就开始频繁at capacity。我一开始以为是服务端忙等了半天后来才发现是配置写错了。改回正确的模型名之后问题立刻消失。所以遇到这个报错第一件事应该是核对你的模型名。去官方文档或者你所用客户端的模型列表里确认当前可用的模型标识符逐字符比对。别嫌麻烦这一步能省掉大量无谓的等待。2.3 并发请求把容量池瞬间打满如果你是在跑批量任务比如一次性提交几十个文件让模型处理或者写了个循环连续调用那么即使模型本身容量充足你自己的并发量也可能把分配给单用户的配额瞬间打满。这种情况的特征是单个请求手动发能通批量发就报错。因为手动发的时候请求是串行的间隔足够大批量发的时候多个请求同时到达服务端一看这个用户瞬间来了这么多直接触发容量保护。解决办法不是换模型而是控制并发节奏。加个请求间隔或者把批量任务拆成小批次串行执行成功率会高很多。我一般会在批量脚本里加一个几百毫秒到一秒的延迟实测下来稳定性提升非常明显。2.4 中间层代理或转发环节的干扰还有一种情况是你用了某种本地代理、转发工具或者中间层来接入 Codex。这类工具在转发请求时如果配置不当可能会改写模型名、丢失部分请求头、或者把请求路由到错误的端点最终导致服务端收到的模型标识和你以为的不一致从而触发容量报错。热词里提到的cc switch local proxy failed while handling codex endpoint /responses就是这类问题的典型表现——本地代理在处理请求时失败了。这种情况下报错信息里往往还会伴随其他线索比如端点路径不对、认证失败等。排查时要先确认代理层是否正常工作再去看模型容量的问题否则你会在错误的方向上浪费大量时间。下面这张表可以帮你快速定位自己属于哪种情况现象特征最可能的原因优先排查方向换模型立刻能通原模型容量不足换模型或错峰使用手动能通、批量报错自身并发过高降低并发、加请求间隔报错伴随认证/端点异常代理或配置问题检查代理层和配置文件改配置后突然开始报错模型名写错导致回退逐字符核对模型标识符特定时间段必现服务端高峰期调整使用时段3. 从报错到定位一条可复现的排查链路3.1 第一步永远是确认当前实际使用的模型很多人以为自己知道在用哪个模型其实未必。客户端可能有默认值、可能有回退逻辑、可能被环境变量覆盖。所以排查的第一步是用最直接的方式确认当前请求真正打到了哪个模型上。如果你用的是命令行工具可以先用一个最简单的请求测试观察返回信息里有没有模型标识。有些客户端会在响应头或者日志里带上实际使用的模型名。打开详细日志模式通常是加一个 verbose 或者 debug 参数能看到完整的请求和响应过程。这一步的目的是排除你以为的模型和实际用的模型不一致这个可能性。我见过太多案例用户信誓旦旦说自己在用 A 模型结果日志一开发现实际打的是 B 模型。不先确认这一点后面所有排查都是空中楼阁。3.2 用最小请求隔离变量确认模型之后下一步是用最小化的请求来隔离变量。所谓最小请求就是一条最简单的、不涉及复杂上下文的调用比如只发一句你好。为什么要这样做因为复杂的请求会引入很多干扰因素上下文太长可能触发其他限制、工具调用可能走不同的处理路径、附件或文件可能影响路由。用最小请求测试能把问题范围缩小到模型容量这一个变量上。如果最小请求也报at capacity那基本可以确定是模型侧的问题换模型或等待即可。如果最小请求能通但你的实际任务报错那问题可能出在请求体本身比如上下文过大、并发过高、或者某个参数触发了特殊处理逻辑。3.3 检查配置文件里的模型字段最小请求验证完之后回头仔细看你的配置文件。不同客户端的配置格式不一样但核心字段通常就那么几个模型名、端点地址、认证信息、超时设置。重点检查模型名字段。常见错误包括大小写不一致、多了或少了版本后缀、用了已经下线的旧名称、复制粘贴时带了多余空格。这些看起来很低级的错误实际发生率极高因为模型名往往是一长串字符肉眼很难发现细微差异。我的习惯是把官方文档里的模型名直接复制到配置里而不是手动输入。手动输入出错概率太高尤其是那些带数字和连字符的名称。复制之后再用编辑器的查找功能确认一遍确保没有隐藏字符。3.4 观察报错的时间规律如果配置没问题、最小请求也时通时不通那就要观察时间规律了。记录一下报错发生的具体时间点连续记录几天看看有没有集中趋势。如果报错集中在某些时段那就是服务端高峰期的问题错峰使用即可。如果报错是随机的、没有规律那可能是服务端在做动态扩缩容或者你的请求恰好撞上了其他用户的批量任务。这种情况下重试机制就很重要了。我一般会在脚本里加一个简单的重试逻辑遇到at capacity就等待几秒后重试最多重试三到五次。实测下来大部分偶发的容量报错都能通过重试解决。但要注意重试间隔不要太短否则会加剧拥塞反而更容易失败。3.5 区分服务端忙和你配错了的判定表把上面的排查步骤总结成一张判定表遇到报错时对照着走能省不少时间排查动作观察结果结论换一个模型测试立刻能通原模型容量问题换一个模型测试仍然报错可能是配置或代理问题最小请求测试能通问题在实际任务的请求体最小请求测试报错模型侧或配置侧问题核对模型名发现不一致配置错误修正即可记录时间规律集中在高峰时段错峰使用或加重试检查代理日志有转发失败记录代理层问题优先修复这张表不是万能的但能覆盖绝大多数常见情况。遇到报错时按顺序走一遍基本都能定位到根因。4. 真正能落地的应对方案从换模型到改配置4.1 换模型最快但也最需要判断力的一招报错信息本身就建议你try a different model所以换模型是最直接的应对方式。但换哪个模型是有讲究的不能随便换。首先要确认你手头有哪些可用模型。不同账号、不同订阅级别可用的模型列表可能不一样。去官方文档或者客户端的模型列表里查一下确认哪些是你当前权限能用的。其次要考虑任务匹配度。如果你在做代码生成就换一个擅长代码的模型如果是在做长文本处理就换一个上下文窗口大的模型。别为了绕开容量报错换了一个完全不擅长当前任务的模型那样虽然不报错了但输出质量会下降得不偿失。我的经验是平时就准备好两到三个备选模型主力模型报容量的时候就切到备选。备选模型不一定要和主力一样强但要能覆盖你大部分日常任务。这样切换的时候不会手忙脚乱。4.2 错峰使用把任务挪到不拥挤的时段如果你的任务不是实时性要求很高的错峰使用是最省心的方案。把批量任务、重构任务、文档生成任务挪到请求量低的时段跑成功率会高很多。根据我的观察相对空闲的时段包括清晨早上七点前、午休时间十二点到一点半、深夜晚上十一点后。当然这只是一般规律具体还要看你所在时区和目标用户群体的分布。错峰使用还有个好处响应速度通常也更快。高峰期即使请求成功了排队等待的时间也可能很长错峰时段服务端负载低响应往往更干脆。所以如果你的任务可以调度尽量往空闲时段安排。4.3 控制并发别让自己的请求把配额打满前面提到过批量任务容易触发容量报错。解决办法是主动控制并发。具体做法有几种第一种是串行执行一个请求完成后再发下一个。最简单但速度慢。适合任务量不大、对时间不敏感的场景。第二种是限制并发数比如同时最多发三个请求完成一个再补一个。这需要在脚本里维护一个请求队列稍微复杂一点但效率比纯串行高很多。第三种是加请求间隔每个请求之间固定等待一段时间。实现简单效果也不错。我一般会设置几百毫秒到一秒的间隔具体数值根据任务量和报错频率调整。不管用哪种方式核心思路都是别让服务端在同一瞬间收到你太多请求。服务端的容量保护机制是按瞬时并发来判断的你把请求摊开就能有效规避。4.4 修正配置把模型名和端点核对清楚如果排查下来发现是配置问题那就老老实实改配置。重点核对三个地方模型名逐字符比对确保和官方文档一致。注意大小写、连字符、版本后缀。端点地址确认请求打到了正确的服务地址。如果你用了代理或转发检查代理配置里的目标地址是否正确。认证信息确认令牌有效、没有过期、权限足够。有些容量报错其实是认证问题被包装成了容量提示虽然不常见但值得排查。改完配置后用最小请求验证一遍确认问题解决再跑正式任务。别改完就直接上批量任务万一没改对又是一堆报错。4.5 重试机制给偶发失败一个缓冲对于偶发的容量报错重试机制是必备的。实现起来很简单捕获报错等待一段时间重新发起请求最多重试若干次。重试的关键参数有两个重试次数和重试间隔。重试次数建议三到五次太多会浪费时间太少可能覆盖不到偶发情况。重试间隔建议采用递增策略比如第一次等两秒第二次等四秒第三次等八秒给服务端足够的恢复时间。要注意的是不是所有报错都适合重试。如果是配置错误、认证失败这类问题重试多少次都没用只会浪费时间。只有容量类、限流类的偶发报错才适合用重试来兜底。5. 那些文档里不会写的实操心得5.1 别把换模型当成万能药很多人一看到容量报错就换模型换完发现还是报错就开始怀疑人生。其实换模型只是应对手段之一不是所有容量报错都能靠换模型解决。如果根因是配置错误或者代理问题换多少个模型都没用。我的做法是先花三十秒确认配置和模型名再决定要不要换模型。这三十秒的检查能过滤掉大部分假容量报错。真正的容量问题换模型立刻见效配置问题换模型照样报错。用这个特征可以快速区分。5.2 日志是你的第一手证据遇到报错不要凭感觉猜打开日志看原始信息。客户端的详细日志里通常包含完整的请求和响应能看到实际使用的模型、端点、以及服务端返回的完整错误内容。有些报错信息在界面上被简化了只显示一句at capacity但日志里可能有更详细的说明比如具体是哪个模型、哪个配额、什么时间窗口。这些信息对定位问题至关重要。我习惯在排查任何问题时第一件事就是开日志。养成这个习惯之后排查效率会提升一大截。5.3 备选模型要提前配好别等报错才找临时找备选模型是很被动的。报错的时候你正忙着干活还要去查文档、找模型名、改配置节奏全乱了。更好的做法是提前把备选模型配置好甚至写好切换脚本。主力模型报错时一条命令就能切过去不打断工作流。我自己的配置里常备两个备选模型一个偏代码、一个偏通用根据任务类型和可用性灵活切换。5.4 批量任务一定要有失败处理跑批量任务的时候一定要假设会有请求失败并提前写好失败处理逻辑。最简单的做法是记录失败的请求等批量跑完之后单独重试这些失败的。如果没有失败处理一个请求报错可能导致整个批量任务中断前面的成果也可能丢失。加上失败记录和重试任务就能跑得更稳。我一般会把失败请求的输入和报错信息一起记到日志里方便事后分析。5.5 版本更新后重新核对配置客户端或者服务端更新之后模型列表和配置格式可能发生变化。更新前能用的模型名更新后可能就变了更新前能用的字段更新后可能被废弃了。所以每次更新之后花几分钟重新核对一遍配置确认模型名、端点、认证信息都还对得上。这个习惯能帮你避开很多更新后突然报错的坑。6. 把这条报错变成日常流程的一部分Selected model is at capacity. Please try a different model这条报错本质上不是故障而是服务端在告诉你当前资源紧张请灵活一点。与其把它当成需要消灭的敌人不如把它当成一个信号提醒你检查配置、调整策略、准备备选方案。我现在的工作流里已经把这条报错的应对内化成了几个固定动作配置里常备备选模型、批量脚本带重试和失败记录、遇到报错先看日志再动手。这套流程跑下来容量报错基本不会打断我的节奏最多就是切换一下模型几秒钟的事。如果你刚开始用 Codex遇到这条报错不用慌。按着排查链路走一遍确认是容量问题还是配置问题然后对症下药。用不了多久你也能形成自己的应对套路。真正重要的不是记住某个具体的模型名或者配置字段而是理解这条报错背后的逻辑——服务端资源有限客户端要灵活。理解了这个不管以后遇到什么变体你都能快速定位、快速解决。
