📦 静态快照模式
返回 Vibe
🎵 Vibe 置顶 • 2026-06-25 12:35

OpenAI "Selected model is at capacity" 报错事件调查：GPT-5.5 容量瓶颈、官方响应与社区信任落差

OpenAI "Selected model is at capacity" 报错事件调查：GPT-5.5 容量瓶颈、官方响应与社区信任落差 调查时点：2026 年 6 月 25...

BenszConan 的头像

BenszConan

管理员

文章目录 ⌄

OpenAI "Selected model is at capacity" 报错事件调查：GPT-5.5 容量瓶颈、官方响应与社区信任落差

调查时点：2026 年 6 月 25 日（北京时间，UTC+8） 调查者：deep_research 深度研究写作系统 资料截至：2026 年 6 月 25 日上午（社区与状态页快照） 引用说明：正文中出现的 [^n] 为可溯源脚注，对应文末「参考文献」条目；每条均标注作者/标题/来源/日期/链接，读者可逐句回溯。

当前可用的临时缓解方案

在进入详细分析之前，先给出当前最实用的一条即时对策：在 GPT-5.5 容量报错持续期间，把 Codex 的模型切换到 GPT-5.4 的 Medium 或 High 档位，可以部分缓解问题。

背后的逻辑很直接。报错集中在 GPT-5.5 系列，尤其是算力消耗最大的 xHigh 与 High 两档[^3]；而 GPT-5.4 作为上一代主力，随着调用密度向 5.5 迁移，它所占用的推理槽位相对宽松，撞上容量墙的概率明显更低。社区里大量用户的实际做法正是"切回 5.4 继续干活"[^7]，最早开帖报错的 Pro 用户也是切回 5.4 后才恢复工作[^4]。之所以建议 Medium/High 而非 xHigh，是因为 xHigh 无论对 5.5 还是 5.4 都是算力消耗最大、最易满载的档位；降到 Medium/High 既能保留大部分编码能力，又能显著降低被 capacity 拒绝的概率。

需要诚实说明：这只是部分缓解，不是根治。其一，GPT-5.4 在高峰时段同样可能偶发 capacity 报错，只是概率远低于 5.5；其二，5.4 的编码能力整体弱于 5.5，作为应急 fallback 合适，作为长期替代则要权衡质量损失。把它当作"等 5.5 容量平息期间的过渡方案"，比期待它彻底解决问题更现实。配合错峰使用、避免长会话触发后台压缩任务[^5]，效果会更稳定。

核心结论

"Selected model is at capacity. Please try a different model."（所选模型已满载，请尝试其他模型）这条报错，在过去两天（6 月 23—25 日）被大量用户密集遇到，并在最近一小时左右达到体感高峰。但把这件事说成"OpenAI 今天突然宕机"是不准确的。综合 OpenAI 官方状态页[^1]、开发者社区[^3][^4]、GitHub[^5]、Reddit[^7] 与第三方监控[^8][^9] 的交叉证据，更接近事实的判断是：

这是一条集中在 Codex 产品线、主要针对 GPT-5.5 系列模型的容量报错[^3][^5]，它从 2026 年 4 月底就开始反复出现[^4]，6 月是高发期[^1]，6 月 16 日 OpenAI 第一次为它单独开了一个官方事件并标记"已恢复"[^2]，但报错此后从未真正消失[^3]。用户在过去两天密集遇到、并在今天上午感到高峰，是这条长尾问题与 6 月 24 日 gpt-4o-mini 高错误率事件、已持续整整一周的 FedRAMP 降级[^1] 叠加之后的综合体感。

换句话说，这不是一次孤立的"今天的事故"，而是一个已经持续近两个月、在 6 月明显恶化的结构性容量问题的一次新高潮。它的底层是 GPT-5.5 在 Codex 中大规模铺开后，推理算力供给跟不上需求增长[^12]；与此同时，OpenAI 还在悄悄下调 GPT-5.5 的使用配额、压缩其上下文窗口[^7]，这些动作与"容量不足"的报错共同塑造了用户当下强烈的受挫感。

报告最值得记住的一点是一个信任落差：OpenAI 官方状态页的时间线，系统性地滞后于用户实际遭遇故障的时间[^3]；而状态页上的"已恢复"，往往只意味着大规模爆发已经过去，零星的容量报错仍在持续——这一点 OpenAI 自己在状态页脚注里也间接承认了[^1]。

这条报错究竟在说什么

要理解过去两天发生了什么，先要把这条报错本身拆清楚。

它不是 ChatGPT 网页版的通用"出错了，请重试"，也主要不是 API 层面的速率限制（rate limit，即"你调用太频繁了，每分钟超过配额了"）。它是 Codex 产品线（包括 Codex 桌面应用、Codex CLI、Codex Cloud 任务、IDE 扩展等）在请求某个具体模型、而该模型当前总的可用推理槽位被占满时返回的一条面向人类的提示[^3][^5]。关键词是 capacity（容量），而不是 quota（配额）或 rate limit（速率）：

  • 配额（quota）：你的账户这周还能用多少 token、多少次消息——这是账户维度的额度。
  • 速率（rate limit）：你的请求在单位时间内是否超过门槛——这是流量维度的限制。
  • 容量（capacity）：OpenAI 后端为某个模型分配的总推理资源（GPU、推理实例、并发槽位）此刻是否够分给你——这是基础设施维度的供给。

