GPT-5.6 提示词指南：两个默认设置会让你多付 1.5 倍和 10 倍

用好 GPT-5.6 的提示词，关键就在两个请求参数上，而这两个的默认值都偏贵。在我们的 50 次调用矩阵里，不设 reasoning_effort 的计费是固定为 "none" 的 1.5 倍，答案却完全一样；一段稳定的前缀如果不做标记，每次调用都按缓存读取费率的 10 倍来计费。本指南是从 GPT-5.6 成本指南的实测数据里总结出来的请求结构手册：一个结构良好的请求长什么样、怎么按任务调节 effort、怎么排布提示词才能让缓存真正起作用，以及从 GPT-5.5 迁移提示词时哪些地方会出问题。

TL;DR

• 每个 GPT-5.6 请求都要显式设 reasoning_effort：在我们的 4 任务矩阵里，不设它相比 "none" 多计 1.5 倍，答案却完全一致。
• 可接受的 effort 从 none 到 xhigh；"max" 在 Sol 和 Terra 上都会返回 400。
• 用显式缓存断点标记稳定前缀：缓存读取按输入费率的 10% 计费，写入按 1.25 倍计费，所以要标记真正会重复的部分，而不是看起来稳定的部分。
• prompt_cache_options 和断点在 GPT-5.5 及更老的版本上会返回 400；上线时要按版本做门控。

一个 GPT-5.6 请求应该长什么样？

从下面这个结构起步，把不需要的删掉。它把两个关键开关都显式设定好，而不是沿用那套偏贵的默认值：

{
  "model": "gpt-5.6-terra",
  "reasoning_effort": "low",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    { "role": "system", "content": "…stable instructions…",
      "prompt_cache_breakpoint": { "mode": "explicit" } },
    { "role": "user", "content": "…the part that changes per request…" }
  ]
}

背后的排布规则是：所有稳定的内容放在断点之前，每次请求变化的内容放在断点之后，任何动态内容（时间戳、用户名、每次调用都不同的检索文档）都不能落在被标记的块里，因为块里只要变一个字节，整块就会按 1.25 倍的写入费率重新计费。prompt_cache_key 会把重复请求路由到同一份缓存；每个租户或会话用一个稳定的 key，并注意文档里写明的软限制：每个 key 大约每分钟 15 个请求。

reasoning_effort 该怎么设？

永远显式设置，最该避免的就是不设。我们的实测里，不带 reasoning_effort 的请求，计费是钉死在 "none" 的请求的 1.5 倍，而整个测试矩阵里答案完全一致。可选值有 none、low、medium、high、xhigh；传 "max" 会返回 400，并列出有效范围。在 Luna 上用一道单行数学题测试，这个档位买到的东西如下：

在我们的 token 用量剖析研究里，GPT-5.6 是唯一一个在这道题上完全关掉思考仍能答对的模型家族。所以对于抽取、分类、格式化以及检索类的调用，把 none 当默认值是站得住脚的。一旦它真的开始推理，这些 token 你看不到，却按完整的输出费率计费：在默认设置的那道数学题里，输出费用的 88% 都是你读不到的 chain of thought。要提高档位，得是你的 eval 说这个任务需要，而不是因为默认设置已经替你花掉了。

怎么组织 prompt 才能让缓存真正省钱？

按稳定程度分层，并给每一层打标记：先放 system instructions，再放 tool definitions，然后是参考文档，每一层末尾放一个 breakpoint，把易变的用户轮次放在最后一个标记之后。每个请求你有四次缓存写入的机会；默认的隐式模式会在最新消息上自动打一个 breakpoint，占掉其中一个，所以显式模式能给你完整的四个，更重要的是，只缓存你标记的部分。

真正的收益在于部分复用，而且这是可以量出来的。用一个稳定块 A 加一个替换掉的尾部 B，计费只重算了尾部：在一个 2431-token 的 prompt 里，1212 个 token 按缓存费率读回，1210 个按溢价费率重新写入，和费率表逐位对得上。由此有三条预算规则：

• 读取按输入费率的 10% 计费，所以一个热的分层前缀能把账单的输入侧压平。
• 写入按 1.25 倍计费，所以一个标记了却再也没被读到的块，比不缓存还贵 25%。标记会重复的部分，而不是所有看起来稳定的东西。
• 完整重复时，命中长度可能落到标记之下（一次探测里，2422-token 的写入只缓存了 1897 个），所以按折扣费率做预算，别指望精确匹配的数量；我们的缓存最小值研究里有各家族的下限。

ttl: "30m" 这个下限是保证的最小值，不是上限，而且是 Claude 默认 5 分钟的 6 倍；现在没有 24 小时档位了，所以那些靠长时保留的日批量负载应该重新算一遍盈亏平衡点。

从 GPT-5.5 迁移 prompt 时会坏掉什么？

两处会明着报错，一处会悄悄出问题。明着报错的：prompt_cache_options 和 prompt_cache_breakpoint 在 GPT-5.5 及更早的模型上会返回一个干净的 400（prompt_cache_options is not supported on this model），所以任何共用的 prompt builder 都需要一个版本判断。同样明着报错的："max" effort，有些 5.5 配置带着它，现在会被拒。

悄悄出问题、代价也更大的：GPT-5.6 默认就会推理，而 5.5 的负载可能是关掉推理的。一个迁移过来、从不设 reasoning_effort 的 prompt，会在同一份费率表下背上 1.5 倍的漏设税。缓存迁移的方向则相反：5.5 的自动前缀检测不需要任何标记，但你既无法触发它也无法调试它；在 5.6 上，同样的 prompt 在你标记之前什么都不做，标记之后会把每次写入都汇报到 usage.prompt_tokens_details.cache_write_tokens 里，未命中会以你自己建的字段里的一个零出现，而不是悄无声息。

哪个档位该跑这个 prompt？

三个档位跑的是同一种请求结构，所以选档位是价格问题，不是 prompting 问题：Sol 每百万 token 收费 $5/$30，Terra 是它的一半，Luna 是五分之一。一旦前缀稳定、带上 key 并且预热完成，缓存读取折扣会把每个档位的输入端价格都拉平，于是输出价格成了真正的区别所在；只要输出质量的 eval 允许，就尽量往下降档。完整的档位算法，包括每个档位的写入溢价盈亏平衡点，都在成本指南里。

FAQ

GPT-5.6 支持 reasoning_effort: “max” 吗？

不支持。带 "max" 的请求会返回 400，并列出从 none 到 xhigh 的合法取值，Sol 和 Terra 都一样。想要拉满的负载应该显式传 xhigh。

缓存断点在 GPT-5.5 上能用吗？

不能。GPT-5.5 及更早的模型会用 400 拒绝 prompt_cache_options 和断点标记。在这些模型上你只能回到自动前缀检测，而它无法主动触发、无法带 key、也无法调试；那里的缓存行为只能当作尽力而为，任何会输出新字段的 prompt 构造器都要按版本做门控。

一个 prompt 到底该用几个断点？

真正会重复的层有几层就用几个，上限内即可：每个请求四个写入位，其中一个会被隐式的自动断点占掉，除非你切到显式模式。一个典型的分层 prompt 需要两到三个（指令、工具、参考块），第五个标记也能被接受、不会报错，但只是共用那些写入位，因为靠后的标记会覆盖它之前的所有内容。

本指南中的所有数字都是首发日通过 Synthorai gateway 在 GPT-5.6 模型上实测得到的，并与实时的 usage.cost 计量对账；方法论和原始探测数据见成本指南和缓存最低量研究。请对照你自己的用量记录核实；费率和可接受取值可能会变。

← 返回博客