GPT-5.6 Luna Max：开发者如何在 Codex 中实际使用它——以及它会在何处失效

8月1日，一份四行的配置文件开始在X上流传。它创建了一个Codex智能体，名为luna_worker，将其模型设置为gpt-5.6-luna，将其推理强度设置为max，并把你工作中无聊的那一半交给它，而GPT-5.6 Sol则负责计划。几天之内，同样的配方已被用英语、中文、日语、韩语、西班牙语和阿拉伯语重新发布，而一个基于同一想法构建的插件在四天内就突破了1,300个GitHub星标。而且，差不多就在它走红的那天，这种接法也是错误的：该插件的作者在48小时内公开把他自己项目中的GPT-5.6 Luna撤了下来，因为一位同行告诉他，它作为Codex子智能体行不通——可两天后他又把它放了回去，只是换了一种完全不同的接法。

整个这段历程发生在一周之内，也是迄今为止任何人针对该模型发布过的最有用的内容。它告诉你：廉价工人模式是真实存在的，显而易见的接法是错误的做法，而这两者之间的差别正是价值的大部分所在。本文中所有涉及技术的内容，均来自从业者在2026年7月30日至8月5日之间自行发布的结果——而非公司文档；公司文档将GPT-5.6 Luna描述为一款面向“成本敏感、高吞吐量工作负载”的模型，对这一切只字未提。凡是由独立第三方测得的数字，我们会注明；凡是来自某位开发者会话日志的数字，我们也会照实说明，包括它们彼此矛盾的情况。而它们确实经常矛盾。

“Luna Max”是什么，以及为什么大多数人从未看到它。

没有叫 Luna Max 的模型。有两个旋钮，Luna Max 是它们的一种组合：GPT-5.6 家族中最便宜的档位，以最深的推理设置运行。档位旋钮在 GPT-5.6 Sol、GPT-5.6 Terra 和 GPT-5.6 Luna 之间选择。推理深度旋钮有六个档位——none、low、medium、high、xhigh 和 max——它控制模型在回答之前进行多少思考。

几乎没有人将廉价档位与深度设置搭配使用，原因很平常：max 默认是隐藏的。在 ChatGPT/Codex 桌面应用中，它藏在“设置 → 配置 → 可用的推理努力”后面，该列表默认情况下顶部选项未被勾选。八月第一周，六位不同的开发者发布了相同的三击修复方法，这很好地说明了有多少人一直在以默认深度运行 Luna，并以此评判该模型。在 API 端则没有任何开关需要寻找：你传入模型 ID gpt-5.6-luna，并将推理努力设置为 max，放在请求体中，这就是全部改动。

在阅读任何基准测试之前，有一个结论值得铭记：当Artificial Analysis发布该模型的智能评分时，页面标题会是GPT-5.6 Luna (max)。大家引用的Luna独立评分是最大努力（max-effort）配置下的结果。如果你一直使用默认配置，并困惑自己的体验为何与排行榜不匹配，原因就在这里。

没人解释的旋钮：努力改变的是 token 数量，而非 token 价格

提高推理强度并不会让你进入更贵的计费档位。GPT-5.6 Luna 在每个强度设置下均按每百万输入 token 0.20 美元、每百万输出 token 1.20 美元计费。变化的只是模型为了得出答案所花费的 token 数量——而在最高强度下，它会花掉很多。

Artificial Analysis 在运行其 Intelligence Index 的过程中测量了这一点，这些数字是对从业者所抱怨内容的最清晰的独立确认：

• 得分 — 在 Artificial Analysis Intelligence Index 上获得 51 分，而它所评测的同类模型得分中位数为 17。

• 冗长度——索引运行期间生成了1.3亿个输出token，而中位数为6100万。Artificial Analysis将该模型标记为“非常冗长”。

• 原始速度——每秒输出 182.5 个 token，在 163 个模型中排名第 16。每个 token 的速度都很快。

• 首个 token 生成时间 — 在最大努力下约为136秒，Artificial Analysis 指出，即便在该价位的推理模型中，这一时间也处于较高水平。

• 总支出 — 174.06 美元用于在整个索引上评估模型。