三者最大的区别在于：当报错是 capacity 时，即便你的账户配额还剩 99%、本周一次都没怎么用，你也照样会失败。这一点在 Reddit r/codex 上被反复印证——一位 Pro 用户在报告该错误时特意说明，/status 显示他的周配额还剩 99%、日配额还剩 93%、上下文还剩 7%，却依然被"Selected model is at capacity"挡在门外[^7]。这恰好排除了"是不是我把额度用完了"的自我归因，把问题指向了 OpenAI 侧的供给。

理解了 capacity 的含义，就能理解为什么这条报错的"恢复"会比想象中慢、为什么官方状态页说"已恢复"之后用户依然会遇到它——因为容量是一个随实时负载波动的动态状态，而不是一个可以一次性修好的开关。

官方时间线：六月的高密度事件与"已恢复"的真相

六月的每一天几乎都有事故

OpenAI 状态页（status.openai.com）的历史记录是这份调查最可靠的一手骨架[^1]。把 2026 年 6 月的官方事件按时间排列，会得到一条异常密集的事故带（时间为太平洋时间 PT，换算成北京时间需加 15 小时）：

日期 官方事件 状态
6 月 24 日（周三） gpt-4o-mini 高错误率 已恢复
6 月 23 日（周二） ChatGPT 上传/下载文件高错误率 已恢复
6 月 19 日（周五） chatgpt.com 访问问题 已恢复
6 月 18 日（周四） FedRAMP 工作区与 API 组织性能降级 仍在调查，已持续一周
6 月 18 日（周四） ChatGPT 企业版 SSO 登录错误 已恢复
6 月 18 日（周四） ChatGPT 无法加载或保存 已恢复
6 月 17 日（周三） Android/iOS 会话错误 已恢复
6 月 16 日（周二） Codex "所选模型已满载"错误 已恢复
6 月 16 日（周二） Codex Cloud 任务问题 已恢复
6 月 15 日（周一） OAuth 账号创建/登录错误 已恢复
6 月 12 日（周五） 431 错误激增 已恢复
6 月 11 日（周四） Codex 中 GPT-5.5 错误率升高 已恢复
6 月 11 日（周四） Free/Go 用户服务中断 已恢复
6 月 8 日（周一） Go 用户服务中断 已恢复
6 月 7 日（周日） Free/Go 用户服务中断 已恢复
6 月 6 日（周六） 部分用户账号访问异常（含误封号后恢复） 已恢复
6 月 5 日（周五） 语音模式、微软账号登录、Free 用户会话错误 已恢复
6 月 4 日（周四） Image API 401、Codex 上下文压缩延迟 已恢复
6 月 3 日（周三） Codex/ChatGPT/Responses API 错误率升高、ChatGPT Pro 错误、codex-gpt-image-2 错误 已恢复
6 月 2 日（周二） 访客用户会话错误率升高 已恢复
6 月 1 日（周一） Free 用户 ChatGPT 可用性下降 已恢复

一个月里几乎每一天都有事件，且 GPT-5.5 与 Codex 相关的条目反复出现（6 月 3、4、11、12、16 日）[^1]。这是理解"为什么最近两天特别明显"的重要背景——用户感知到的不是一次突然崩塌，而是一条长期高水位事故带在 6 月下旬的又一次抬头。

需要特别说明这张表的统计口径。状态页首页同时给出了 3—6 月的聚合可用性：API 为 99.98%、Codex 为 99.96%、FedRAMP 为 99.96%，而 ChatGPT 只有 99.80%——明显低于其他服务[^1]。也就是说，从官方自己的指标看，ChatGPT 这条线在过去一个季度里确实是相对最不稳定的。但更关键的是状态页脚注里那句话："可用性指标是在所有层级、模型和错误类型的聚合层面报告的。单个客户的可用性可能因其订阅层级以及所使用的具体模型和 API 功能而异。"[^1]——这句话等于官方预告了"你看状态页一切正常，但你本人就是用不了"这种情形是存在的、且在预期之内。

6 月 16 日：报错第一次有了自己的官方名字

在所有这些事件里，6 月 16 日那条最值得关注，因为它第一次把这条报错升格为一个有正式名称的官方事件——"Codex 'Selected Model is at Capacity' Error"（Codex"所选模型已满载"错误）[^2]。

该事件的详情页记录如下[^2]：

状态：已识别（Identified）· 性能降级 "我们已确认用户在受影响服务中遇到错误率升高。我们正在着手实施缓解措施。" 时间：2026 年 6 月 16 日，星期二，18:32（北京时间，UTC+8）

也就是说，6 月 16 日北京时间傍晚，OpenAI 正式承认了这个错误的存在，并表示正在处理[^2]。状态页历史显示，该事件在同一天晚些时候（太平洋时间 13:48）被标记为"所有受影响服务已完全恢复"[^1]。

但真正重要的不是这条事件本身，而是它之后发生的事——这是本报告的核心发现。

今天（6 月 25 日）官方状态页上写着什么

把视线拉回今天。截至本报告资料采集时点（北京时间 6 月 25 日上午），OpenAI 状态页首页显示[^1]：

  • 顶部横幅："我们当前正在经历问题"。
  • 唯一被列为"进行中"的事件，是 FedRAMP 工作区与 API 组织性能降级，状态为"仍在调查中"，已持续一周——也就是说它从 6 月 18 日开始，一直拖到了 6 月 25 日[^1]。
  • 与"Selected model is at capacity"直接相关的官方事件（6 月 16 日那条），早已不在进行中列表里[^1]。

这里出现了一个对本次调查至关重要的矛盾：

用户在过去两天密集遇到、并在最近一小时感到高峰的，正是"Selected model is at capacity"这条报错；但 OpenAI 官方状态页上，与这条报错同名的官方事件在 6 月 16 日就标记"已恢复"了[^1][^2]，今天的状态页上根本没有一条与之对应的、正在进行的事件。

