聊个很现实的问题你正在终端里用Codex让它把某模块的重构方案落地提示刚打了一半屏幕突然定住接着刷出一行白字Selected model is at capacity. Please try a different model.那一刻你会怎么做我见过随手连按三下回车、疯狂重试的也见过直接把窗口关了开始怀疑人生的。老实说这问题最近确实有点频繁尤其是工作日的白天基本隔一段时间就撞上一次不致命但非常打断节奏。这篇文章不打算写什么高深原理单纯把我在实际项目里摸索出的缓解方法整成一份可照做的清单。适合谁看第一类是拿Codex当日常编码搭档、被这个报错恶心过的人第二类是正在写自动化脚本、想尽量避免任务中途挂掉的人第三类是刚上手、遇到报错一脸懵、怀疑是自己账号出了问题的人。看完你至少能知道这个错到底是怎么回事现场怎么应急平时怎么防范以及如果它还是出现该怎么用更高级的姿势绕过它。1. 这个报错是什么为什么偏偏盯上你1.1 报错的典型现场它不是账号问题先明确一点看到Selected model is at capacity时绝大多数情况不是你账号被封也不是你欠费更不是网络出了故障。它是模型服务侧主动拒绝新的推理请求字面意思就是你选中的那个模型太忙了暂时腾不出算力给你建议换一个池子里的模型试试。我自己第一次遇到时也怀疑过是不是用量配额用完了后来点开用量页面发现消耗量根本没到上限这才确认是容量问题。两者的区别对你接下来的处理方式影响很大账号问题你要去检查权限、去续套餐容量问题你什么都不用动换个模型或者等一会儿就行。很多人在这里浪费了整整一下午反复检查订阅、清理缓存、重装客户端其实完全是错误的方向。更要命的是这个报错的随机性很强。同样一个任务白天撞上晚上顺滑同一个时段的同一个请求换个模型立刻就好。这种薛定谔的成功率特别容易让人抓狂但它恰恰暴露了问题的本质负载是多变的不是你的环境变了。1.2 容量报错背后的运行逻辑了解一点背后逻辑就不会乱慌。Codex背后是大量的共享推理集群这些集群按模型类型拆分资源池。假设某个模型当前同时在跑的请求数是1万集群上限就是1万那第1万个之后的请求进来服务端不会排长队等你而是直接甩一句capacity错误让你识趣点换个池子。这里有个容易误解的点capacity不是全局统一状态而是按模型、按数据中心、按时段动态变化的。同一个时间点可能重型模型很挤轻量模型很空也可能你所在的区域很挤另一个区域很空。所以try a different model不是官方的敷衍话术而是真的建议你去试负载更低的资源池。这不是什么隐藏技巧而是容量架构的基本特征。你可以把类比放得再日常一点商场周末只有一家奶茶店排队半小时起步旁边另一家没什么人。你换一家买就能立刻买到。报错就是这个意思——它没有把你拉黑只是这家奶茶店暂时产能满了。换个品牌买问题当场解决。这也是为什么企业级专用节点很少触发这个报错专用资源池是隔离出来的不跟公共流量挤。普通开发者用的公共入口波动就大很多。如果你的工作依赖Codex的连续可用性这一点早晚会让你考虑升级通道或者更灵活的任务编排方式。1.3 为什么最近感觉变频繁了如果你最近明显觉得这个报错变多正常现象。一来是模型能力更新后涌进来的用户变多二来是很多开发团队开始批量用Codex跑自动化编码任务自动化脚本一挂就是并发几十路请求把共享容量吃得更快。再叠加你所在时区的正常业务高峰就很容易撞上。从我的观察来看工作日上午十点到下午四点这个区间是最容易唱的。这个时段对应用户活跃度最高的时间段容量报错像一个峰值信号器提醒你现在全世界的开发者都在干活。明白这几层之后接下来该看的全是实操。2. 撞上报错后的应急操作止损优先2.1 第一反应切换模型试试最直接的缓解方式就是提示里那句try a different model。实际操作里我一般分两种情况还没发起请求在初始化模型的选择界面直接换一个模型比如从更重的推理模型切到轻量模型。这一步很快几秒钟就能完成。已经会话跑到一半直接在那段会话里切换不一定可行我处理的方法是尽量在新会话里重开一次对话然后一句话说明你要继续的任务让新会话接管。虽然会损失一部分上下文但好处是立刻恢复了生产力而不是干等着。注意一点不是所有模型都适合你的任务。轻量模型适合修bug、写测试用例、做小范围代码生成而重构、架构设计、长文件生成这一类的重任务还是需要在负载更高的模型下跑。所以切换的时候要结合任务复杂度临时顶一下可以重要的长任务不要硬换到完全不适配的模型上否则后续返工更浪费时间。我自己的经验是把模型按重、中、轻三个档位分好。遇到capacity时先试中档模型中档也失败再试轻档。这样既能解决眼下的问题也不会因为降级太多导致输出质量明显下滑。2.2 等待退避跟容量搏斗的正确姿势很多人的下意识动作是立刻重试而且连续点。这个做法其实最不划算。服务端的容量状态是动态的超载高峰期可能持续几分钟到半小时你在第一分钟里狂点20次可能19次都被拒。更重要的是过于高频的请求会让服务端触发你的请求流控等于你在capacity之外又给自己添了一道坎。这个教训我是真金白银换来的有一阵子我写了个循环脚本自动重试结果撞上容量高峰期脚本以每秒三次的频率连着打了几分钟不仅一个问题没解决后面还被限了大约一刻钟。我的做法是递进式等待第一次失败后等30秒再失败等2分钟再失败就直接切后台去做别的任务过10分钟再回来。这个节奏是从实际工程里的指数退避策略学来的对容量类错误尤其有效因为服务端什么时候恢复没有确定值只有随机等待才能覆盖不同峰谷乱撞只会消耗自己的耐心和配额。2.3 缩短上下文给模型减负同样一个任务上下文越短一次推理占用的算力资源越少请求被拒绝的概率也越低。Codex每次会把当前会话历史、相关文件的内容一起打包发给服务端你如果在一个会话里连续处理了2小时、塞进去好多大文件请求开销会明显变大。到了高峰期这种胖请求往往是最先被拒的那一批。实操上我做三件事用对话压缩功能把历史摘要化别让几千行历史记录继续堆着。压缩后Codex只保留关键结论丢失的细节反正也在代码里。把不相关的文件移出项目目录或者明确告诉Codex只关注某个子目录减少它自动扫描文件树的范围。如果要处理一个大文件尽量用裁剪后的相关片段去问而不是动不动把整个文件丢进去。对代码来说真正相关的可能就那几十行其余都是噪音。这个思路很快见效。我有一次连续撞了三次capacity用对话压缩加清理项目里一个无关的大数据文件后第四次请求稳稳过去了。顺带说一句精简上下文不只对避让容量有帮助对输出质量也是正向的——模型聚焦在真正相关的内容上思路清晰很多。3. 把容量问题从偶发变成可控中长期使用习惯3.1 错峰使用挑人少的时候干重活容量问题有非常明显的时段属性。我统计过自己在不同时段各个位置上的报错频率工作日白天尤其是上午十点到下午四点这个区间报错次数是晚上八点后的三倍以上。原因不复杂这个时段覆盖了多个工作时段的重叠区很多开发者在同时跑任务。所以我对重型任务的使用策略是能在晚上跑就放晚上能在凌晨跑就扛到凌晨。如果你手里有那种需要连续跑很久的自动化编码任务挑安静时段挂上会舒服很多。白天的时间段留给轻量请求、临时答疑、简单改动这类请求就算撞容量代价也很小。这个习惯带来的额外好处是夜间网络通常也更稳定请求响应速度更快。我甚至会把一些需要反复试验的任务安排在晚上统一跑早上起来收拾结果效率和体验都好很多。3.2 任务拆分小步快跑比一次梭哈更抗造我见过一种典型的失败姿势一句话让Codex把整个订单模块重构掉加上单元测试然后更新API文档和迁移脚本。结果任务跑到一半撞上capacity整个上下文全废不光没结果前面的进展也丢了。这种大而全的指令对于容量波动非常脆弱因为单次请求负载大等待时间长任何抖动都可能导致任务失败。正确方式是把它拆成一个小步走、一步一确认的流程第一步帮我梳理当前模块的结构和问题点第二步针对问题点列出三种重构方案第三步选定方案A先改核心业务逻辑部分第四步为改完的部分补充测试用例第五步更新模块对应的文档每一步都是独立的短会话单位请求的负载小撞容量的概率比长任务低很多。即便某一小步失败重新发起也就损失几秒钟不需要重新养一个庞大的上下文。这个模式我用了很久成功率提升非常明显也不再害怕任务中途断掉。3.3 请求节奏管理给自动化脚本装上节流阀如果你自己写了脚本批量调用Codex不加节流就相当于无保护地冲击共享资源池。容量错误只是最快暴露问题的方式再往后可能就是限流。我在批量调用时一定会做三件套请求间隔两次请求之间至少停顿0.5秒随机上限到2秒用随机抖动防止多个任务在同一时刻爆发。这个随机抖动很重要如果所有任务都在固定的1秒后发起很容易形成共振让服务端在那一瞬间压力骤增。任务队列用一个简单的队列把任务串行或限制为2~3个并发而不是一口气全发出去。队列的另一个优势是方便记录每个任务的状态失败时能单独重试而不影响其他任务。失败重试策略遇到capacity错误时按指数退避等待不要立刻重发同一个请求。这个重试策略要单独写跟普通网络错误区别开网络错误可以相对快一点重试容量错误必须拉长间隔。这套节流阀让我的自动化任务中断率下降了很多。以前一批任务跑下来能完成五六成就算运气好现在基本能稳定在九成以上剩下的偶发失败也会被重试机制自动消化掉。4. 进阶排查用环境优化和日志分析把问题量化4.1 网络质量别让网络背锅也别让它添乱capacity错误本身是服务端状态不是网络问题。但网络质量差会让整个交互链条变脆弱比如请求在传输中被截断、重连时被调度到其他节点、超时后你误以为服务端还没回复而重复发请求这些都会放大容量问题带来的影响。我自己的检查方法很简单选择一个稳定的公共地址做连通性测试跑一段时间ping看延迟和丢包率。如果丢包率超过1%网络稳定性就比较差了如果平均延迟比平时高一倍以上也说明这条链路不健康。换一个更稳定的网络环境能减少一些莫名其妙的连带问题。另外注意你本地如果跑了很多占用带宽的东西比如大体积仓库同步、镜像拉取、视频通话也可能挤占网络资源。这些对自动化任务的实时性影响是实打实的。我在跑长任务前会先把这些占带宽的应用关掉保证Codex请求的通道尽量干净。4.2 抓日志统计你的专属容量规律Codex支持调试日志模式打开之后会在日志文件里记录每次请求的HTTP状态码、耗时、重试次数、模型标识。我推荐用这些日志做一件很有价值的事量化自己撞容量的规律而不是每次都凭感觉判断。我写过一段很简单的Python脚本读取日志文件用正则把Selected model is at capacity这一类错误出现的行按照小时聚合画一个粗糙的频率分布。跑一周之后数据会告诉你三件事一天里哪些时段对你来说最容易撞容量哪些模型在你这个项目上的失败率最高上下文体积阈值在哪里超过多少规模开始容易失败。有了这些数据你就是在用数据调度任务而不是靠运气。我后来排任务调度前都会先扫一眼自己的历史错误分布直接把关键任务放到低谷时段去跑效果立竿见影。import re from collections import Counter from datetime import datetime # 假设日志每行格式类似2025-01-01 10:23:45 ERROR capacity: Selected model is at capacity log_pattern re.compile(r(\d{4}-\d{2}-\d{2} \d{2}):.*(capacity|error|retry), re.IGNORECASE) def analyze_log(log_path): hourly Counter() with open(log_path, encodingutf-8, errorsignore) as f: for line in f: m log_pattern.search(line) if m: ts datetime.strptime(m.group(1), %Y-%m-%d %H) hourly[ts.strftime(%A %H:00)] 1 return sorted(hourly.items()) if __name__ __main__: for slot, count in analyze_log(codex.log): print(f{slot}: {count} 次)这段脚本很粗糙但够用。核心思想是把日志变成趋势让自己对容量问题有预期而不是每次都被突然袭击。4.3 自动化重试脚本把应急动作写进代码如果你用的是API方式接入Codex完全可以把遇到capacity就切换模型等待退避的逻辑写成一个可复用的函数。下面是我常用的一个Python示例思路import time import random import requests def safe_request(url, payload, model_priority): models list(model_priority) for attempt in range(6): model models[attempt % len(models)] body {**payload, model: model} try: resp requests.post(url, jsonbody, timeout60) if resp.status_code 200: return resp.json() if capacity in resp.text.lower() and attempt len(models) - 1: print(f模型 {model} 容量不足等待后切换) else: return {error: resp.text} except Exception as e: print(f请求异常{e}) time.sleep(2 ** attempt random.random()) return {error: all retries exhausted}这个脚本的核心思路就是模型列表按优先级排好碰到capacity就切下一个模型等待时间按2的指数增长加上随机抖动。实际用下来非常稳尤其是夜间无人值守的任务。你可以把model_priority传成[重模型, 中模型, 轻模型]这样即使重模型一直满负载也会自动滑落到轻模型把任务跑完。注意重试逻辑里不要对普通网络错误使用同样的切模型策略网络错误应该固定重试等待容量错误才切换模型。两者的处理方式混在一起会导致真正的网络问题被掩盖甚至把容量问题误判成网络问题排查时南辕北辙。4.4 账号与配额体检排查到最后还得排除账号因素。区分方法很简单直接看报错文本提示认证失败、登录过期账号层面有问题提示用量配额不足、达到月度上限套餐用量问题提示capacity、try a different model纯粹容量问题。我建议固定一个周期检查登录态和用量别在自己毫不知情的情况下把容量问题和账号问题混在一起。特别是自动化脚本长期挂着的时候可能一次登录态过期就会让之后的所有请求都以另一种报错形式失败你要是只盯着capacity看永远找不到原因。做一次体检把账号状态、用量、模型可用列表都过一遍后面能省掉很多无谓的排查。5. 对照速查与实战心得5.1 常见问题对照表表现直接原因推荐动作请求发出后立刻返回capacity当前模型资源池超载切换到其他模型结合任务复杂度选择替代模型连续多次重试仍然报错高峰期持续且重试频率过高停止重试等10分钟再用递减间隔重试同一会话内越到后面越容易触发上下文膨胀导致单请求负载变高压缩对话历史缩小讨论范围工作日上午集中出现共享资源池到达业务高峰把重活错峰到夜间或清晨长任务跑到一半断掉单次任务时间过长上下文过重任务拆分为多个短会话逐步推进偶发性、单次报错服务端负载瞬时抖动直接重试一次即可不必过度反应不同模型报错率差异大各模型资源池规模和热度不同记录各模型的失败率形成自己的优先级列表脚本批量任务频繁中断并发过高、无退避重试策略降低并发、增加随机间隔、用指数退避5.2 实战心得与习惯沉淀这个报错我真的踩了挺多次现在已经不太会被它激怒了。最后分享几个沉淀下来的习惯第一我把防容量问题纳入了任务规划。接到大的自动化任务先看时间是不是高峰期高峰期就主动拆小任务或者干脆把任务排期到安静时段。这不是什么复杂技术但确实让我的成功率提高了一大截。第二我的重试等待曲线是固定的30秒、2分钟、10分钟、30分钟四级退避。超过30分钟还报错我就默认是全局性故障直接停手去做别的事。从时间成本来讲这个策略比以前的手忙脚乱高效得多至少不会在无效重试上浪费一个小时。第三对Codex不要有一次问到底的执念。它最好的使用方式是当好一个高频、短对话、快速反馈的助手而不是一次性解决所有问题的神谕。短对话对容量问题的免疫力天然更高出了问题重启成本也极低就算偶尔撞上一次也就是重新念一遍需求的功夫。第四如果手头有多个模型可选把它做成一个循环列表失败时自动转下一个这是成本最低的高可用方案。哪怕只是手动操作把模型从重到轻排个序依次试也比死磕一个模型明智。5.3 配套自动化流水线的额外建议如果你在持续集成或者定时任务里使用Codex还要额外考虑失败的缓释。我的建议是在流水线里给这类型任务设置独立的超时和错误容忍度别让一个容量错误把整条流水线打红。具体做法是把Codex相关步骤标记为可重试步骤单独配置重试次数失败后发送一条消息让当值的人知道但不用立刻介入并且把当时的上下文和日志自动存档方便事后分析。我还尝试过把一天的Codex任务集中到一个队列里按优先级排序遇到容量就整体切到备用模型。这套东西跑下来整个团队的效率都不再受制于某个模型的临时状态大家也不会因为偶发报错频繁打断思路。说到底容量问题是服务架构的一部分我们控制不了服务端但能控制自己的调度策略和任务形态。这个报错不会彻底消失但完全可以被驯化。把我的这套方法试一遍你的中断率应该会明显降下来它还在你就已经有完整的应对预案了。