把第三行和第四行放在一起读，因为这两行合起来就是完整的用户体验。Luna 在最大负载下能快速流式输出 token，但启动需要几分钟，而且在同样的任务上，它产生的 token 数量大约是普通模型的两倍。这就是为什么现场报告中最常见的抱怨不是“它错了”，而是“它很慢”——也是为什么便宜的价格并没有转化为相应便宜的会话。你只是买到了低单价，但 token 总数很高。

作为对比：在我们自己的 GPT-5.6 Luna 模型页面上，七天真实流量下观测到的首 token 中位延迟为 1.78 秒，第 95 百分位为 9.26 秒。这与 136 秒的数字并不矛盾——这是同一个模型在多种努力设置下测得的结果，其中大多数并非最高档。你获得的延迟取决于你设置的档位，而不是你调用的端点。

Luna Max 真的是“以六分之一价格就能买到 Sol Medium”吗？

这就是让该模式爆火的说法，它源于Dan McAteer。他将Luna在最大推理设置下的表现定位在GPT-5.6左右，Sol在中等设置，或Claude Opus 5在中等设置，成本约为其六分之一。许多账号都转发了这一说法，有时还删掉了原本的保留性措辞，因此有必要把可测量的数据与主观感受区分开来。

独立评分板有力地支持了该说法中关于成本的一半，而对能力的一半仅给予部分支持。在不同层级上以最大工作量运行同一基准测试套件时，Artificial Analysis 记录到 Luna 指数为 51，成本 174 美元；Terra 指数为 55，成本 1,403 美元；Kimi K3 指数为 57，成本 2,437 美元；Sol 指数为 59，成本 2,824 美元。Luna 比 Sol 低 8 个指数点，但完成相同工作的成本约为后者的十六分之一。

独立评分榜在8月13日变得更加严苛，当时DeepSWE发布了v1.1——这是其长周期工程基准的修订版，保留了来自91个代码仓库、跨越五种语言的113个原始任务，但如今每项修复都会通过在一个隔离容器中运行已提交的diff来评分，这使得作弊难度大增。在更新后的榜单上，GPT-5.6三个层级在最大努力下均停留在7月评测文章所述的位置：Luna Max以67.2%的pass@1和每任务0.61美元居首，Terra Max约为70%，Sol Max以73%的成功率和8.39美元的成本位列第三——成功率高出六个百分点，但成本约为前者的十四倍。

值得再看一眼的比较位于 Luna 之下，而非其上。Claude Sonnet 5 Max 在同样的 113 项任务上得分 54%——比 Luna Max 低约 13 个百分点——每项任务成本为 26.40 美元，约为 Luna 完成同样任务所付费用的 44 倍。Luna Max 还超越了 Gemini 3.7 Flash（在同一榜单上，高强度配置为 65%）；指出这一轮的社区帖子显示，其与 Gemini 3.7 Flash Medium 的差距约为 1.7 个百分点。DeepSWE 是 Datacurve 的独立测试框架，而非公司评估——该公司自称 GPT-5.6 系列在 Terminal-Bench 2.1 和 DeepSWE 上取得了最先进的成果，这仍然是一个独立的、由供应商报告的说法。

然后是实际使用中的证据，这方面确实存在分歧。Pawel Huryn 运行了自己的修复 bug 基准测试——在两个真实代码库中植入 105 个 bug，采用盲评，每个模型一轮——结果显示 Luna 在最大努力模式下以 1.80 美元修复了 33 个 bug，而 Claude Fable 5 以 68 美元修复了 24 个。另一方面的证据，Diego Haz 花了两天时间运行多组对照会话，得出了相反的结论：Luna 平均每次会话花费 1.20 美元，而 Sol 平均为 29 美元，但他不得不重做 Luna 的大部分输出，而且在他的用例中没有任何可交付的成果，这使得节省成为一种幻觉，而非折扣。另一位开发者使用相同的测试框架报告说，Sol 在中等模式下用大约一半的时间，产出了明显优于 Luna 最大模式的结果。一场针对单个 3D 场景任务的中文评测量化了这种差异：Sol Medium 用时 21 分 30 秒完成，质量评分最高，token 消耗最少；Luna Max 用时 40 分 55 秒，消耗约 13 万 token，质量评分最低，并且用掉了每周订阅额度的一半。