这个落差不是报告可以含糊带过的细节，它本身就是结论的一部分。下面专门解释它。

用户体感与官方记录的落差

"最近两天明显、最近一小时高峰"如何解释

用户提供的体感是：过去两天报错明显增多，最近一小时达到高峰。今天是北京时间 6 月 25 日。

如果只看官方状态页，对"最近两天"最接近的对应物是：6 月 24 日的 gpt-4o-mini 高错误率、6 月 23 日的 ChatGPT 文件上传/下载错误，以及从 6 月 18 日起持续至今的 FedRAMP 降级[^1]。但严格地说，这些官方事件没有一条的名字是"capacity"，而且前两条都已被标记为"已恢复"[^1]。

那么用户的体感从何而来？把多个来源的线索拼起来，至少有三股力量在共同作用：

第一股，是 6 月 16 日事件之后从未真正平息的尾部报错。 OpenAI 开发者社区里专门追踪这条报错的主帖（编号 1383863，标题就叫"Selected Model is at capacity... June 16th, 2026"）一直处于活跃状态，由社区领袖 VeitB 维护[^3]。在状态页宣布"已恢复"之后，仍有大量用户回帖报告问题仍在持续，措辞是"Still Not Resolved"（仍未解决），还有人写道"同一问题，一小时前遇到过一次，现在又来了，Codex Mac 版，GPT-5.5 High"[^3]。这些回帖的时间，恰好落在 6 月 23 日前后——也就是用户所说的"最近两天"。更说明问题的是另一个更早的社区帖（编号 1379767，标题"GPT 5.5 - Selected model is at capacity"），它从 4 月 25 日就开帖，直到约 20 小时前（即 6 月 24 日左右）才被关闭[^4]。一个开了两个月的报错帖，直到 6 月 24 日还在更新、才关闭，这本身就是"问题长期持续、直到最近仍在发生"的硬证据。

第二股，是今天上午（北京时间）对应的北美晚间时段。 用户说的"最近一小时高峰"，发生在北京时间 6 月 25 日上午 11 点前后，换算成美西太平洋时间是 6 月 24 日晚上 20 点前后、美东时间是 6 月 24 日深夜 23 点前后。这虽然不是北美工作日的日间峰值，但恰恰是亚太地区（含中国）开发者进入工作时段、而 OpenAI 后端在美国进入夜间维护或负载迁移的时段，亚太用户的报错感知在这个窗口容易被放大。

第三股，是多重官方事件叠加带来的整体不稳。 即使"capacity"报错本身在状态页上没有新事件，但 6 月 24 日 gpt-4o-mini 高错误率、6 月 23 日文件上传/下载错误、持续一周的 FedRAMP 降级、6 月 17 日的移动端会话错误等[^1]，叠加在一起，足以让一个连续几天都在和 OpenAI 服务打交道的用户产生"这两天到处都是报错、刚才那一小时尤其密集"的强烈印象。用户的体感是真实的，只是它的成因比"某一条事故"要复杂；6 月中旬也有媒体记录到 ChatGPT 用户问题反馈的集中爆发[^14]。

为什么"已恢复"之后报错仍在继续

这是本次调查最需要讲清楚的一点，也是用户最容易产生被误导感的地方。

OpenAI 状态页上的"已恢复（All impacted services have now fully recovered）"，指的是受影响服务在聚合层面恢复——即大规模、可复现的错误率升高已经回落到阈值以下[^1]。但 capacity 这类报错的特殊性在于：它本质上是瞬时容量调度失败，只要某个时刻涌入该模型的并发请求超过当下分配的推理槽位，它就会再次发生，哪怕整体错误率已经"正常"。

社区帖里一位用户 RoMango 的理解是准确的："这意味着所选模型当前过载，服务似乎没有为这个模型腾出空闲容量。"[^3]——它是一个会随负载波动、随时可能复发的状态，而不是一个被"修好"就永久消失的 bug。这正是为什么 6 月 16 日标记"已恢复"之后[^1]，6 月 23—24 日仍有用户在持续报告它[^3]。

再加上状态页首页脚注那句"单个客户的可用性可能因其订阅层级以及所使用的具体模型和 API 功能而异"[^1]，等于 OpenAI 自己留好了口径：聚合指标恢复正常，不等于每一个用 GPT-5.5 xHigh 的 Pro 用户都不再遇到 capacity 报错。这是官方话术与用户体感之间最关键的缓冲地带。

状态页滞后于真实故障：社区的核心批评

在 6 月 16 日那条主帖里，一位名叫 timore 的用户写下了一段被社区广泛认同的批评，它精准地概括了用户对 OpenAI 沟通方式的不满，也解释了为什么"看状态页"这件事正在失去可信度[^3]：

"我完全理解大型平台会出现服务中断或性能下降，这是正常的。但我想指出的是，根据 OpenAI 状态页，事件似乎最近才开始；然而根据社区里的用户反馈和我自己的体验，问题在几个小时前就已经开始了。……更广泛地说，我认为很重要的一点是：这些事件不应该看起来像是等社区开始报告之后才被发现的。理想状态下，应该让人感觉 OpenAI 早就监测到了性能下降、正在积极处理、并持续告知用户进展。"

这段话提出了两个具体诉求：一是希望公开的事件时间线更接近真实故障起点，而不是滞后几小时；二是希望提供更主动的检测、概略的恢复时间（ETA）和更详细的更新[^3]。这两个诉求之所以有代表性，是因为它们道出了所有"最近一小时高峰"用户的共同困境——当报错突然密集出现时，用户无法判断这到底是本地网络问题、临时抖动、还是已经被官方知晓的已知事件，只能靠社区互助来拼凑真相。

