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 几个我踩过的坑
第一个坑是以为换个模型名字就行，结果发现客户端缓存了旧配置，切换根本没生效，白白折腾。第二个坑是在长会话里反复切换模型，导致上下文格式混乱，反而引出新的报错。第三个坑是死等一个模型恢复，明明备用模型就在旁边闲着，非要跟热门档较劲，浪费了大量时间。
说到底，这个报错不是什么故障，而是资源调度的一种正常反馈。把它当成一个信号——提醒你该分流了、该错峰了、该整理会话了——心态上就不会那么烦躁。我现在的习惯是，只要看到这个提示，第一反应就是切备用模型，第二反应是检查当前会话是不是太长了，基本两三秒就能恢复干活，节奏几乎不受影响。