经过一周后，社区立场的诚实总结是：Luna Max 不是 Sol Medium。它比 Sol Medium 便宜不少，但也更差；这个取舍是否划算，完全取决于任务是否被定义得足够严格，以至于“更差”并不重要。而这正是下面的接线模式的用途。

经得起实战检验的模式：Sol 规划，Luna 实施，由新的 Sol 评审。

一直在用 Luna Max 的人，没有一个会把它当作通用编码代理来用。在每一个版本中，实践者们最终趋同的有效配置都包含四个角色：

• 编排器 — 以高努力模式驻留在主线程的 GPT-5.6 Sol。它负责需求、架构、任务分解和最终验收，但不编写代码。

• 常规执行者——GPT-5.6 Luna 在最大努力下，处理有边界且完全明确界定的工作：机械性重构、测试编写、模块分析、文档完善，这类任务的目标清晰无歧义。

• 硬性执行者——GPT-5.6 Terra 以最大努力运行，适用于上下文密集型构建，在这类构建中Luna的指令漂移会变得代价高昂。

• 评审者——一个全新的、只读的 GPT-5.6 Sol 实例，它只查看最终的 diff，其他什么都看不到。之所以强调“全新”，是因为带着实现上下文的评审者往往会认可自己的推理。

参考实现是sol-advisor，这是 Dan McAteer 开发的一个 MIT 许可的 Codex 插件，发布第一周就获得了大约 1,400 颗星。你可以通过 Codex 插件市场安装它：添加DannyMac180/sol-advisor仓库，然后添加sol-advisor插件。它目前的形态很有借鉴意义：原生通道固定搭配一个 Terra/High 实现者，后面跟着一个全新的 Sol/High 审查者；而 Luna 在 max 设置下是一个明确的选择加入通道，作为单独的用户可见任务运行，由主要的 Sol 会话直接审查并接受其工作，而不是通过原生审查者来路由。

如果你宁愿不安装任何东西，被广泛复制的极简版本是一个自定义代理定义，位于 ~/.codex/agents/luna-worker.toml，带有两个设置——model = "gpt-5.6-luna"和model_reasoning_effort = "max"——外加一个描述和指令，将其限制在具有明确边界的委派工作上，禁止它改变整体目标或扩大自己的范围，并将架构决策和模糊需求发回给主代理。流传的建议是让 Sol 为你编写这个文件，根据你安装的 Codex 版本进行验证，并在你接受之前向你展示 diff，无论你是否信任该做法，这都是合理的。

子代理陷阱，以及社区最终认可的修复方案

这就是该模式的病毒式版本与可行版本分道扬镳之处。

Codex 的原生子代理系统并未将 GPT-5.6 Luna 视为一等公民。McAteer 撞上了一堵硬墙——Luna 不允许作为子代理使用——于是他改为将其声明为自定义代理来绕过这一限制，并公开指出了这一变通方案的代价：自定义代理无法像原生子代理那样与主代理共享上下文。数天后，他将 Luna 通道从 sol-advisor 中完全移除，理由是另一位专注于 Codex 的开发者的发现：Luna 在子代理角色中表现不佳，推测它尚未针对 v2 多代理协议进行后期训练。Diego Haz 则从另一面独立描述了同一堵墙：Sol 无法将 Luna 作为子代理生成，因此 Luna 只能存在于顶层线程中，这使得协调变得混乱。

这一解决方案目前已成为主流立场，即停止对抗它：

• 让 Luna Max 拥有自己的线程，而不是子代理图中的一个槽位。 指示 Sol 编排器在 Luna 上启动一个单独的顶层 Codex 任务，对其进行监控并取回结果。这正是 McAteer 重新添加到 sol-advisor 的内容（8 月 4 日），也是其他几位独立得出的结论。

• 接受上下文隔离这一代价。 独立的线程意味着独立的历史。这就是你要付出的代价，也是为什么下面的交接在此处比在原生子代理设置中更为重要。