timore 的批评在本次事件中得到了充分印证：状态页把 6 月 16 日事件的开端标在傍晚[^2]，但社区反馈显示问题在几小时前就已开始[^3]；而 6 月 23—25 日用户密集遇到的 capacity 报错，在状态页上根本没有对应的进行中事件[^1]。状态页的盲区，恰恰是用户体感最强烈的区域。

机制：GPT-5.5 为什么总是"容量不足"

理解了"发生了什么"，接下来要回答"为什么会这样"。capacity 报错的根源，是 GPT-5.5 这个模型在 Codex 中的供需严重失衡。

需求侧：GPT-5.5 成为 Codex 默认主力，调用密度激增

GPT-5.5 是 OpenAI 在 2026 年 4 月推向 Codex 的主力编码模型。状态页 4 月 23 日的事件记录写道："GPT-5.5 现已向 Codex 中所有付费用户开放。"[^1] 从那时起，它就成了 Codex 用户（尤其是重度编码的 Pro 用户）的默认选择。

GPT-5.5 提供多个推理强度档位（在 Codex 中体现为 xHigh/High/Medium/Low 等），其中 xHigh 和 High 两档是最受开发者欢迎、也是对算力消耗最大的。社区反馈里反复出现的报错配置，几乎都是 "GPT-5.5 xHigh" 或 "GPT-5.5 High"[^3]。一个直观的对比是：xHigh 档每处理一个 prompt 所消耗的算力远高于低档位，当大量 Pro 用户同时选择最高档位时，分配给该档位的推理槽位会在高峰时段被迅速占满，于是 capacity 报错集中爆发在 xHigh/High 上。

6 月还有一个催化因素：媒体报道显示，OpenAI 在 6 月对 ChatGPT 进行了史上最大规模的一次改版，其中一个明确重点是加码编码产品 Codex[^11]。这意味着 Codex 的入口被进一步打开、新用户和新调用量涌入，需求曲线在 6 月又被抬高了一截。

供给侧：算力账单压顶与配额的悄悄调整

需求在涨，供给却在收紧。这是容量矛盾激化的另一半。

算力成本方面，国内媒体（证券时报）在报道 OpenAI 时使用了"算力账单压顶"的表述[^12]——它指出了 OpenAI 在 2026 年面临的现实压力：模型越智能、推理越深，单次调用的算力成本越高。在成本与产能受限的双重约束下，OpenAI 不可能无限制地为所有档位提供充裕的实时容量。

更敏感的是，社区在 6 月密集发现 OpenAI 对 GPT-5.5 的配额和上下文进行了低调调整[^7]：

  • Reddit r/codex 上出现标题为"OpenAI 悄悄把 Codex（gpt-5.5）的配额削减了 10—20 倍"的讨论，Plus 和 Pro 用户都反映自己的使用限额在单次交互后从 99% 掉到 67%[^7]。
  • 有用户发现 GPT-5.5 原本宣传的 1M（百万）token 上下文窗口，对 Pro 订阅被服务端硬性压缩到了约 40 万总 token / 27.2 万输入 token[^7]。
  • 多个帖子抱怨 GPT-5.5 的使用限额"荒唐"，甚至有 Medium 模式用户只发了两条消息就触顶 100%[^7]。

这些动作和 capacity 报错是不是同一回事？严格地说，它们是两个层面：配额下调是"你能用多少"的账户策略，capacity 报错是"此刻系统够不够分给你"的实时供给。但二者在用户端会叠加成同一种受挫体验——"我花钱买了 Pro、配额又被人悄悄砍、真要用的时候还告诉我容量满了"。从机制推断，配额与上下文的收紧，本身也可以是 OpenAI 在算力紧张时管理需求侧的手段之一：用更低的配额和更短的上下文，来压低每个用户对推理槽位的占用，从而缓解 capacity 压力。如果是这样，那么"配额被砍"和"报错变多"就可能是同一个降本保供策略的两面。

需要强调，以上对配额调整的解读来自社区反馈与媒体报道[^7]，OpenAI 并未公开发布"我们下调了 GPT-5.5 配额"的正式公告，这部分属于社区观测+合理推断，在引用时应保留必要的不确定性。

capacity 与 rate limit 是两回事

把前面两层叠加起来，就回到了一个对用户最有用的判断：遇到这条报错时，不要先怀疑自己账户的问题。

如果是配额（quota）问题，/status 会显示你的额度已经见底；如果是速率（rate limit）问题，降低请求频率、错峰使用就能解决。但 capacity 报错的标志恰恰是——/status 显示你额度充足、请求频率也不高，却仍然失败[^7]。这意味着问题在 OpenAI 的供给侧，用户侧能做的只有：换一个负载更低的模型档位（比如从 xHigh 降到 High/Medium）、等待高峰过去、或切换到 GPT-5.4 等其他模型。社区帖里多个用户的实际做法正是如此——"切回 5.4 继续干活"、"换成 5.3 Medium 就好了"[^7]。

报错的高发场景：上下文压缩任务

GitHub 上 openai/codex 仓库的 issue 编号 28303，提供了一个关于报错触发场景的重要技术线索[^5]。该 issue 标题是"Error running remote compact task: Selected model is at capacity"，由一位 Plus 用户在 6 月 15 日提交（即 6 月 16 日官方事件的前一天）[^5]。它的关键在于 "remote compact task"（远程压缩任务） 这个词。

