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…" }
  ]
}

背後的排序規則是：所有穩定的內容放在斷點之前，所有每次請求都會變的內容放在斷點之後，而任何動態的東西（時間戳記、使用者名稱、每次呼叫都不同的檢索文件）絕對不能落在標記的區塊裡，因為只要有一個 byte 變了，整個區塊就會用 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。等評測告訴你這個任務需要，再把旋鈕往上調，而不是因為預設值已經幫你花掉了才調。

提示詞要怎麼排，快取才划算？

按穩定度由高到低分層排列提示詞，並標記每一層：先放系統指令，接著是工具定義，然後是參考文件，每一層結尾放一個 breakpoint，最後一個標記之後才擺會頻繁變動的 user turn。每個請求可以寫入四次快取；在預設的隱式模式下，最新訊息會自動加上一個 breakpoint，佔掉其中一次，所以明確模式能讓你用滿四次，更重要的是只快取你標記的部分。

划算的關鍵在於部分重用，而且這是量測過的。用一個穩定區塊 A 搭配一段替換的尾段 B，計費器只重新計了尾段：在一個 2,431 個 token 的提示詞裡，有 1,212 個 token 以快取費率讀回，1,210 個以較高費率重新寫入，對照費率表逐位吻合。由此得出三條預算規則：

• 讀取按輸入費率的 10% 計費，所以一段熱的分層前綴能把帳單的輸入面壓平。
• 寫入按 1.25 倍計費，所以一個被標記卻再也讀不到的區塊，成本比不快取還高 25%。標記會重複的部分，而不是所有看起來穩定的部分。
• 完全重複時，命中長度可能掉到標記以下（某次探測中，2,422 個 token 的寫入只快取了 1,897 個），所以要按折扣費率編預算，而不是按精確命中數；各家族的下限請見我們的 快取最小值研究。

ttl: "30m" 的下限是保證的最小值，不是上限，而且是 Claude 預設 5 分鐘的 6 倍；現在已經沒有 24 小時的等級，所以原本靠延長保留期的每日批次工作負載，該重新算一遍損益平衡點。

從 GPT-5.5 移植提示詞時會出什麼問題？

兩個問題會直接報錯，一個會悄悄出事。直接報錯的：prompt_cache_options 和 prompt_cache_breakpoint 在 GPT-5.5 及更舊的模型上會回傳明確的 400（prompt_cache_options is not supported on this model），所以任何共用的 prompt builder 都需要一道版本判斷。另一個直接報錯的：某些 5.5 設定帶著的 "max" effort 會被拒絕。

悄悄出事、而且更花錢的：GPT-5.6 預設會推理，但 5.5 的工作負載可能是把推理關掉的。一個從沒設過 reasoning_effort 的移植提示詞，會在同一份費率表上吃到 1.5 倍的省略稅。快取的遷移方向則相反：5.5 的自動前綴偵測不需要任何標記，卻也無法觸發或除錯；到了 5.6，同一個提示詞在你標記之前什麼都不做，標記後每次寫入都會在 usage.prompt_tokens_details.cache_write_tokens 裡回報，未命中會在這個你自己建立的欄位裡顯示為 0，而不是靜悄悄地什麼都沒有。

該用哪一層跑這個 prompt？

同一種請求結構在三層上都跑得起來，所以選層是價格問題，不是 prompt 問題：Sol 每百萬 token 收 $5/$30，Terra 是一半，Luna 是五分之一。當前綴穩定、keyed 且處於 warm 狀態後，快取讀取折扣會把每一層的 input 端拉平，於是 output 價格成了唯一的區別；只要輸出品質的 eval 能過，就盡量往下降。完整的分層計算，包含每一層的 write-premium 損益兩平點，都在成本指南裡。

FAQ

GPT-5.6 支援 reasoning_effort: “max” 嗎？

不支援。帶 "max" 的請求會回 400，並列出 none 到 xhigh 這些有效值，Sol 和 Terra 都一樣。要用到上限的工作負載應該明確送 xhigh。

這些 cache breakpoint 在 GPT-5.5 上能用嗎？

不能。GPT-5.5 和更舊的模型會用 400 拒絕 prompt_cache_options 和 breakpoint 標記。在那些模型上你只能回到自動前綴偵測，而那是無法觸發、無法 keyed、也無法除錯的；把那裡的快取行為當成 best-effort，並對任何會輸出新欄位的 prompt builder 做版本控管。

一個 prompt 實際上該用幾個 breakpoint？

有幾層真的會重複就用幾個，直到用完額度為止：每個請求四次 write，其中一次會被隱含的自動 breakpoint 用掉，除非你切到 explicit 模式。典型的分層 prompt 需要兩到三個（instructions、tools、reference block），第五個標記不會報錯，但只是共用那幾個 write 槽，因為靠後的標記會涵蓋它之前的所有內容。

本指南的所有數字都是在 GPT-5.6 模型上線首日透過 Synthorai 閘道實測的，並與即時的 usage.cost 計量對過帳；方法論與原始探測資料在成本指南和快取最小值研究裡。請以你自己的使用紀錄為準；費率和可接受的值可能會變動。

← 返回部落格