GPT-5.6 发布之后，很多人第一反应不是“它到底强不强”，而是另一个更现实的问题：
为什么我一用 Codex，额度掉得这么快？
这次 GPT-5.6 不再是一个单独模型，而是一组模型：Sol、Terra、Luna。再叠加 low、medium、high、xhigh、max 这些推理档位，以及 Codex 里的 ultra、子代理、长上下文、工具调用，选择一下子变复杂了。
所以这篇不做发布会复读机，也不只讲“哪个最强”。我们按实际使用来讲清楚四件事：
- 三个模型到底分别干什么。
- API 定价和 Codex 额度为什么看起来更容易烧。
- 日常写作、编程、重构、上线排查分别怎么选。
- 怎么设置，才能少花冤枉额度。
先说结论：默认用 Terra，便宜活给 Luna，硬仗再上 Sol
如果你不想看完整分析，先记这套默认策略：
| 场景 | 推荐模型 | 推荐推理档位 | 原因 |
|---|---|---|---|
| 翻译、总结、改文案、整理资料 | GPT-5.6 Luna | low 或 medium | 便宜、快、结果容易人工判断 |
| 普通代码修改、页面调整、常见 Bug | GPT-5.6 Terra | medium | 能力和成本最均衡，适合作默认 |
| 多文件修改、复杂重构、难复现问题 | GPT-5.6 Terra | high 或 xhigh | 先提高推理档位，不急着换 Sol |
| 架构级改造、上线前排查、关键安全/金融/生产任务 | GPT-5.6 Sol | high、xhigh 或 max | 质量优先，成本靠任务价值覆盖 |
| 已经失败两轮、结果明显不可靠 | 升一级模型或推理档位 | 不要同时全开 | 先找瓶颈，不要盲目堆配置 |
我的建议更简单一点：
日常默认 Terra Medium；能一眼验收的活用 Luna；只有高价值复杂任务才用 Sol。
这和很多人升级新模型后的直觉相反。新模型刚出，大家很容易把最强模型设成默认，甚至把最高推理档位也打开。但 Agent 工作不是聊天问答，它会读文件、跑命令、调用工具、展开上下文、甚至启动子代理。你开的不是“更聪明一点”，而是打开了一整套更昂贵的执行方式。
GPT-5.6 不是一个模型，而是一条能力阶梯
OpenAI 官方模型页给出的定位很清楚：
| 模型 | API 模型 ID | 官方定位 | 输入价 / 100万 tokens | 输出价 / 100万 tokens | 上下文窗口 |
|---|---|---|---|---|---|
| Sol | gpt-5.6-sol，别名 gpt-5.6 | 复杂推理和编码的旗舰模型 | $5.00 | $30.00 | 1.05M |
| Terra | gpt-5.6-terra | 智能和成本的平衡款 | $2.50 | $15.00 | 1.05M |
| Luna | gpt-5.6-luna | 面向高频、成本敏感任务 | $1.00 | $6.00 | 1.05M |
注意两个细节。
第一，gpt-5.6 这个别名默认指向 gpt-5.6-sol。如果你在 API 或某些工具里只填 gpt-5.6，很可能不是在用“中杯”，而是在用旗舰档。
第二，三档模型都有 1.05M 上下文和 128K 最大输出，不代表你应该把上下文塞满。长上下文是能力上限，不是使用目标。尤其在 Agent 场景里，上下文越长，历史报错、重复日志、旧方案、无关文件越容易一起进入后续请求。
这也是 GPT-5.6 的第一个使用原则：
选模型不要只看“能装多少”，而要看“这个任务值不值得让它读这么多”。
三个模型分别适合什么
Luna：脏活累活，但不要让它背锅
Luna 是最便宜的一档，适合高频、结果容易验证的任务。
比如：
| 任务 | 适合 Luna 吗 |
|---|---|
| 翻译、润色、摘要 | 适合 |
| 生成 FAQ、整理会议纪要 | 适合 |
| 批量改 i18n 文案 | 适合 |
| 根据明确模板生成内容 | 适合 |
| 大规模架构重构 | 不适合 |
| 隐蔽 Bug 定位 | 不建议 |
Luna 的正确用法不是“让便宜模型干一切”，而是把确定性强、验收成本低的事情交给它。比如你让它把一批中文文案翻成英文，结果好不好一眼能看出来；让它整理 API 文档、抽取字段、改格式，也很容易复核。
但如果任务本身需要长时间探索、复杂判断、多文件推理，Luna 反而可能让你花更多。因为它第一次做不好，你会补充要求、重跑、回滚、再解释，最后总成本未必低。
Terra：大多数人的默认档
Terra 是这次最值得长期默认使用的一档。
它的价格刚好是 Sol 的一半：输入 $2.50，输出 $15。官方定位也是在智能和成本之间取平衡。对 Codex、Cursor、Claude Code 这类 Agent 工作流来说，平衡款往往比旗舰款更重要，因为你每天跑的不是一次“奥赛题”，而是一堆中等复杂度任务。
适合 Terra 的场景：
| 场景 | 建议 |
|---|---|
| 普通页面开发 | Terra Medium |
| 修常见 Bug | Terra Medium |
| 多文件但范围明确的修改 | Terra High |
| 给代码补测试 | Terra Medium 或 High |
| 读项目、解释模块、生成迁移计划 | Terra Medium |
如果你从 GPT-5.4 或 GPT-5.5 迁移过来，我建议先把 Terra Medium 当默认，不要一上来切到 Sol Max。OpenAI 的提示迁移建议里也强调：迁移时先保留原来的推理设置，再在代表性任务上测试同档位和低一档位，不要默认把推理拉满。
这点很关键。GPT-5.6 的优势之一是更高的 token 效率，但如果你同时把模型、推理档位、上下文、子代理全拉满，就很难知道到底是模型变贵了，还是你的运行方式变重了。
Sol：不是默认档，是关键任务档
Sol 是旗舰模型，也是 OpenAI 官方推荐给复杂推理和编码的模型。它的优势集中在几个方向：
| 能力方向 | 适合用 Sol 的原因 |
|---|---|
| 长链路 coding agent | 更擅长规划、执行、验证、修正 |
| 前端和视觉任务 | 官方强调布局、层级、设计判断有明显提升 |
| 复杂知识工作 | 文档、表格、演示、金融研究、法律分析等多步骤任务 |
| 工具和浏览器任务 | 更适合需要浏览、计算、文件处理、电脑操作的流程 |
| 安全和高风险排查 | 质量收益可能超过成本 |
但 Sol 不是“永远最好”。社区评测里有一个很有意思的分歧：在更偏 Agent 操作的 Terminal-Bench、Artificial Analysis Coding Agent Index 上，GPT-5.6 Sol 表现很强；但在 SWE-Bench Pro 这类真实仓库 issue 修复榜单里，外部讨论也指出它并非在所有维度都压过 Claude Fable 5。
这说明了一个实际结论：
Sol 更像长任务 Agent 的强模型，不是所有代码榜单的万能第一名。
所以 Sol 应该留给高价值任务：核心模块重构、上线前最后排查、复杂架构设计、难复现问题定位、严肃安全审查。你越能清楚定义验收标准，Sol 越值得用；你只是想“帮我看看这个页面怎么改”，Terra 通常更划算。
为什么感觉 GPT-5.6 额度掉得更快
很多人会说：官方不是说更高效吗？为什么我用起来反而更耗？
这里要分清两件事：
模型单次完成任务可能更高效，不等于你的整体使用一定更省。
尤其在 Codex 里，额度消耗不是只由“模型单价”决定，而是由这一整条链路决定：
1. 长上下文会触发更高价格区间
OpenAI 定价页把 GPT-5.6 分成 short context 和 long context 两档。以标准 API 价格为例：
| 模型 | 短上下文输入 | 长上下文输入 | 短上下文输出 | 长上下文输出 |
|---|---|---|---|---|
| Sol | $5.00 | $10.00 | $30.00 | $45.00 |
| Terra | $2.50 | $5.00 | $15.00 | $22.50 |
| Luna | $1.00 | $2.00 | $6.00 | $9.00 |
也就是说，一旦任务进入 long context，输入价格会翻倍，输出价格也会变高。第三方 SDK 和社区实践里，普遍会把 GPT-5.6 的短/长上下文分界理解为 272K tokens。Codex 订阅额度并不等于 API 账单，官方没有公开完整换算公式，所以不能把 API 倍率机械套到订阅额度上。
但一个经验判断是成立的：
上下文越长，Agent 读得越多、带得越多、缓存写入越多、输出也越容易变长，额度下降自然更快。
2. 子代理不是免费并行
GPT-5.6 支持更强的多代理能力。官方文档里，Multi-agent beta 可以让一个 GPT-5.6 实例协调多个子代理并综合结果；官方发布页也把 Codex 的 ultra 类比为更强的并行执行方式。
这对复杂任务很有价值。比如一个大型重构可以让不同子代理分别读前端、后端、测试、数据库迁移，再由主代理汇总。
但普通任务开子代理，常常是另一回事：
| 你以为 | 实际可能发生 |
|---|---|
| 并行更快 | 多个代理各自读文件、调用工具 |
| 多代理更聪明 | 简单问题被拆复杂 |
| 一次性解决 | 汇总阶段还要再消耗上下文 |
| 只多一点成本 | 可能多出多轮文件读取和推理 |
所以多代理适合“能清晰拆分的复杂任务”，不适合“帮我改一个按钮样式”这种小活。
3. 推理档位越高，不一定越划算
GPT-5.6 支持 none、low、medium、high、xhigh、max。官方建议也很明确：medium 是均衡起点，high 或 xhigh 应该在评测显示有收益时使用，max 留给最难、质量优先的任务。
这和人的直觉不太一样。很多人会把“推理更高”理解成“肯定更好”。但在日常任务里，推理档位过高可能只是让模型花更多步骤确认一个原本简单的问题。
更合理的升级顺序是：
Luna low/medium
-> Terra medium
-> Terra high/xhigh
-> Sol high/xhigh
-> Sol max 或 Codex ultra
不要一上来就从第一档跳到最后一档。
4. 提示词太长、工具太多，也会烧钱
OpenAI 的 GPT-5.6 提示指南里有一个很实用的结论：精简重复系统提示、无关示例和无关工具描述，在内部 coding-agent eval 中既提高了得分，也显著降低了 token 和成本。这个结论不应该被理解成“提示词越短越好”，而是：
该保留目标、约束、验收标准；该删掉重复规则、无关工具和过期上下文。
很多 Codex 任务耗费高，并不是因为你多写了几句话，而是因为你没有告诉它：
| 缺失信息 | 可能后果 |
|---|---|
| 要改哪些文件 | Agent 全项目搜索 |
| 怎么验收 | Agent 反复自查、反复跑无关命令 |
| 哪些不要动 | Agent 扩大修改范围 |
| 输出要多细 | 最终回答写得过长 |
| 是否允许外部操作 | Agent 停下来问，或做过多安全确认 |
省钱的提示词不是短，而是边界清楚。
Codex 里怎么设置更省
如果你用的是 Codex，本地配置可以先从这几项入手。下面是一个偏保守、适合日常任务的思路：
# ~/.codex/config.toml
# 日常默认模型：平衡能力和成本
model = "gpt-5.6-terra"
# 控制上下文，不把窗口当垃圾桶
model_context_window = 272000
model_auto_compact_token_limit = 240000
# 普通任务先关闭多代理，需要时再开
multi_agent = false
这不是唯一正确配置，而是一个“先稳住成本”的起点。
model_context_window = 272000 的意思，是把日常任务限制在短上下文附近；model_auto_compact_token_limit = 240000 是提前触发压缩，给后续推理和输出留空间。实际使用时，旧任务可能不会立刻吃到新配置，最好重启 Codex 或新建任务。
如果你确实在做复杂任务，可以临时升级：
model = "gpt-5.6-sol"
multi_agent = true
但我不建议长期这样默认。Sol、多代理、大上下文、最高推理档位，应该像“生产事故排查工具箱”，不是每天开机就全挂身上。
API 里怎么用
如果你是 API 用户，最重要的是把模型选择变成参数，而不是写死。
最基础的选择规则：
const modelByTask = {
cheap: "gpt-5.6-luna",
default: "gpt-5.6-terra",
hard: "gpt-5.6-sol",
};
然后把推理档位也做成可控项：
const effortByTask = {
draft: "low",
normal: "medium",
difficult: "high",
critical: "max",
};
真正上线时，不要只看每百万 token 单价，而要记录这些指标：
| 指标 | 为什么重要 |
|---|---|
| 单任务总 tokens | 直接反映成本 |
| 输出 tokens | Sol 的输出价格很高，长回答很贵 |
| cache write tokens | GPT-5.6 有单独 cache write 价格 |
| cached input tokens | 缓存命中高，成本会明显下降 |
| 工具调用次数 | Web search、file search、tool call 也可能计费 |
| 任务一次通过率 | 便宜但反复重跑，不一定省 |
| 人工返工时间 | 最终要算“完成任务成本” |
对于工具密集型流程，可以研究 GPT-5.6 的 Programmatic Tool Calling。它适合过滤、排序、去重、聚合、批处理这类有明确边界的中间步骤。官方提示里也提醒：不要因为“有多个工具调用”就上 PTC，只有当中间结果可以用代码压缩成小结构时，才值得用。
一套更实用的升级规则
我建议把 GPT-5.6 当成一条升级路径，而不是一个模型开关。
写作和资料整理
默认：
Luna low / medium
升级条件：
| 现象 | 怎么升 |
|---|---|
| 摘要漏重点 | Luna medium |
| 结构混乱 | Terra medium |
| 需要跨多篇材料综合观点 | Terra high |
| 要写高质量发布稿、投资分析、法律/科研内容 | Sol high |
不要用 Sol Max 来改普通错别字，这个场景不体面，钱包也不体面。
日常开发
默认：
Terra medium
升级条件：
| 现象 | 怎么升 |
|---|---|
| 一次没改全 | 先补充文件范围和验收标准 |
| 涉及多个模块 | Terra high |
| 涉及架构边界、数据迁移、并发、安全 | Sol high |
| 前两轮都失败，且任务价值高 | Sol xhigh / max |
日常开发最容易浪费的地方，是提示词太模糊。比如“帮我优化一下项目”这种请求，Agent 只能自己到处看。更好的写法是：
请只检查 app/articles 页面首屏加载慢的问题。
重点看数据读取、Markdown 渲染、图片加载。
不要改样式。
验收标准：npm run build 通过，并说明性能瓶颈和修改点。
这类提示不一定更短，但明显更省。
大型重构
默认：
Terra high -> Sol high
大型重构不要一开始就让模型动手。先让它出计划：
- 让模型列出涉及模块。
- 让模型说明迁移步骤和风险。
- 让模型给出验证命令。
- 你确认范围后，再让它改。
如果任务能拆成独立工作流，再考虑开启多代理或 ultra。比如前端、后端、数据库、测试可以并行分析；但如果所有改动都围绕一个核心文件，多代理未必有价值。
上线前排查
默认：
Sol high / xhigh
上线前排查的成本逻辑不一样。这里不应该问“哪个便宜”，而应该问“漏一个问题要花多少钱”。
适合 Sol 的上线前任务：
| 任务 | 为什么值得 |
|---|---|
| 数据迁移审查 | 失败成本高 |
| 权限和鉴权检查 | 漏洞风险高 |
| 支付、订单、账单流程 | 业务影响大 |
| 安全补丁和依赖升级 | 需要谨慎验证 |
| 大版本发布回归 | 需要全局理解 |
但即便是 Sol，也要给清楚验收标准：查什么、不查什么、输出几类风险、是否允许修改代码、需要跑哪些验证。
关于“GPT-5.6 到底有没有碾压”的冷静判断
这次社区反馈很热闹。官方强调 GPT-5.6 在 Agent、编码、知识工作、前端设计、浏览器/电脑使用、网络安全和科研任务上都有明显提升。Artificial Analysis 也把 GPT-5.6 Sol 放在 Coding Agent Index 的前列，认为它在 Codex harness 里表现非常强。
但也有另一类观点提醒：不同 benchmark 测的不是一回事。Terminal-Bench 更像终端里的长链路 Agent 执行；SWE-Bench Pro 更像真实仓库 issue 修复。Sol 在前者很强，不代表所有代码修复场景都无脑第一。
所以我更愿意把 GPT-5.6 的提升理解成：
它不是让你永远选最强模型，而是给你更细的模型路由能力。
以前你可能只有“便宜模型”和“旗舰模型”两个选择。现在你可以把任务按价值和难度分层：Luna 跑量，Terra 做默认，Sol 打硬仗。真正会用的人，不是永远开 Sol，而是知道什么时候不用 Sol。
最后给一张个人选择表
| 你现在要做什么 | 直接选 |
|---|---|
| 翻译、总结、提取要点 | Luna low / medium |
| 写普通公众号初稿 | Luna medium 或 Terra medium |
| 写严肃分析文章 | Terra high，必要时 Sol high |
| 改一个页面样式 | Terra medium |
| 修普通 Bug | Terra medium |
| 多文件重构 | Terra high |
| 难复现 Bug | Sol high |
| 上线前风险排查 | Sol xhigh |
| 核心系统重构 | Sol xhigh / max |
| 任务可以拆成多个独立方向 | 再考虑 multi-agent / ultra |
| 只是小改动 | 不要开 multi-agent / ultra |
如果只记一句话：
GPT-5.6 的正确用法，不是把最强模型设成默认，而是把任务价值、验收难度和模型成本对齐。
Luna 负责跑量，Terra 负责日常，Sol 负责关键战役。上下文不要无限堆，子代理不要随便开，推理档位不要凭心情拉满。这样用，GPT-5.6 才不是“额度粉碎机”，而是真正能把复杂工作做下来的生产力工具。
参考资料
- OpenAI 官方发布页：https://openai.com/index/gpt-5-6/
- OpenAI 模型页：https://platform.openai.com/docs/models
- OpenAI 定价页：https://platform.openai.com/docs/pricing
- OpenAI GPT-5.6 模型指南：https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6
- OpenAI GPT-5.6 提示指南：https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6
- Artificial Analysis GPT-5.6 评测：https://artificialanalysis.ai/articles/gpt-5-6-has-landed
- Simon Willison：https://simonwillison.net/2026/Jul/9/gpt-5-6/
- 参考文章：前端充电宝《GPT-5.6 额度消耗太快，原因找到了，可以这样优化！》
- 参考文章：字节笔记本《GPT-5.6 的中杯、大杯、特大杯如何选？》