Codex 在长会话中会执行"上下文压缩（compaction）"——当对话历史接近上下文上限时，系统在后台发起一次远程压缩任务，把旧上下文摘要化，腾出空间。而这个压缩任务本身也要调用 GPT-5.5。也就是说，用户往往不是在主动发消息时报错，而是在会话已经很长、系统自动触发后台压缩时，压缩请求撞上了容量墙[^5]。这就解释了为什么社区里很多用户的描述是"会话跑了好几个小时、突然就报 capacity、之后再也无法用这个模型"——长会话的后台压缩需求，恰恰是高峰时段最容易被 capacity 拒绝的请求类型[^3]。GitHub 给该 issue 打的标签也印证了这一点：app、bug、context（上下文管理，含压缩）、rate-limits[^5]。

这不是新问题：从四月到六月的长尾

如果只盯着 6 月 16 日那条官方事件，会误以为这是一个 6 月才出现的新故障。把时间轴拉长，会发现这是一条至少从 4 月底就开始的长尾（GitHub 上 openai/codex 的相关 issue 也早在 4 月就有开发者集中上报，如 #19583）[^6]。

OpenAI 状态页的更早记录里，GPT-5.5 在 Codex 中的错误率问题几乎贯穿了整个 5 月[^1]：

  • 5 月 1 日、5 月 8 日（多次）、5 月 11 日、5 月 13 日、5 月 17 日、5 月 20 日、5 月 21 日，都出现了与 GPT-5.5、Codex、Responses API 错误率相关的事件，措辞包括"Increased Error Rate for gpt-5.5 model in the API"（5 月 8 日）、"Elevated error rates with GPT 5.5"（5 月 11 日）、"GPT5.5 Performance Degradation"（5 月 17 日）、"Elevated errors on model gpt-5.5 in codex"（4 月 24 日）等[^1]。
  • 与之呼应，社区最早的专门报错帖 1379767 开帖于 4 月 25—26 日：一位 Pro 200 美元账户用户报告，他的 GPT-5.5 xHigh 会话在连续工作 3 小时 9 分 39 秒后突然报"Selected model is at capacity"，此后每一次 GPT-5.5 对话都报同样的错，他不得不切回 5.4 xHigh 才能继续[^4]。这个帖子获得了近 3900 次浏览，直到 6 月 24 日左右才被关闭[^4]。

把这条线连起来：4 月底首爆 → 5 月几乎每两三天一轮 → 6 月 3 日、11 日、16 日连续升级 → 6 月 16 日首次获得官方正式事件名 → 6 月 23—25 日用户仍在密集报告。[^1][^4][^3] 这是一个持续了近两个月、反复发作的结构性问题，6 月 16 日只是其中被官方正式点名的一个高点，而不是起点，更不是终点。

理解了这条长尾，就能理解为什么用户的"最近两天高峰"既真实、又不应该被简单当成"突发事故"来对待——它是一条长期曲线的又一次上扬。

利益相关方：谁在被影响

个人开发者与 Pro/Plus 订阅者

受影响最直接、声音最大的，是 Codex 的重度个人用户，尤其是 Pro（含 20x、200 美元档）和 Plus 订阅者。社区帖里反复出现的配置是"GPT-5.5 xHigh/High + Pro 账户"[^3]。这类用户的工作流高度依赖 Codex 的长会话编码能力——他们让 Codex 并行处理多个模块、连续跑几个小时。一旦 capacity 报错出现，长会话中断、上下文压缩失败、被迫降级到 5.4 或更低档位，工作效率直接打折。社区里一位用户的话很有代表性："我刚买了 20x Codex，三小时后就用不了了，体验太令人失望了。"[^3]

更让这个群体不满的是付费与体验的错位：他们支付了顶级订阅费用，却换来配额被悄悄下调、上下文被压缩、高峰期还频繁遇到容量报错[^7]。Reddit 上"OpenAI 正在流失开发者"的情绪，正是从这个群体中发酵出来的[^7]。

团队与企业用户

企业版（Enterprise）、商业版（Business）和 FedRAMP（面向美国政府的合规版本）用户是另一个受影响群体，且他们的问题更"硬"。状态页显示，FedRAMP 工作区与 API 组织的性能降级从 6 月 18 日起一直持续到 6 月 25 日，整整一周仍在调查中——这是目前官方状态页上唯一一个"进行中"的事件[^1]。此外，6 月 18 日还出现过 ChatGPT 企业版 SSO 登录错误、ChatGPT 无法加载或保存等事件[^1]。对企业用户而言，这类持续性的降级比瞬时 capacity 报错更棘手，因为它影响的是团队协作和数据可靠性，且迟迟得不到解决。

OpenAI 自身

OpenAI 在这一轮事件中扮演的是"承压方"的角色。它面对的是一组难以同时满足的约束：GPT-5.5 的强劲需求、居高不下的推理算力成本[^12]、传闻中即将到来的 GPT-5.6 发布所需的容量预留[^15]、以及企业合规版（FedRAMP）的稳定性承诺[^1]。状态页的高密度事件、配额与上下文的低调调整[^7]、以及"聚合恢复但个体仍报错"的官方口径[^1]，都可以被解读为 OpenAI 在这些约束之间做出的取舍。这种取舍在商业上是可理解的，但它确实以用户体验和社区信任为代价。

争议与反方观点

一份合格的深度报道，必须呈现主流叙事之外的反方视角。

容量不足还是有意降本？

最核心的争议是：反复出现的 capacity 报错，到底是真的"算力不够"，还是 OpenAI 为了控制成本而有意收紧供给？

