加算力、自动续跑，Codex 连更第 11 天对付「已满负荷」报错

Codex 连更进入第二周，这一天交出的东西不是新模型、也不是额度回血，而是一个老用户再熟悉不过的报错——Selected model is at capacity，中文界面里就是「所选模型已满负荷，请尝试其他模型」。据 Tibo 的说法，这次处理分两头：一头是加算力、做改动，让这条提示少出现；另一头是改行为，提示出现时会话不再卡死，而是自动继续。仍然遇到问题的用户可以直接反馈，团队会逐个跟进。

一条拖了四个月的报错

这个问题不是这两周才冒出来的。据日本科技媒体 hashout 报道，6 月 16 日 Codex 曾出现一次集中的满负荷故障，主要波及 Medium、High 档位，Tibo 当晚在 X 上表示会在 24 小时内修复。但从后续情况看，那次修复更像止血：到 9 月，开发者社区仍有不少人反映同一条报错，有帖子称 Pro 档用户在 Terra、Sol、Astra 上轮流撞到它，而 OpenAI 状态页同期显示一切正常。

状态页「全绿」和用户「全红」同时成立，恰好说明这条报错的性质：它不是整站宕机，而是某个模型在某个时段的算力池排满了。对状态页来说服务在线，对正在跑长任务的人来说，任务就是停了。

满负荷和额度用完，是两回事

• 额度用尽：针对的是账号，你这个周期的配额花完了，换模型、重试都没用，只能等重置或升级。
• 模型满负荷：针对的是服务端，某个模型此刻的并发容量被占满，与账号还剩多少额度无关，过一会儿或换个模型往往就能过。
• 旧的麻烦：在 Codex 这种一跑就是几十分钟的代理式任务里，满负荷提示一出，会话就停在那里，人不在电脑前，任务就白等。

此前流传的应对办法也很朴素：别急着重装或清任务状态，先重试一次，不行就切模型。这次 OpenAI 把「重试」这一步收进了产品里，用户不用再守着屏幕点按钮。

自动续跑比加算力更关键

加算力能压低报错频率，但只要需求曲线继续往上走，高峰时段撞墙几乎是必然——这是所有按量供给的模型服务都绕不开的物理约束。真正改变体验的是第二点：把一次容量拒绝从「终止事件」降级成「等待事件」。对写代码的代理来说，晚两分钟完成和半路中断，完全是两种结果；前者用户多半察觉不到，后者往往意味着要重新交代上下文。

当然，Tibo 没有公开具体的扩容规模，也没说明自动续跑是在原模型上排队重试，还是会在必要时切到别的模型。如果是后者，输出质量和计费口径会不会跟着变，目前还没有官方说法，只能等后续文档或用户实测。

连更第 11 天，在修地基

回看这轮 28 天连更，前几天多是额度、功能这类看得见的「福利」，第 11 天则落在可用性这种不太好宣传的地方。它没有新闻点，却回应了 Codex 社区里抱怨时间最长的一类问题。一个产品愿意在营销周期里花一天去修报错，某种程度上也是在承认：和对手比拼的，已经不只是模型分数，而是长任务能不能稳稳跑完。至于「明显减少」到底减少多少，要看接下来几个晚高峰的真实反馈。