1. 这个报错到底在说什么如果你最近在频繁使用 Codex 这类 AI 编程助手大概率见过这句话Selected model is at capacity. Please try a different model.翻译成人话就是——你当前选中的那个模型此刻的算力池已经被占满了服务端暂时挤不出资源来处理你的请求建议你换一个模型再试。这个提示看起来像是一句简单的“稍后再试”但它背后牵扯的东西比想象中多。它不是你的网络问题不是你账号的问题也不是你代码写错了而是服务端的模型调度与容量分配机制在起作用。理解这一点非常关键因为很多人第一反应是去检查自己的网络、重启客户端、甚至怀疑是不是被封了结果折腾半天发现根本方向就错了。我先把结论摆在前面这个报错的本质是供需错配。热门模型通常是能力最强、大家最爱用的那个在高峰时段请求量远超其可用算力服务端为了保护整体稳定性会对超出容量的请求直接返回这个提示而不是让你排队等到天荒地老。所以应对思路无非两条——要么错峰要么换道要么想办法让自己少触发这个限制。这篇文章适合所有在用 Codex 做日常开发、被这个报错反复打断节奏的人。不管你是刚上手的新手还是已经用了一段时间的老用户我都会把触发原理、缓解手段、实操配置和踩坑经验讲透让你下次再看到这句话时知道该干什么而不是干瞪眼。2. 报错背后的调度逻辑拆解2.1 为什么会出现“容量已满”要缓解一个问题先得搞清楚它是怎么产生的。AI 编程助手的后端并不是一台机器在跑而是一整套模型服务集群。每个模型比如不同能力档位、不同响应速度的版本背后对应一组计算资源这组资源的并发处理能力是有上限的。当某个模型的瞬时请求数超过它的处理上限时调度层有两个选择一是让请求排队二是直接拒绝并提示换模型。Codex 选择的是后者原因也很实际——编程场景对响应延迟很敏感如果让你排队等三十秒体验可能比直接告诉你“换一个”更糟。所以这个提示本质上是一种快速失败fail-fast策略把选择权交回给你。这里有个容易被忽略的点容量限制往往是按模型维度独立计算的。也就是说A 模型满了不代表 B 模型也满。这就解释了为什么提示里明确说“try a different model”——换一个负载较低的模型请求大概率就能立刻通过。2.2 哪些行为会加速触发限制我在实际使用中总结了几类高频触发场景你可以对照看看自己中了几个高峰时段集中使用工作日的上午到傍晚尤其是整点前后是全球开发者集中干活的时间热门模型基本处于饱和状态。长上下文连续对话单次会话里塞进大量代码文件、反复追问会让每次请求的计算量变大占用资源时间更长间接提高了触发概率。频繁切换任务不重开会话一个会话里又让它改前端、又让它写后端、又让它解释算法上下文越滚越大单次请求越来越重。默认死磕同一个模型很多人配置好之后就再也没动过模型选项永远用那一个最强的自然永远撞在容量墙上。理解这几点的价值在于缓解手段不是玄学而是针对性地减少“重请求”和“扎堆请求”。2.3 换模型为什么通常立刻见效前面说了容量是按模型独立算的。不同模型的能力档位不同用的人数和场景也不同。能力最强的那一档往往是“重灾区”因为大家都想要最好的效果。而次一档或者专门优化过速度的模型负载通常低得多。这里要破除一个误区换模型不等于效果一定变差。对于很多日常任务——比如写个正则、补个单元测试、解释一段报错、生成样板代码——次一档的模型完全够用甚至因为响应更快整体体验反而更好。真正需要最强模型的场景其实是那些复杂重构、跨文件逻辑推理、疑难 bug 定位。把模型选择和任务难度匹配起来是缓解这个报错最省事的思路。3. 实操层面的一整套缓解方案3.1 方案一建立模型分级使用习惯这是我最推荐、也最根本的一条。不要把所有任务都丢给同一个模型而是按任务难度分级。下面这张表是我自己长期用下来总结的匹配关系你可以直接抄任务类型推荐模型档位理由补全单行/单函数、写正则轻量/快速档任务简单快比强重要解释报错、写注释文档轻量/快速档不需要深度推理生成样板代码、单元测试中等档需要一定理解力但不算复杂跨文件重构、架构设计最强档复杂推理值得等疑难 bug 定位最强档需要强逻辑链养成这个习惯之后你会发现撞上“容量已满”的概率大幅下降因为大部分请求都分流到了负载较低的模型上只有真正需要的时候才去挤那个热门档。3.2 方案二错峰使用与批量处理如果你确实重度依赖最强模型那就得学会错峰。根据我的观察请求高峰通常集中在工作日的白天深夜和清晨相对宽松。如果你的任务不紧急把复杂的重构、大批量的代码生成放到负载低的时段跑成功率会高很多。另一个技巧是批量处理。与其一个文件一个文件地让模型改不如把相关的几个文件一次性组织好在一个会话里连续处理完。这样虽然单次请求重但总请求数少了整体占用资源的时间反而可能更短。当然这有个度上下文太大也会拖慢响应需要自己权衡。3.3 方案三优化会话管理减少无效请求很多人没意识到会话管理本身就是一种容量优化手段。一个又长又乱的会话每次请求都要把全部历史上下文重新计算一遍等于每次都在做重复劳动既慢又占资源。我的做法是一个任务一个会话改前端就开前端会话写后端就开后端会话任务结束就关掉重开。及时清理无关上下文如果会话里已经聊了很多跟当前任务无关的内容果断新开会话别舍不得。避免反复追问同一件事想清楚再问一次把需求描述完整比来回追问五六次更省资源。这些习惯看起来是小事但累积起来能显著降低你触发容量限制的频率。3.4 方案四配置层面的自动降级思路如果你用的是支持配置的客户端可以考虑设置一个模型优先级列表或者手动准备一个“备胎模型”。当主模型返回容量提示时你能第一时间切过去而不是被打断思路去翻设置。具体做法因客户端而异但核心思路一致把常用模型按“主力 备用”两组配置好主力满了立刻切备用。有些工具支持在配置里写多个模型端点请求失败时自动尝试下一个这种就最省心。如果你的工具不支持自动切换那就手动记住备用模型的切换路径把它变成肌肉记忆。提示切换模型后如果当前会话的上下文很长建议新开一个会话再切避免上下文格式不兼容导致的额外报错。4. 常见问题与排查速查4.1 换了模型还是报同样的错怎么办这种情况说明你换的那个模型也满了或者你根本没换成功。先确认两件事一是切换是否真的生效有些客户端切换后需要新开会话才应用二是你换的模型是不是同样属于热门档位。如果连续换两三个都满那基本就是整体高峰只能错峰或者等一会儿。4.2 是不是我的账号被限流了大概率不是。账号限流通常会返回明确的配额提示而不是“容量已满”。容量提示是全局性的跟你个人账号状态关系不大。如果你怀疑是账号问题可以换个简单任务试试如果简单任务能过那就纯粹是模型负载问题。4.3 频繁重试有用吗基本没用甚至有害。容量满的时候你疯狂重试只会增加服务端压力还可能触发更严格的限流。正确做法是换模型或等几分钟而不是无脑点重试。4.4 排查速查表现象最可能原因处理方式换模型后立刻可用原模型负载高保持分级使用习惯换多个模型都满整体高峰错峰或等待简单任务也报错可能账号或配置问题检查配置与账号状态长会话频繁报错上下文过重新开会话拆分任务重试多次无效容量持续紧张停止重试切换策略4.5 几个我踩过的坑第一个坑是以为换个模型名字就行结果发现客户端缓存了旧配置切换根本没生效白白折腾。第二个坑是在长会话里反复切换模型导致上下文格式混乱反而引出新的报错。第三个坑是死等一个模型恢复明明备用模型就在旁边闲着非要跟热门档较劲浪费了大量时间。说到底这个报错不是什么故障而是资源调度的一种正常反馈。把它当成一个信号——提醒你该分流了、该错峰了、该整理会话了——心态上就不会那么烦躁。我现在的习惯是只要看到这个提示第一反应就是切备用模型第二反应是检查当前会话是不是太长了基本两三秒就能恢复干活节奏几乎不受影响。
1. 这个报错到底在说什么如果你最近在频繁使用 Codex 这类 AI 编程助手大概率见过这句话Selected model is at capacity. Please try a different model.翻译成人话就是——你当前选中的那个模型此刻的算力池已经被占满了服务端暂时挤不出资源来处理你的请求建议你换一个模型再试。这个提示看起来像是一句简单的“稍后再试”但它背后牵扯的东西比想象中多。它不是你的网络问题不是你账号的问题也不是你代码写错了而是服务端的模型调度与容量分配机制在起作用。理解这一点非常关键因为很多人第一反应是去检查自己的网络、重启客户端、甚至怀疑是不是被封了结果折腾半天发现根本方向就错了。我先把结论摆在前面这个报错的本质是供需错配。热门模型通常是能力最强、大家最爱用的那个在高峰时段请求量远超其可用算力服务端为了保护整体稳定性会对超出容量的请求直接返回这个提示而不是让你排队等到天荒地老。所以应对思路无非两条——要么错峰要么换道要么想办法让自己少触发这个限制。这篇文章适合所有在用 Codex 做日常开发、被这个报错反复打断节奏的人。不管你是刚上手的新手还是已经用了一段时间的老用户我都会把触发原理、缓解手段、实操配置和踩坑经验讲透让你下次再看到这句话时知道该干什么而不是干瞪眼。2. 报错背后的调度逻辑拆解2.1 为什么会出现“容量已满”要缓解一个问题先得搞清楚它是怎么产生的。AI 编程助手的后端并不是一台机器在跑而是一整套模型服务集群。每个模型比如不同能力档位、不同响应速度的版本背后对应一组计算资源这组资源的并发处理能力是有上限的。当某个模型的瞬时请求数超过它的处理上限时调度层有两个选择一是让请求排队二是直接拒绝并提示换模型。Codex 选择的是后者原因也很实际——编程场景对响应延迟很敏感如果让你排队等三十秒体验可能比直接告诉你“换一个”更糟。所以这个提示本质上是一种快速失败fail-fast策略把选择权交回给你。这里有个容易被忽略的点容量限制往往是按模型维度独立计算的。也就是说A 模型满了不代表 B 模型也满。这就解释了为什么提示里明确说“try a different model”——换一个负载较低的模型请求大概率就能立刻通过。2.2 哪些行为会加速触发限制我在实际使用中总结了几类高频触发场景你可以对照看看自己中了几个高峰时段集中使用工作日的上午到傍晚尤其是整点前后是全球开发者集中干活的时间热门模型基本处于饱和状态。长上下文连续对话单次会话里塞进大量代码文件、反复追问会让每次请求的计算量变大占用资源时间更长间接提高了触发概率。频繁切换任务不重开会话一个会话里又让它改前端、又让它写后端、又让它解释算法上下文越滚越大单次请求越来越重。默认死磕同一个模型很多人配置好之后就再也没动过模型选项永远用那一个最强的自然永远撞在容量墙上。理解这几点的价值在于缓解手段不是玄学而是针对性地减少“重请求”和“扎堆请求”。2.3 换模型为什么通常立刻见效前面说了容量是按模型独立算的。不同模型的能力档位不同用的人数和场景也不同。能力最强的那一档往往是“重灾区”因为大家都想要最好的效果。而次一档或者专门优化过速度的模型负载通常低得多。这里要破除一个误区换模型不等于效果一定变差。对于很多日常任务——比如写个正则、补个单元测试、解释一段报错、生成样板代码——次一档的模型完全够用甚至因为响应更快整体体验反而更好。真正需要最强模型的场景其实是那些复杂重构、跨文件逻辑推理、疑难 bug 定位。把模型选择和任务难度匹配起来是缓解这个报错最省事的思路。3. 实操层面的一整套缓解方案3.1 方案一建立模型分级使用习惯这是我最推荐、也最根本的一条。不要把所有任务都丢给同一个模型而是按任务难度分级。下面这张表是我自己长期用下来总结的匹配关系你可以直接抄任务类型推荐模型档位理由补全单行/单函数、写正则轻量/快速档任务简单快比强重要解释报错、写注释文档轻量/快速档不需要深度推理生成样板代码、单元测试中等档需要一定理解力但不算复杂跨文件重构、架构设计最强档复杂推理值得等疑难 bug 定位最强档需要强逻辑链养成这个习惯之后你会发现撞上“容量已满”的概率大幅下降因为大部分请求都分流到了负载较低的模型上只有真正需要的时候才去挤那个热门档。3.2 方案二错峰使用与批量处理如果你确实重度依赖最强模型那就得学会错峰。根据我的观察请求高峰通常集中在工作日的白天深夜和清晨相对宽松。如果你的任务不紧急把复杂的重构、大批量的代码生成放到负载低的时段跑成功率会高很多。另一个技巧是批量处理。与其一个文件一个文件地让模型改不如把相关的几个文件一次性组织好在一个会话里连续处理完。这样虽然单次请求重但总请求数少了整体占用资源的时间反而可能更短。当然这有个度上下文太大也会拖慢响应需要自己权衡。3.3 方案三优化会话管理减少无效请求很多人没意识到会话管理本身就是一种容量优化手段。一个又长又乱的会话每次请求都要把全部历史上下文重新计算一遍等于每次都在做重复劳动既慢又占资源。我的做法是一个任务一个会话改前端就开前端会话写后端就开后端会话任务结束就关掉重开。及时清理无关上下文如果会话里已经聊了很多跟当前任务无关的内容果断新开会话别舍不得。避免反复追问同一件事想清楚再问一次把需求描述完整比来回追问五六次更省资源。这些习惯看起来是小事但累积起来能显著降低你触发容量限制的频率。3.4 方案四配置层面的自动降级思路如果你用的是支持配置的客户端可以考虑设置一个模型优先级列表或者手动准备一个“备胎模型”。当主模型返回容量提示时你能第一时间切过去而不是被打断思路去翻设置。具体做法因客户端而异但核心思路一致把常用模型按“主力 备用”两组配置好主力满了立刻切备用。有些工具支持在配置里写多个模型端点请求失败时自动尝试下一个这种就最省心。如果你的工具不支持自动切换那就手动记住备用模型的切换路径把它变成肌肉记忆。提示切换模型后如果当前会话的上下文很长建议新开一个会话再切避免上下文格式不兼容导致的额外报错。4. 常见问题与排查速查4.1 换了模型还是报同样的错怎么办这种情况说明你换的那个模型也满了或者你根本没换成功。先确认两件事一是切换是否真的生效有些客户端切换后需要新开会话才应用二是你换的模型是不是同样属于热门档位。如果连续换两三个都满那基本就是整体高峰只能错峰或者等一会儿。4.2 是不是我的账号被限流了大概率不是。账号限流通常会返回明确的配额提示而不是“容量已满”。容量提示是全局性的跟你个人账号状态关系不大。如果你怀疑是账号问题可以换个简单任务试试如果简单任务能过那就纯粹是模型负载问题。4.3 频繁重试有用吗基本没用甚至有害。容量满的时候你疯狂重试只会增加服务端压力还可能触发更严格的限流。正确做法是换模型或等几分钟而不是无脑点重试。4.4 排查速查表现象最可能原因处理方式换模型后立刻可用原模型负载高保持分级使用习惯换多个模型都满整体高峰错峰或等待简单任务也报错可能账号或配置问题检查配置与账号状态长会话频繁报错上下文过重新开会话拆分任务重试多次无效容量持续紧张停止重试切换策略4.5 几个我踩过的坑第一个坑是以为换个模型名字就行结果发现客户端缓存了旧配置切换根本没生效白白折腾。第二个坑是在长会话里反复切换模型导致上下文格式混乱反而引出新的报错。第三个坑是死等一个模型恢复明明备用模型就在旁边闲着非要跟热门档较劲浪费了大量时间。说到底这个报错不是什么故障而是资源调度的一种正常反馈。把它当成一个信号——提醒你该分流了、该错峰了、该整理会话了——心态上就不会那么烦躁。我现在的习惯是只要看到这个提示第一反应就是切备用模型第二反应是检查当前会话是不是太长了基本两三秒就能恢复干活节奏几乎不受影响。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