支持"有意降本"一方的证据，是 6 月集中出现的配额下调（10—20 倍的说法）、上下文窗口压缩（1M → 40 万）[^7]，以及中文媒体广泛报道的"GPT-5.5 降智"现象——有报道引用 OpenAI 官方文档，指 GPT-5.5 在使用一两个小时后会被悄悄替换成更弱的 mini 版本，被戏称为"薛定谔的脑子"[^13]。这些动作都指向一个方向：OpenAI 在主动限制每个用户对高成本档位的消耗。如果"限配额"和"报容量满"是同一套降本策略的不同表现，那么 capacity 报错就带有相当的人为色彩。

支持"真实容量瓶颈"一方的证据，则是 GPT-5.5 从 4 月全量上线以来持续两个月的错误率曲线[^1]——这种跨月、跨事件类型、跨产品线（API、Codex、ChatGPT）的反复出错，更像是基础设施层面的供给跟不上需求，而非单纯的政策调整所能解释。此外，社区里即便配额充足的 Pro 用户也报错[^7]，说明问题至少有一部分确实超越了账户策略层面。

本报告的判断是：两者很可能同时成立。真实的算力供给紧张是底色，而配额下调、上下文压缩是 OpenAI 为缓解这种紧张而采取的需求侧管理手段；这些手段在用户端被感知为"被降本"，与 capacity 报错叠加，共同构成了当前的受挫体验。把任何一方单独当作全部原因，都不够准确。

"陈旧横幅"质疑

社区里还存在一种更技术性的质疑：部分 capacity 报错可能是**"陈旧横幅（stale banner）"**——即模型实际并未满载，但前端因为状态判断逻辑的延迟或缓存，错误地显示了"已满载"提示[^3]。这一说法难以在公开渠道得到确证，但它在逻辑上解释了一种社区反映的现象：有时用户什么都不改、刷新或等待几分钟，报错就消失了。OpenAI 没有公开回应过这一质疑，因此它仍属于待证实的社区假说，本报告予以保留但不作为定论。

为 GPT-5.6 预留容量的猜测

6 月 16 日主帖里，用户 Anders123 提出了一个被多人附和的猜测："这会不会是因为他们在为几个小时后要发布的新版 5.6 预留容量？"[^3] 这个猜测的背景是：社区与爆料渠道一直在讨论 GPT-5.6（传闻代号"iris-alpha"，传闻支持 1.5M token 上下文，预测市场 Polymarket 一度给出 6 月 30 日发布的较高概率）[^15]。如果 OpenAI 确实在为 GPT-5.6 的发布腾挪推理资源，那么 GPT-5.5 的 capacity 收紧就有了"战略层"的解释。

但必须强调：没有任何 OpenAI 官方信息证实"为 5.6 预留容量"这一说法，GPT-5.6 本身也尚未正式发布[^15]。这属于社区在信息真空中的合理推测，应作为"值得观察的假说"而非事实来对待。

官方应对与沟通评价

综合来看，OpenAI 在这一轮事件中的应对呈现明显的两面性。

做得相对到位的一面：状态页确实记录了大量事件，6 月 16 日也首次为 capacity 报错开了正式事件，且大多数事件都在较短时间内被标记为"已恢复"[^1][^2]。这表明 OpenAI 内部对故障的响应速度并不慢。

明显不足的一面：

  • 时间线滞后。如 timore 所批评，官方事件的起点往往晚于用户实际遭遇的时间几小时，削弱了状态页的预警价值[^3]。
  • "已恢复"口径粗糙。聚合层面的恢复与个体用户的零星报错之间存在系统性落差[^1]，而 OpenAI 没有用更细粒度（按模型、按档位、按区域）的可用性指标来填补这个落差，只用了一句脚注免责[^1]。
  • 缺乏 ETA 和进度细节。多数事件更新只有"已识别/已恢复"这种单句状态[^2]，缺少根因说明、影响范围估计和预计恢复时间，用户无法据此安排工作。
  • 对长期结构性问题缺乏公开承认。GPT-5.5 的 capacity 问题是跨月反复发作的[^1][^4]，但 OpenAI 从未在状态页或公告层面承认这是一个需要长期治理的结构性瓶颈，每次都当作独立事件来"恢复"，这让用户的长期预期无法建立。

用一个比喻概括：OpenAI 的状态页像一个反应灵敏但只报近忧、不报远虑的火警系统——每一次火情它都迅速拉响并很快解除，但它不会告诉你整栋楼其实长期处于电路过载状态。

未来变量与值得持续观察的信号

未来几周，以下几个变量将决定 capacity 报错会好转还是恶化：

  • GPT-5.6 是否发布、发布后如何影响 5.5 的容量分配。 若 5.6 在 6 月底如期发布，短期内可能进一步挤占 5.5 的推理资源、加剧报错；但若 OpenAI 同步扩容，也可能缓解[^15]。
  • 配额与上下文政策是否继续收紧。 若 Pro 用户的 1M 上下文持续被限制、配额继续下调，说明降本保供策略仍在延续，capacity 压力不会很快消失[^7]。
  • FedRAMP 降级事件何时彻底解决。 它已经持续一周，是当前状态页上唯一进行中的事件，其走向是 OpenAI 基础设施健康度的一个风向标[^1]。
  • 状态页是否会增加按模型/档位的细粒度可用性。 如果 OpenAI 响应社区批评、提供更细的指标，将直接改善信任落差问题[^3]。

建议读者持续盯住两个一手信号源：OpenAI 官方状态页（status.openai.com）的历史与当前事件[^1]，以及开发者社区编号 1383863、1379767 这两个长期报错帖的活跃度[^3][^4]——它们的开合与回复密度，是判断问题是否真正平息的可靠先行指标。