• 如果你必须强制将其纳入 multi-agent v2，那么模型目录就是它被过滤掉的原因。 一位开发者将这种排除追溯到内置模型目录将 Luna 标记为 v1，并报告了一种变通方法：复制~/.codex/models_cache.json，将 Luna 的multi_agent_version设置为v2，将model_catalog_json指向你的副本，重启 Codex，然后让编排器以最大规模启动 Luna，配上快速服务层级，并关闭 forking。把这当作某位开发者在内部文件上进行的非官方 hack——这正是那种 Codex 更新一发布就会失效的东西。

交接文档：解决最常见问题的五个问题

Luna Max 最常被报告的失败是它不能紧密遵循指令，尤其是当你给它一个具体的工作流程或迭代循环去运行时。这个抱怨既来自喜欢该模型的开发者，也来自已经放弃它的开发者。实践者们最终达成的缓解方案不是写作风格意义上的更好的提示词，而是一个更严格的契约。在 Luna 话题开始之前，回答五件事：

• 这个代理需要完成的确切任务是什么？不是工作范围——而是最终完成状态。

• 哪些文件、文档或系统在范围内？ 需明确列举，而非默示。

• 它不能改变什么？ 禁止更改的接口、迁移、配置和公共契约。

• 什么证据能证明完成？ 一个具名测试、特定命令的输出、一个只涉及所列文件的 diff。

• 哪个缺失的决策应该让它停下来？回退而非猜测的触发点——正是这一点防止了过于急切的廉价模型凭空发明架构。

这也是值得将公司自身的提示词指导纳入考量的地方，并赋予其应有的标签：该公司报告称，在其内部编码代理评估中，更精简的系统提示词使评估分数提高了10–15%，同时将总token数削减了41–66%、成本削减了33–67%；它还建议对从GPT-5.5或GPT-5.4继承而来的提示词进行审计，而不是将其直接移植沿用。这些是供应商报告的数字。但这一方向与该领域的研究发现一致：精确地描述目的地，删除对每一步过程的叙述。请注意这与上文之间的张力——对范围和约束的精确描述并不等同于冗长，社区共识是Luna Max需要更多前者，更少后者。

需要规划的故障模式

• 指令漂移。经多位开发者证实：它会忽略初始简报的部分内容；当简报是需要遵循的流程而非要达到的结果时，问题最为严重。

• 实际耗时缓慢。 反复被反馈，且与Artificial Analysis在最大努力设置下测得的约136秒首令牌时间一致。适合可以挂机运行的工作；在交互式循环中则很痛苦。

• 上下文消耗。一位开发者报告称，Luna Max 消耗 258k 的 Codex 线程窗口的速度快得惊人，并怀疑一旦 Codex 在接近上限时开始压缩，配额消耗就会激增。压缩这部分只是他的印象，并非实测结果——但这种消耗速率正是 Artificial Analysis 独立测量出的冗长程度所导致的预期结果。在 API 端，请注意长上下文档位：一旦请求超过约 272k tokens，该模型的透传价格表就会从 $0.20/$1.20 变为 $0.40/$1.80，因此持续增长的线程不仅总费用更高，每个 token 的费用也会更高。

• 任何视觉相关的内容。这是现场报告中最清晰的一条分界线。一位广受关注的从业者为了改用 Luna Max 而取消了 Kimi K3 编码订阅，并评价它与自己正在放弃的产品一样好，而且便宜得多——不过明确为前端工作留出了例外。另一位则更为直言不讳：不要用 Luna 执行设计、图形、排版或幻灯片工作；用 Sol 规划、用 Luna 执行的分工方式适用于分步教学任务，而非美学类任务。

• 子代理目录。上文已说明——如果在多代理运行中 Luna 始终未被选中，那是被过滤掉了，而非运行失败。

• 看似省钱。 这种不会出现在任何基准测试中的失败模式：一次花费1.20美元而不是29美元的会话，产生的工作你却要手工重写，你付出的代价是1.20美元外加一个下午。

何时不应追求最大值

Max 不是免费的升级，而经得起考验的指导是阶梯，而非设置：

• 清晰的转换——字段重命名、机械提取、格式化处理。在 Luna 上工作量低或中等。以指定测试通过为门槛。

• 常规实现 — high 或 xhigh。Luna worker 的社区默认值是 xhigh 而非 max，正是因为 max 会在本不困难的任务上耗费时间和 tokens。

