我明明在 Codex 里选了一个主模型，为什么中转站日志或者用量记录里，还会突然冒出 gpt-5.6-luna、gpt-5.6-terra？

这不一定是模型选错了，也不一定是账号出现了异常。一种已经能够验证的原因是：Codex App 并不是把所有工作都交给当前对话模型，而是会为自动标题、记忆生成和特定建议内容的安全分类等后台任务单独调用辅助模型。

我顺着官方文档、Codex 开源代码、本机 App 安装包和真实运行日志核验了一遍。结论很明确：这件事确实存在，而且不同任务使用的模型还不一样。

先看结论

截至 2026 年 8 月 4 日，我核验的当前 macOS Codex App 是 26.727.51351，内置 codex-cli 0.146.0-alpha.9.2。当前安装包、官方源码和保留的较早版本运行日志共同支持下面这些结论：

所以，当主对话使用 Sol 或其他模型时，后台同时出现 Luna、Terra 请求，在这些核验版本里是可以解释得通的。

为什么 Codex 不让主模型顺手把这些事做完？

从公开的模型定位和客户端代码可以推断，一个重要原因是这些任务对模型能力的要求并不相同。

写代码、做架构判断、处理复杂上下文，需要更强的推理和工具能力；但从一段对话中提取标题、分类信息或者结构化摘要，目标非常明确，也很容易判断结果是否合格。

OpenAI 对 GPT-5.6 系列的公开定位也是这样：Sol 面向复杂、开放和高价值任务；Terra 是日常工作的全能档；Luna 更适合提取、分类、转换和结构化摘要等明确、可重复的任务。详情可看 Codex 模型选择说明。

换句话说，Codex 做的是任务分级：

• 主对话通常从用户选择的模型开始，服务端仍可能继续路由。
• 本次核验的自动标题、记忆提取和特定建议安全分类选择了 Luna。
• 需要跨多条记忆进行归并和取舍的全局整合默认选择 Terra。

这种拆分可以让不同复杂度的工作使用不同的速度、成本和能力范围，而不必把所有事情都塞给最强模型。

证据一：自动标题确实会单独调用 Luna

对话标题要分成两种情况。

用户手动输入标题时，不需要调用模型。客户端只需要把这个名称保存下来。

新对话的自动短标题则不同。在我核验的当前桌面端安装包中，Codex 会启动一个临时、只读的系统线程来生成标题和描述，指定使用 gpt-5.6-luna 和 Low 推理，并关闭联网、多代理、插件等不需要的能力。

包内代码整理后的关键字段如下。这是本机安装包观察，不是 OpenAI 对未来版本作出的公开稳定承诺：

feature: thread_title
model: gpt-5.6-luna
effort: low
threadSource: system
web_search: disabled

我保留的一份较早桌面版本日志还能证明这条路径真实运行过。该日志对应 runtime 26.715.12143、app-server 0.145.0-alpha.30，其中一条完整事件是：

2026-07-23T13:22:41.876Z
feature=thread_title model=gpt-5.6-luna
reasoningEffort=low status=success
inputTokens=18380 cachedInputTokens=11008 outputTokens=87

也就是说，标题不是当前主对话模型“顺手”生成的，而是一笔独立的辅助请求。

这里还有一个容易误解的细节：Codex 开源核心可以直接从第一条用户消息派生一个本地标题，桌面宿主又可以在其上生成更短、更自然的 AI 标题。因此，不是每一次标题变化都会调用模型，但桌面端的自动标题路径确实会。

另一个例子：Ambient Suggestions 候选安全检查

当前 App 包内代码还为 ambient_suggestion_safety 指定了 gpt-5.6-luna 和 Low 推理。本机 2026 年 7 月 26 日至 28 日的日志也连续记录过成功事件，例如：

feature=ambient_suggestion_safety
model=gpt-5.6-luna
reasoningEffort=low
status=success

这个证据只覆盖 Ambient Suggestions 的候选安全分类，不能泛化成“Codex 的所有安全检查都使用 Luna”。

证据二：记忆不是一次调用，而是两个模型阶段

“Codex 会用模型存储记忆”这句话只说对了一半。

把数据写入 SQLite 或 Markdown 文件，本质上只是普通程序逻辑，并不需要大模型。真正需要模型的是：从历史对话中判断什么值得留下，以及怎样把多条记忆合并成稳定、可复用的上下文。

官方文档公开了两个独立配置项：