给不同读者的行动建议

对个人开发者/Pro/Plus 用户：遇到 capacity 报错时，先用 /status 确认自己的配额与上下文余量——若配额充足仍报错，基本可判定为 OpenAI 供给侧波动，不必怀疑账户[^7]。短期可降档（xHigh→High/Medium）或切换到 GPT-5.4 应急；避免在长会话即将触发后台压缩时（即上下文接近上限）硬撑，因为压缩任务最易撞上容量墙[^5]；重要工作错开北美白天高峰。

对团队/企业用户：关注 FedRAMP 降级等持续性事件的进展[^1]，对关键工作流准备备选模型或多供应商策略；不要仅凭状态页的"已恢复"判断服务可用性，应结合自身监控。

对所有读者：把"Selected model is at capacity"理解为一条结构性、会反复出现的报错，而不是一次性的突发事故。校准预期、准备 fallback，比等待它"彻底修好"更现实。

本次调查的局限与不确定性披露

为保持诚实，本报告必须明确披露以下几点局限：

  • 6 月 25 日当天（"最近一小时高峰"）的直接一手证据有限。 本报告未能从公开渠道获取到 6 月 25 日当天精确到小时的 capacity 报错激增数据（这类实时数据通常不公开）。用户提供的体感是真实的，但报告对它的解释基于"6 月 16 日事件后的长尾 + 6 月 24 日 gpt-4o-mini 等叠加事件"的综合推断[^1][^3]，而非一份 6 月 25 日当天的精确监控报表。
  • "为 GPT-5.6 预留容量""陈旧横幅"等说法未被官方证实。 它们作为社区假说或合理推测被保留[^3][^15]，并非定论。
  • 配额下调的具体幅度（10—20 倍等）来自社区反馈，未经 OpenAI 官方公告确认。[^7] 引用时应保留必要的不确定性。
  • 第三方监控（isdown、pulsetic、downdetector）的数据存在缓存与口径差异。 例如 isdown 在本报告采集时显示的"最近中断"与"24 小时内 0 起中断"存在滞后，不能作为 6 月 25 日实时状态的依据；其长期统计（90 天 72 起事件、月均 13.3 起）只作为趋势参考[^8][^9][^10]。
  • 搜索引擎对 2026 年 6 月近期内容的索引存在滞后。 部分搜索结果混入了 2025 年的旧闻（如某篇被误标为 2026 的报道实为 2025-06-11 发布），本报告已逐一核对一手页面的真实时间戳予以剔除，但读者自行检索时应注意年份与发布时间字段。

本报告所有可确证的事实判断，均可在配套的《检索日志》中找到对应的一手来源；所有带推断性质的判断，均已在行文中以"推断""可能""待证实"等措辞标注，并附脚注指向来源。

参考链接

以下链接按来源平台分类，便于按平台查阅；正文行内溯源请见下方「参考文献」脚注。

OpenAI 官方来源

OpenAI 开发者社区（一手讨论）

GitHub（openai/codex）

Reddit（r/codex 等社区反馈）

第三方监控

媒体与中文社区（背景与机制）

参考文献

[^1]: OpenAI. OpenAI Status（首页与 History）. status.openai.com, 2026. 资料截至 2026-06-25. 链接：https://status.openai.com ；历史：https://status.openai.com/history . 一手来源，引用处包括：6 月事件时间线表、3—6 月聚合可用性（API 99.98% / Codex 99.96% / FedRAMP 99.96% / ChatGPT 99.80%）、状态页脚注"单个客户可用性可能因订阅层级/模型/API 功能而异"、GPT-5.5 于 4 月 23 日向 Codex 全量开放、5 月 GPT-5.5 错误率事件序列、当前进行中的 FedRAMP 降级（已持续一周）。

[^2]: OpenAI. Incident: Codex "Selected Model is at Capacity" Error. status.openai.com, 2026-06-16. 链接：https://status.openai.com/incidents/01KV7ZT644J4V94GSXMFPY2ANR . 一手来源，原文："We have identified that users are experiencing elevated errors for the impacted services. We are working on implementing a mitigation." 时间：Tue, Jun 16, 2026, 06:32 PM（+08:00）。

[^3]: VeitB 等. Selected Model is at capacity. Please try a different model. June 16th, 2026. OpenAI Developer Community（Codex 板块）, 2026-06-16. 链接：https://community.openai.com/t/selected-model-is-at-capacity-please-try-a-different-model-june-16th-2026/1383863 . 一手社区讨论，3.3k 浏览/139 赞/64 用户；引用处包括：VeitB 的维护与"已恢复"说明、Starasoft 的"Still Not Resolved"、Tommes 的"一小时前一次、现在又一次（Codex Mac, 5.5 High）"、RoMango 的"模型当前过载"判断、Anders123 的"刚买 20x 三小时后用不了"及"为 5.6 预留容量"猜测、timore 对状态页滞后与沟通不足的批评、guruhegde/Tycos 等的 xHigh/High 报错配置。

[^4]: Xees 等. GPT 5.5 - Selected model is at capacity. OpenAI Developer Community（Codex 板块）, 2026-04-25. 链接：https://community.openai.com/t/gpt-5-5-selected-model-is-at-capacity/1379767 . 一手社区讨论，3.9k 浏览；引用处包括：Xees 报告 Pro 200 美元账户 GPT-5.5 xHigh 会话工作 3h9m39s 后报错、被迫切回 5.4 xHigh；该帖从 4 月 25 日开帖，至约 20 小时前（≈2026-06-24）才关闭——作为问题长期持续至 6 月 24 日的硬证据。