• 有界但真正困难——这才是max真正的工作。任务包必须既困难又规定明确，额外的推理才能转化为更好的结果。

• 模糊调查——改变档次，而非旋钮。如果模型是误判而非规划不足，在更便宜的模型上增加思考也无济于事；那是 Sol 的任务。

• 模糊的任务说明 — 修正约定，而非模型。任何努力设置都无法弥补未声明的验收标准。

一个针对订阅的特别提醒，出自第三方指南，且很容易出错：Codex 按模型收取的信用费率与 API 标价的比例并不相同，因此你不能照搬 API 价格比例来作为订阅路由规则。Plus 层级上报告的五小时消息配额就说明了这一点——Sol 上大约 15–90 条本地消息，Terra 上 20–110 条，Luna 上 50–280 条，范围之所以如此宽泛，是因为“消息”并非固定的工作单位。如果你的路由决策由订阅上限而非账单驱动，那就应以上限为衡量标准。

Codex 之外：人们还用它指向什么

低成本与深度推理的结合，在编程代理之外也被证实很有用，以下是有实际证据的用途：

• 浏览器智能体。一位开发者让 GPT-5.6 Luna 运行浏览器自动化技术栈，打开 Hacker News 上排名前 15 的帖子，阅读每个链接的页面并撰写报告——总成本仅为 3 美分。长周期、低风险、高 token 消耗：这正是该模型定价所对应的场景。

• 技能链。 两位实践者独立报告称，他们仅凭一个 Luna Max 目标就驱动了一条双技能流水线——将图像生成接入图像到 Three.js 的转换器——从而得到一个可交互的低多边形 3D 对象，且各自都注意到这几乎没有让他们的每周使用计数产生变化。这值得与“不要将 Luna 用于视觉工作”的警告一起阅读：Luna 是在编排执行视觉工作的工具，而不是亲自评判美学。

• 保持一个会话处于热状态。 此模型的缓存输入价格为每百万 tokens 0.02 美元，而全新输入为 0.20 美元——Artificial Analysis 在其定价面板中列出的 90% 折扣——且缓存窗口约为 30 分钟。多个指南独立得出的实际结论是：一个持续运行、反复读取同一代码库的会话，远比每个任务都开启新会话便宜得多。

• 配额套利。 整个系列中最激进的说法，也明确标注为一种说法：一位开发者报告称，由于 effort 几乎免费而层级倍率很大，他在廉价层级上以最大 effort 运行，在 $200 套餐下用三周时间处理了 49 亿个 token——按 API 价格算相当于六位数——而且他把 Kimi K3、Grok 和 DeepSeek 模型放在本地路由器后面的同一个选择器中，这样触及一个提供商的限制也不会中断工作。没有人独立复现过这个 token 数字。不过，其背后的路由习惯才是值得借鉴的部分。

无需 Codex 订阅即可运行相同的拆分

以上所有内容都是一个订阅形态的故事：人们之所以关注 Luna Max，是因为它扩展了每周的上限。在 API 方面，同样的架构更易于构建，也更容易理解，因为你是在支付账单，而不是在管理配额——而且编排器/工作器的拆分不再是插件，而是变成了普通的路由。

GPT-5.6 Luna 可通过 OrcaRouter 使用，输入每百万 token 0.20 美元，输出每百万 token 1.20 美元——这是提供商的标价，以 0% 加价转售，因此 7 月 30 日的降价在公告当天就已在我们的服务上生效，而不是等到下一个计费周期。它通过兼容 API 在 /v1/chat/completions 和 /v1/responses 上提供服务，因此 reasoning-effort 字段会像直连一样包含在请求体中，模型 ID 为 openai/gpt-5.6-luna。GPT-5.6 Sol 和 GPT-5.6 Terra 使用同一个密钥，这正是该模式的关键：一个编排器与一个工作器位于不同层级，只需一次集成中的两个模型 ID，而非两份供应商合同。路由 DSL 让你能用一次调用来表达这种拆分，而不是手工拼接线程；自动故障转移也覆盖了配额套利人群用本地路由器解决的场景——当某家供应商出现降级时，请求会落到其他地方，而不是直接失败。

