Codex 里的 Ultra，得先过账单这一关

2026 年 7 月 6 日，Tibo 在 X 上回复一位 Codex 用户，只说了一句："Ultra will be in codex." 他回复的是 Haider 的帖子，后者希望 Codex 能用上 GPT-5.6 的 "pro or sol ultra"，讨论的核心是模型权限、使用额度，以及跟其他 AI 编程订阅的竞争。

我的态度是谨慎乐观。X 上一句话的回复毕竟不是正式发布公告，我不会把它当成对上线时间、订阅资格或定价的承诺。但它之所以重要，是因为 OpenAI 的 GPT-5.6 官方公告提到，新的 ultra 模式不再局限于单个智能体，而是通过子智能体来加速复杂任务。如果这个模式真的落地 Codex，真正的问题就不再是模型名字听起来厉害，而是它用起来像不像一个靠得住的工程帮手。

答案快照

问题	我的判断
发生了什么事？	Tibo 公开表示 Ultra 会进入 Codex，回复的是用户希望在 Codex 里用上 GPT-5.6 "pro or sol ultra" 的请求。
已经确认了什么？	OpenAI 已发布 GPT-5.6 Sol、Terra 和 Luna，以及一个用子智能体处理复杂任务的 ultra 模式。
还没确认什么？	这条推文没有给出上线时间、大范围开放计划、订阅资格、Codex 计费细则，也没有说明具体的产品行为。
我的结论	Ultra 在 Codex 里好不好用，要看容量、成本透明度、审查控制和实际工作流的可靠性。

消息虽小，覆盖面却不小

消息源头故意说得很短，所以我把它当成一个产品方向信号，而不是完整公告。值得注意的是，他指向的是 Codex，而不是 API 或私有预览。这个区别很关键，因为开发者是在 Codex 里通过文件、终端、代码审查、工作树和长时间任务来真正体验模型的。

OpenAI 的 Codex 帮助文档说明，Codex 已经覆盖 Free、Go、Plus、Pro、Business、Edu 和 Enterprise 各档订阅，不同套餐的用量限制和额度选项各有不同。也就是说，Codex 面对的是广大用户群，不只是企业实验室。当更强的模式进入 Codex，焦点就从跑分数据转向日常产品机制的考验。

Ultra 本质上是一个工作流承诺

"ultra 模式"听起来容易像营销话术，但它背后的产品主张其实很具体：子智能体要让一个请求能拆分成多块协调执行的任务。对写代码来说，这可能真的有用。一次大改动往往涉及搜索、规划、实现、测试、文档、迁移说明和代码审查。并行协助之所以有吸引力，正是因为真正的工程工作很少是一步到位的。

但这也是为什么我不想急着给这个模式叫好。更多智能体会带来更多产出，但更多产出不等于更好的工作。这个模式得紧扣用户意图、展示过程、尊重边界，让审查变得更轻松而不是更费劲。它的承诺不是"模型更大就赢了"，而是"委派变得可控、可以信任"。

权限仍是悬而未决的问题

官方关于可用范围的说明把这条推文拉回了现实。OpenAI 表示，GPT-5.6 预览权限仅限于通过审批的 API 组织和 Codex 工作区，拿到其中一个的资格并不会自动获得另一个。帮助中心还明确指出，个人用户和消费者账户不具备预览资格，付费 ChatGPT 订阅本身也不提供访问权限。

所以从实用角度看："Ultra 会进 Codex"这句话有分量，但并没有告诉普通用户什么时候能用上。它也没说 Ultra 会以什么形式出现——是 GPT-5.6 Sol Ultra、一个可选模式、一个工作区限制的预览，还是 OpenAI 自动路由的某种功能。这些区分不是抠字眼，它们决定了谁能用、团队怎么算预算、开发者该对这条公告抱多大信心。

额度可能决定采用率

这才是我觉得真正关键的地方。OpenAI 的 Codex 费率表说明，Codex 已改为基于 token 的额度计费，实际消耗取决于输入 token、缓存输入 token 和输出 token。页面列出 GPT-5.5 的定价是每百万输入 token 消耗 125 额度、每百万输出 token 消耗 750 额度，一个典型的 GPT-5.5 Codex 任务大约消耗 5 到 45 额度。但在我看到的版本里，还没有 Ultra 的 Codex 费率。

这也是我一直揪着额度不放的原因。如果 Ultra 使用子智能体，用户会想知道：到底会启动多少工作、什么算在套餐内用量里、缓存上下文怎么处理、任务在烧完预算之前能在哪里停下来。OpenAI 的 额度说明已经把 Codex 额度定位为超出 Plus 和 Pro 包含用量之后的补充付费方式。对一个高级模式来说，成本透明度本身就是产品质量的一部分。

公众反应关乎信任，不只是热度

围绕 GPT-5.6 的公众反应并不单一。一篇 Digg 摘要总结了 Tibo 此前关于 GPT-5.6 Sol Ultra 的帖子，既有人兴奋想拿难题试试，也有人对可用范围细节缺失感到不满。Reddit 上关于 GPT-5.6 的讨论里，开发者在争论预览权限、安全限制和时间节点。OpenAI 开发者社区里，一位 Codex 用户抱怨额度限制会把正常的编码流程变成配额管理。

我觉得关于配额的批评比单纯的兴奋更有说服力。一个前沿的编码模式在 demo 里可以很惊艳，但如果用户舍不得用好 prompt、长任务不可预测地消耗额度、安全检查在缺乏清晰反馈的情况下打断正常工作，那它作为日常工具就会失败。在这种情况下，开发者首先问的不是"Ultra 聪不聪明"，而是"我今天能不能靠它搞定这个仓库"。

我会关注什么

如果 Ultra 进入 Codex，我会先看操作细节，再看跑分宣传。Codex 能不能显示跑了哪些子智能体、为什么跑？开发者能不能限制一次运行的范围或预算？安全暂停的信息是否足够用来调试？团队在审查时能不能复现同一条任务路径，还是这个模式给人的感觉只是一次性的、看不见过程的闷头操作？

最好的结果不是 Codex 多了一个更强的模型，而是 Codex 多了一套更可靠的委派工程机制：清晰的任务边界、可见的成本、可恢复的失败、可审查的产出。这样 Ultra 才会像一个严肃的工作流原语，而不是一个花哨的路由选项。

我的结论

我把"Ultra will be in codex"理解为一个重要信号，但还不是完整的产品故事。消息本身指向一个方向，官方文档说是有限预览，费率表和社区反馈都强调额度很关键。拼在一起，结论很清楚：Ultra 在 Codex 里要想让人兴奋，就得先跨过权限、额度、安全检查和审查这些实际摩擦。

这也是我对它的评判标准。一个编程智能体不是靠一个 prompt 的惊艳表现取胜的，而是靠变得足够可靠——让我敢把难活交给它、看得懂它做了什么、再判断结果值不值这个成本。