[^5]: TANLOV. Error running remote compact task: Selected model is at capacity. openai/codex Issue #28303, GitHub, 2026-06-15. 链接：https://github.com/openai/codex/issues/28303 . 一手来源，Plus 订阅、版本 26.609.41114；标签：app / bug / context（含 compaction）/ rate-limits。引用处：报错高发于"远程上下文压缩任务（remote compact task）"的机制线索。

[^6]: openai/codex. Selected model is at capacity. Issue #19583, GitHub, 2026. 链接：https://github.com/openai/codex/issues/19583 . 早期相关 issue（4 月即有 upvote 引导，见社区帖 1379767 中 EricGT 的指引）。

[^7]: r/codex 社区. 关于 GPT-5.5 配额下调、上下文压缩与 capacity 报错的多篇讨论. Reddit, 2026. 引用篇目包括："OpenAI silently nerfed the Codex (gpt-5.5) quota by 10-20x"（https://www.reddit.com/r/codex/comments/1ub3krs/ ）、"just found out they turned off 1M context GPT-5.5 in codex for pro subs"（1M→约 40 万总/27.2 万输入）（https://www.reddit.com/r/codex/comments/1stvd0t/ ）、"GPT 5.5 usage limits are ridiculous"（https://www.reddit.com/r/codex/comments/1sxf7hd/ ）、"Selected model is at capacity..."（Pro 配额 99% remaining 仍报错）（https://www.reddit.com/r/codex/comments/1s339zz/ ）、"The 'Fix' for Selected model is at capacity"（https://www.reddit.com/r/codex/comments/1stgyql/ ）。社区反馈，配额下调幅度与上下文压缩数值未经 OpenAI 官方公告确认。

[^8]: IsDown.app. OpenAI 服务健康与事件统计. 2026, 资料截至 2026-06-25. 链接：https://isdown.app/status/openai . 第三方监控，引用处：90 天内 72 起事件（1 major + 71 minor）、中位持续 2 小时；5 年 773 起、月均 13.3 起。注意其实时数据存在缓存滞后（采集时显示"last outage April 08, 2026"），仅作趋势参考。

[^9]: Pulsetic. OpenAI 事件追踪. 2026. 链接：https://pulsetic.com/status/openai/incidents/4544/ . 第三方监控，事件 4544："Elevated error rates for GPT 5.5 in Codex"（2026-06-11 起，状态 Monitoring）；事件 4734：6 月 16 日 Codex capacity error，约 3h16m。

[^10]: Downdetector. OpenAI 状态. 2026, 资料截至 2026-06-25. 链接：https://downdetector.com/status/openai/ . 第三方监控，采集时显示无当前大规模问题。

[^11]: 新浪财经. ChatGPT 将迎史上最大改版，重点加码编码产品 Codex. 2026-06-08. 链接：https://finance.sina.com.cn/stock/t/2026-06-08/doc-iniasfpy4046912.shtml . 媒体报道，引用处：6 月 ChatGPT 改版加码 Codex 作为需求侧催化。

[^12]: 证券时报. 算力账单压顶（OpenAI 相关报道）. 2026. 链接：https://www.stcn.com/article/detail/3895851.html . 媒体报道，引用处：OpenAI 算力成本压力背景。

[^13]: BAAI hub / 新浪财经. 实锤！GPT-5.5「降智」被抓，OpenAI 官方文档认了. 2026. 链接：https://hub.baai.ac.cn/view/55031 . 媒体/社区报道，引用处：GPT-5.5 使用 1—2 小时后被指悄然替换为 mini 版本（"薛定谔的脑子"），以及中转站"偷换模型"风险。

[^14]: The Providence Journal. Is ChatGPT down? Issues reported by users. 2026-06-17. 链接：https://www.providencejournal.com/story/news/technology/2026/06/17/is-chatgpt-down-issues-reported-by-users-open-ai-platform-chatbot-crashed/90591809007/ . 媒体报道，6 月中旬 ChatGPT 用户问题反馈。

[^15]: 社区与爆料渠道. GPT-5.6 相关传闻聚合. 2026. 来源：OpenAI 开发者社区与 Reddit r/codex 讨论（含主帖 1383863 中 Anders123 的猜测）、第三方爆料站点。引用处：GPT-5.6 传闻代号"iris-alpha"、传闻 1.5M token 上下文、预测市场 Polymarket 给出 6 月 30 日发布的较高概率。弱来源/未证实：OpenAI 官方未确认 GPT-5.6 的存在与发布日期，仅作"值得观察的假说"。

同频道推荐

查看全部 →
bensz skills v4.2.1 → v4.3.1：把更新、任务与图片交付，慢慢磨成一条可靠的路
#Codex #Skills #Vibe Coding #发布公告
2026-07-19
0 评论
bensz skills v4.1.3 → v4.2.0：工作区“大搬家”，所有产物收编进 .bensz-api 命名空间
#Claude Code #Codex #Skills #Vibe Coding #发布公告
2026-06-21
0 评论
BAC 更新手记：让人类贡献不再隐形，账本也更扛造了
#Claude Code #Vibe Coding #发布公告
2026-06-13
0 评论
bensz skills v4.1.2：auto-draw-plot 登场，技能库第一次会“画图”
#Claude Code #Codex #Skills #Vibe Coding #发布公告 #画图
2026-06-13
0 评论
在 Codex 中用 gpt-image-2 画图：从配置到出图的完整教程
#Codex #OpenAI #Skills #Vibe Coding #画图
2026-06-05
0 评论

评论区

0 条评论
游客只能浏览内容；登录后即可参与评论。
还没有评论，欢迎发表第一条看法。