两个坦诚的提醒。Codex 特有的机制——子代理图、插件市场、模型目录、每周配额——都是公司的，它们都不会随 API 密钥一起提供；如果你想要的模式是sol-advisor在 Codex 应用内，你需要 Codex 订阅。此外，上述故障模式是模型本身的属性，而非传输方式的属性：路由改变的是调用的成本以及提供商宕机时的表现，而不是 Luna 是否会遵循你的指令。

谁应该复制这个，谁不应该

如果你的工作是大规模且机械上可明确指定的——重构、测试脚手架搭建、提取、文档编写、对大型仓库进行分析遍历——就把 max 打开，让 Luna 在独立线程中运行，并以五个问题的交接方式进行；在它前面放一个 Sol 实例用于规划，后面放一个用于审阅；这样你的花费预计会减少一个数量级。汇报收益最大的人都在做类似的事情，而独立的成本数据也支持这个方向，即使它们并不支持“和 Sol 一样好”的表述。

如果你的工作是探索性的、审美性的，或者是以一份开始模糊、随推进而逐渐清晰的简报形式到来，那么现场报告会直白地告诉你：你会把省下的钱双倍花在返工上。而如果你是交互式使用——坐在那里盯着它看——最高努力模式下两分钟的冷启动时间，会比价格带来的愉悦更让你恼火。

值得关注的是：公司是否会针对 v2 子代理协议对 Luna 进行后训练。当前方案中每一处别扭的地方——独立的线程、丢失的共享上下文、catalog 的 hack 处理、整套撤回再重连的流程——都源于那同一个缺口。补上它，这种模式的最佳版本就能简化好几个步骤。

值得认真回答的问题

最大推理努力是否比默认设置每token花费更高？

不，这是对这个设置最常见的误解。GPT-5.6 Luna 的计费与 effort 无关，统一为每百万 tokens 输入 $0.20、输出 $1.20。max 改变的是所花费的 token 数量——模型会规划更多、自我检查，并在回答前进行修改。Artificial Analysis 测量到，该模型在一套基准测试套件上输出了 130M 个 token，而中位数模型输出 61M。因此，在相同任务上，max-effort 会话比 medium-effort 会话花费更高，这完全是通过 token 数量体现的，而且它生成第一个 token 所需的时间也更长。Effort 其实是一个挂着质量标签的 token 数量调节旋钮。

GPT-5.6 Luna 现在能作为原生 Codex 子代理运行了吗？

截至2026年8月5日，答案是否定的——社区已经不再尝试了。Codex的原生子代理路径不接受Luna；自定义代理的变通方法能让它运行起来，但会失去与主代理的共享上下文；而这个模式最知名插件的开发者移除了Luna，随后将其重新添加为单独生成并由编排器监控的顶级任务。如果你看到多代理运行中Luna从未被选中，那很可能是被过滤掉了，因为标准模型目录将其标记为v1而非v2，有一位开发者已自行手动修补，风险自负。这是列表中随Codex更新最有可能发生变化的一项，所以请根据你安装的版本进行验证，而不是相信任何现成方案，包括本方案。

它是否足以取代Claude或Kimi K3的编程订阅？

几位开发者已经公开取消了每月200美元的套餐，正是因为这件事。把这个问题推到台前的那篇帖子来自一位每天写代码的免疫学家：他取消了 Kimi K3 编程订阅，不是因为不好，而是因为他觉得无法证明其合理性——因为在他的体验中，GPT-5.6 Luna 在他的工作上同样好，而且便宜得多——前端除外。独立的成本数据让这个论点难以反驳：在同一个基准测试套件上，Kimi K3 在最大努力模式下得分为57，成本为2,437美元，而 GPT-5.6 Luna 在最大模式下得分为51，成本为174美元。但在你取消任何东西之前，请先看看不同意见。那些测量了配对会话并得出负面结果的开发者，并不是在测试另一个模型；他们是在测试一种不同类型的任务——开放式的、视觉的、或规格模糊的——而在这类任务上，较便宜的模型输得够惨，足以抹掉节省下来的钱。站得住脚的答案是说，Luna Max 替代的是你大部分编程工作，不一定是你最好的编程模型，而且那些从中获益最多的从业者，正是保留了某个前沿档位来规划和检查的人。