• memories.extract_model：覆盖单个对话的记忆提取模型。
• memories.consolidation_model：覆盖全局记忆整合模型。

这两个配置项证明存在两个可独立配置的模型角色；官方源码的 Memories 流水线说明进一步确认了 Phase 1 提取、Phase 2 整合的执行过程。官方文档还说明，它会跳过仍在活跃或过短的会话，等待会话空闲后在后台处理，并可能在额度过低时跳过本轮任务。它不是每次聊天结束后立即执行。参见 Codex Memories 文档。

第一阶段：从单个对话中提取记忆

这一阶段读取一段符合条件的历史对话，提取值得长期保留的信息、摘要和索引字段。当前官方默认模型是 gpt-5.6-luna，推理强度为 Low。

它属于典型的结构化提取任务，结果格式明确、执行量可能很大，正好符合 Luna 的定位。

第二阶段：整理全局记忆

这一阶段需要把多个对话产生的记忆进行合并、去重和重组，再同步成全局记忆文件。当前官方默认模型是 gpt-5.6-terra，推理强度为 Medium。

从任务形态上看，它比单条提取更需要跨记录判断；使用 Terra 也与官方对其“日常全能档”的定位一致。

这两个默认值可以直接在 OpenAI 的 Codex 源码中找到：模型常量、第一阶段选择逻辑、第二阶段选择逻辑以及 两个阶段的推理档位。

为什么有人看到的是 GPT-5.4，而不是 Luna 和 Terra？

因为客户端的默认模型选择会随版本变化。

旧版本曾默认使用 gpt-5.4-mini 做记忆提取、使用 gpt-5.4 做记忆整合。

2026 年 7 月，OpenAI 在官方提交中把这些内部用途迁移到了对应的 GPT-5.6 Luna/Terra 型号。可以直接查看这次 模型迁移提交。

所以，不能把“Codex 永远固定使用某个辅助模型”当成规则。准确说法应该是：某个 Codex 版本会为特定后台任务设置默认辅助模型，而且这些默认值可能更新，也允许配置或模型提供方覆盖。

在中转站看到额外模型请求，要不要担心？

先不要只凭模型名称下结论。

如果额外的 Luna 或 Terra 请求发生在你刚创建对话、长会话空闲、启动 Codex 或启用记忆功能附近，它可能来自上述后台流程。模型不同，并不能单独证明主任务被降级，也可能只是主任务和辅助任务被拆开执行。

macOS 用户可以先在 Codex 桌面日志中搜索当前能够确认的特征：

rg "thread_title|ambient_suggestion_safety" \
  ~/Library/Logs/com.openai.codex/

记忆任务的痕迹会因版本和存储路径不同而变化，不能假定桌面文本日志一定包含 memory_consolidation。

如果能同时对上时间、功能标签、模型名称和成功状态，证据就比只看一条账单记录完整得多。

反过来，如果请求时间与任何 Codex 操作都对不上、消耗持续异常，或者服务端没有保留足够的功能标签，那就仍然需要继续检查 API Key 使用记录、客户端日志和服务端路由，不能因为“Codex 本来会用辅助模型”就把所有异常都合理化。

最后一个边界：客户端记录的模型，不等于服务端物理模型

本次证据能够确认的是：当前客户端代码为自动标题和记忆阶段选择了这些模型 ID；较早版本的桌面日志还实际记录了标题生成的成功调用。

但如果使用第三方模型提供方或中转服务，服务端仍可能做别名解析、模型映射或内部路由。只看客户端无法证明后端最终运行的物理模型是什么。

因此，最严谨的说法不是“后台百分之百运行了某块指定权重”，而是：这些 Codex 客户端路径明确选择或请求了对应的 Luna/Terra 模型 ID。

结论

Codex 不是“一个模型外面套了一层聊天界面”，而是一个会拆分任务、调度模型和运行工具的 Agent 客户端。

在本次核验版本里，自动标题、记忆提取和 Ambient Suggestions 候选安全检查会选择 Luna；更复杂的全局记忆整理默认选择 Terra。公开资料与代码能够确认这种分工及其模型定位，但不能据此推断所有后台任务都走同一个轻量模型。

所以下次在中转站账单里看到主模型之外又出现 Luna、Terra，先别急着判断“掺水”或者“串号”。把时间、功能标签、客户端版本和服务端路由一起对上，才能知道这笔请求到底从哪里来。