# Codex 里的 Ultra，得先过账单这一关 **Summary:** Tibo 说 Ultra 会进 Codex；但我觉得真正的考验不是模型噱头，而是 subagent 级别的编码能力能不能扛住权限、额度和信任这三关。 - Canonical: https://markhuang.ai/zh/news/codex-ultra-beat-the-meter - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-07-06 - Section: News - Tags: AI, Codex, 开发者工具, 编程智能体, GPT-5.6 - Source: [X/Twitter](https://twitter.com/thsottiaux/status/2073933490513752151) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一个强大的卡通 AI 编程助手走向开发者工作站，旁边的容量仪表闪着光](https://cdn.markhuang.ai/news/codex-ultra-beat-the-meter/hero.webp) *Ultra 进 Codex 这件事，有意思的地方不在名字本身，而在于：一个更强的智能体模式，能不能在权限、额度和信任这些现实约束下，依然好用。* 2026 年 7 月 6 日，Tibo 在 X 上回复一位 Codex 用户，只说了一句：["Ultra will be in codex."](https://twitter.com/thsottiaux/status/2073933490513752151) 他回复的是 [Haider](https://x.com/haider1/status/2073695124220006575) 的帖子，后者希望 Codex 能用上 GPT-5.6 的 "pro or sol ultra"，讨论的核心是模型权限、使用额度，以及跟其他 AI 编程订阅的竞争。 我的态度是谨慎乐观。X 上一句话的回复毕竟不是正式发布公告，我不会把它当成对上线时间、订阅资格或定价的承诺。但它之所以重要，是因为 OpenAI 的 GPT-5.6 官方公告提到，新的 [ultra 模式](https://openai.com/index/previewing-gpt-5-6-sol/)不再局限于单个智能体，而是通过子智能体来加速复杂任务。如果这个模式真的落地 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 帮助文档](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan)说明，Codex 已经覆盖 Free、Go、Plus、Pro、Business、Edu 和 Enterprise 各档订阅，不同套餐的用量限制和额度选项各有不同。也就是说，Codex 面对的是广大用户群，不只是企业实验室。当更强的模式进入 Codex，焦点就从跑分数据转向日常产品机制的考验。 ![一个卡通 AI 编程助手在软件工坊里协调多个帮手智能体，把成品打包送出](https://cdn.markhuang.ai/news/codex-ultra-beat-the-meter/why-it-matters.webp) *子智能体模式有没有用，取决于它能不能把混乱的工作变成可审查的进展，而不只是多了几路并行。* ## Ultra 本质上是一个工作流承诺 "ultra 模式"听起来容易像营销话术，但它背后的产品主张其实很具体：子智能体要让一个请求能拆分成多块协调执行的任务。对写代码来说，这可能真的有用。一次大改动往往涉及搜索、规划、实现、测试、文档、迁移说明和代码审查。并行协助之所以有吸引力，正是因为真正的工程工作很少是一步到位的。 但这也是为什么我不想急着给这个模式叫好。更多智能体会带来更多产出，但更多产出不等于更好的工作。这个模式得紧扣用户意图、展示过程、尊重边界，让审查变得更轻松而不是更费劲。它的承诺不是"模型更大就赢了"，而是"委派变得可控、可以信任"。 > **Info:** > > OpenAI 的 [GPT-5.6 帮助中心页面](https://help.openai.com/en/articles/20001325-a-preview-of-gpt-56-sol-terra-and-luna)说明，预览版目前只通过 API 和 Codex 对少量受信任的合作伙伴和机构开放，预览期间不包含 ChatGPT，OpenAI 也尚未公布正式发布日期。 ## 权限仍是悬而未决的问题 [官方关于可用范围的说明](https://help.openai.com/en/articles/20001325-a-preview-of-gpt-56-sol-terra-and-luna)把这条推文拉回了现实。OpenAI 表示，GPT-5.6 预览权限仅限于通过审批的 API 组织和 Codex 工作区，拿到其中一个的资格并不会自动获得另一个。帮助中心还明确指出，个人用户和消费者账户不具备预览资格，付费 ChatGPT 订阅本身也不提供访问权限。 所以从实用角度看："Ultra 会进 Codex"这句话有分量，但并没有告诉普通用户什么时候能用上。它也没说 Ultra 会以什么形式出现——是 GPT-5.6 Sol Ultra、一个可选模式、一个工作区限制的预览，还是 OpenAI 自动路由的某种功能。这些区分不是抠字眼，它们决定了谁能用、团队怎么算预算、开发者该对这条公告抱多大信心。 ![一架天平称量发光的 AI 帮手智能体和抽象的用量方块，开发者在旁边做计划](https://cdn.markhuang.ai/news/codex-ultra-beat-the-meter/tradeoff.webp) *智能体模式越强，账单就越重要。团队需要在工作流变成习惯之前，搞清楚自己花了多少钱。* ## 额度可能决定采用率 这才是我觉得真正关键的地方。OpenAI 的 [Codex 费率表](https://help.openai.com/en/articles/20001106-codex-rate-card)说明，Codex 已改为基于 token 的额度计费，实际消耗取决于输入 token、缓存输入 token 和输出 token。页面列出 GPT-5.5 的定价是每百万输入 token 消耗 125 额度、每百万输出 token 消耗 750 额度，一个典型的 GPT-5.5 Codex 任务大约消耗 5 到 45 额度。但在我看到的版本里，还没有 Ultra 的 Codex 费率。 这也是我一直揪着额度不放的原因。如果 Ultra 使用子智能体，用户会想知道：到底会启动多少工作、什么算在套餐内用量里、缓存上下文怎么处理、任务在烧完预算之前能在哪里停下来。OpenAI 的 [额度说明](https://help.openai.com/en/articles/12642688-using-credits-for-flexible-usage-in-chatgpt-freegopluspro)已经把 Codex 额度定位为超出 Plus 和 Pro 包含用量之后的补充付费方式。对一个高级模式来说，成本透明度本身就是产品质量的一部分。 ## 公众反应关乎信任，不只是热度 围绕 GPT-5.6 的公众反应并不单一。一篇 [Digg 摘要](https://digg.com/tech/mij9vqu9)总结了 Tibo 此前关于 GPT-5.6 Sol Ultra 的帖子，既有人兴奋想拿难题试试，也有人对可用范围细节缺失感到不满。[Reddit 上关于 GPT-5.6 的讨论](https://www.reddit.com/r/codex/comments/1ugcpj4/gpt_56_sol_announced/)里，开发者在争论预览权限、安全限制和时间节点。[OpenAI 开发者社区](https://community.openai.com/t/introducing-the-new-codex-for-almost-everything/1379125/17)里，一位 Codex 用户抱怨额度限制会把正常的编码流程变成配额管理。 我觉得关于配额的批评比单纯的兴奋更有说服力。一个前沿的编码模式在 demo 里可以很惊艳，但如果用户舍不得用好 prompt、长任务不可预测地消耗额度、安全检查在缺乏清晰反馈的情况下打断正常工作，那它作为日常工具就会失败。在这种情况下，开发者首先问的不是"Ultra 聪不聪明"，而是"我今天能不能靠它搞定这个仓库"。 ![一个卡通工程控制室里，AI 帮手智能体沿着带门禁的工作流路径移动，经过审查关卡](https://cdn.markhuang.ai/news/codex-ultra-beat-the-meter/workflow-risk.webp) *Ultra 在 Codex 里最好的形态，是让委派变得更可审查——有清晰的关卡和检查点，而不是闷头干了一通、让人看不懂的黑箱操作。* ## 我会关注什么 如果 Ultra 进入 Codex，我会先看操作细节，再看跑分宣传。Codex 能不能显示跑了哪些子智能体、为什么跑？开发者能不能限制一次运行的范围或预算？安全暂停的信息是否足够用来调试？团队在审查时能不能复现同一条任务路径，还是这个模式给人的感觉只是一次性的、看不见过程的闷头操作？ 最好的结果不是 Codex 多了一个更强的模型，而是 Codex 多了一套更可靠的委派工程机制：清晰的任务边界、可见的成本、可恢复的失败、可审查的产出。这样 Ultra 才会像一个严肃的工作流原语，而不是一个花哨的路由选项。 ## 我的结论 我把"Ultra will be in codex"理解为一个重要信号，但还不是完整的产品故事。消息本身指向一个方向，官方文档说是有限预览，费率表和社区反馈都强调额度很关键。拼在一起，结论很清楚：Ultra 在 Codex 里要想让人兴奋，就得先跨过权限、额度、安全检查和审查这些实际摩擦。 这也是我对它的评判标准。一个编程智能体不是靠一个 prompt 的惊艳表现取胜的，而是靠变得足够可靠——让我敢把难活交给它、看得懂它做了什么、再判断结果值不值这个成本。