提示詞快取 | OpenAI API

提示詞快取為何重要

當多個請求使用相同的提示詞前綴時，提示詞快取可以重用先前的運算結果。這帶來三項主要優點：

節省運算： 避免重新計算模型已處理過的提示詞前綴。
降低輸入 Token 費用： 重用的 Token 按模型較低的快取輸入費率計費，最高可省下 90%。
加快速度： 縮短開始回應前處理輸入所需的時間。

支援提示詞快取的 OpenAI 模型預設會啟用這項功能。使用提示詞快取儀表板監控快取讀取命中率，並使用提示詞快取診斷工具診斷快取未命中的原因，提高快取重用率。

Agents API 的模型呼叫採用與 Responses API 相同的提示詞快取行為。在工作階段內重用上下文可保留共用的提示詞前綴，但維持工作階段並不保證快取命中。如需瞭解工作階段的用量欄位及子代理程式的用量核算方式，請參閱可觀測性與用量。

提示詞快取的定價依模型而異。請參閱 API 定價，瞭解目前快取輸入與快取寫入的費率。快取寫入並非額外收費：輸入 Token 會依未快取輸入、快取輸入或快取寫入其中一種費率計費。

什麼是提示詞快取？

模型處理輸入 Token 時，必須計算稱為鍵值（KV）狀態的中間狀態。這些狀態讓模型在處理新輸入及生成輸出 Token 時，能夠參照先前的 Token。

提示詞快取會保存可重用前綴的狀態；前綴是指提示詞開頭未變更的 Token。當後續請求具有相同的前綴，並找到相符的快取項目時，模型就能重用已儲存的狀態，無須再次處理那些 Token。不過，模型仍需處理所有新輸入，才能生成新的回應。

提示詞快取儲存的是鍵值（KV）張量，而非 Token 本身。

請 ChatGPT 提供更深入的說明

OpenAI 會快取模型組合後的完整上下文，包括 OpenAI 提供的指示、開發人員訊息、工具定義，以及含有文字、圖像、文件和支援的音訊的對話歷史紀錄。

若要重用快取，組合後的整個前綴都必須相符。如果中斷點之前的內容或相關設定有所變更，從變更位置起，前綴就無法再與現有快取項目相符。

變更請求不一定會捨棄現有的快取項目。關鍵在於後續請求是否具有相同的前綴，以及能否找到符合條件且相符的中斷點。主要應檢查下列設定：

設定	影響
`model`	不同的模型可能使用不同的權重，快取行為也可能不同。
`tools`	會變更工具名稱、說明、結構描述、順序或工具專屬指示。
`parallel_tool_calls`	可能變更在單一回合中呼叫多個工具的相關指示。
`text.format`（結構化輸出）	會加入輸出格式指示及指定的結構描述。
`reasoning.effort`	可能變更模型端的推理指示。在支援的模型上，可使用組態更新來調整推理強度，同時保留先前的前綴。
`text.verbosity`	可能變更回應詳細程度的相關指示。
`context_management`（壓縮）	會以壓縮後的上下文取代先前的對話內容，可能導致從第一個變更的 Token 起無法重用快取。

快取的運作方式

快取中斷點 標記提示詞前綴的結尾，OpenAI 可將該前綴存入快取，供後續請求重用。第一個請求會將符合條件的前綴寫入快取，後續請求則會尋找可用且相符的最長快取前綴，從後往前逐一檢查符合條件的中斷點，直到找到相符的前綴。

提示詞前綴必須達到模型的 可快取最小 Token 長度 ，才能存入快取。OpenAI 提供的隱藏系統內容中的 Token 不計入此下限。GPT-5.6 及後續模型的可快取最小提示詞長度為 1,024 個 Token；較早模型的下限則依請求設定而異。詳情請參閱模型比較。

達到可快取最小 Token 長度後，您可以明確指定快取中斷點的位置，或讓 OpenAI 以隱含方式選擇位置。可用選項依模型而異。

對 GPT-5.6 及後續模型而言，快取寫入費率為標準未快取輸入 Token 費率的 1.25 倍。如果您確定前綴會被重用，這筆費用就值得支付，因為後續讀取的費率僅為標準費率的 0.1 倍。將前綴寫入一次並完整重用一次，成本為一般輸入成本的 1.35 倍；若不使用快取而處理兩次，成本則為 2 倍。每多讀取一次快取，就能省下更多費用：以十個請求來說，一次寫入加上九次完整讀取的成本為 2.15 倍，不使用快取則為 10 倍。

同時支援隱含快取與明確快取；明確快取可讓您更精確地控制哪些上下文會寫入快取。

明確模式： 您可依據上下文管理需求，選擇快取中斷點的位置。

將 prompt_cache_options.mode 設為 explicit，即可僅使用開發人員選定的中斷點。接著，在輸入訊息中受支援的內容區塊加入 prompt_cache_breakpoint: { "mode": "explicit" }，以標記各個所需的中斷點。
若未設定任何明確中斷點，請求就不會使用提示詞快取，也不會寫入快取。
僅使用明確中斷點的模式可讓您選擇快取寫入的結束位置。最後一個選定中斷點之後的內容，會按未快取輸入 Token 費率處理，不收取快取寫入費用。如此便可避免將會變動且不太可能重用的內容寫入快取。
多個明確中斷點可保存變更頻率不同的前綴。每個請求最多可執行四次快取寫入。
additional_tools 輸入項目目前不接受 prompt_cache_breakpoint。

頂層 instructions 不能包含明確中斷點。若要標記可重用的開發人員指示，請將指示放在開發人員訊息內的 input_text 區塊中。

隱含模式： OpenAI 會自動選擇適合大多數使用案例的中斷點位置，無須額外設定。

當 prompt_cache_options.mode 為 implicit 時，OpenAI 會在最新一則符合條件的訊息結尾設定中斷點。符合條件的訊息包括：
- 使用者訊息
- 一組連續工具回應中的最後一則工具回應
- 開頭一組連續開發人員訊息中的最後一則開發人員訊息。
你可以新增顯式斷點，而不必關閉隱式斷點；隱式斷點會占用四個快取寫入名額中的一個，因此還有三個名額可供顯式快取寫入使用。

前綴比對的運作方式

OpenAI 只會依前綴由長到短的順序，逐一檢查傳入請求中的 快取查詢邊界 （說明如下），尋找機器上已快取且可用的相符前綴。

對於 GPT-5.6 及更新的模型，傳入請求中的快取查詢邊界包括：

僅顯式模式： 最前面的 2 個和最近的 50 個顯式斷點。
隱式模式： 最前面的 2 個和最近的 50 個顯式斷點、隱式斷點、最多 20 個較早且符合資格的訊息結尾，以及開頭連續一組開發人員訊息的結束位置。這讓隱式模式即使未在較早的訊息結尾設定顯式斷點，也能重用以該處為結尾的前綴。

模型世代

快取模式

隱式

顯式

隱式斷點會設在最新且符合資格的使用者訊息處。

隱藏系統工具開發人員上下文歷程後續訊息已快取的輸入未快取的輸入

最短可快取長度（因模型而異）

請求 1

12,000 個輸入 Token

3,000 個 Token（示意）

請求 2

15,000 個輸入 Token

3,000 個 Token（示意）

2.5k

7.5k

10k

12.5k

15k

17.5k

20k

輸入 Token（包括示意用的隱藏 Token）

15,000

最後一個相符斷點

−

3,000

隱藏的 Token

12,000

回報的已快取 Token 數

請求 1 · Responses API 請求

import OpenAI from "openai";

const client = new OpenAI();
const response = await client.responses.create({
  "model": "gpt-5.6",
  "reasoning": {
    "effort": "medium",
    "context": "all_turns"
  },
  "text": { "verbosity": "medium" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "8,000 tokens"
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "2,000 tokens"
        }
      ]
    }
  ],
  "tools": [
    "Tool definitions, 2,000 tokens"
  ],
  "prompt_cache_key": "shared-workflow-v1",
  "prompt_cache_options": {
    "mode": "implicit",
    "ttl": "30m"
  }
});

請求 2 · Responses API 請求

import OpenAI from "openai";

const client = new OpenAI();
const response = await client.responses.create({
  "model": "gpt-5.6",
  "reasoning": {
    "effort": "medium",
    "context": "all_turns"
  },
  "text": { "verbosity": "medium" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "8,000 tokens"
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "2,000 tokens"
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "3,000 tokens"
        }
      ]
    }
  ],
  "tools": [
    "Tool definitions, 2,000 tokens"
  ],
  "prompt_cache_key": "shared-workflow-v1",
  "prompt_cache_options": {
    "mode": "implicit",
    "ttl": "30m"
  }
});

請求 1 · 回應用量

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 0,
      "cache_write_tokens": 12000
    }
  }
}

請求 2 · 回應用量

{
  "usage": {
    "input_tokens": 15000,
    "input_tokens_details": {
      "cached_tokens": 12000,
      "cache_write_tokens": 3000
    }
  }
}

快取存留時間

快取項目不會永久儲存。後續請求只有在快取項目仍可用時，才能重複使用已快取的前綴。重複使用前綴會重設其存留時間，且不會再次收取快取寫入費用。存留時間與保留設定依模型而異。

快取位置

快取狀態儲存在個別機器上；當流量超過每分鐘 15 個請求時，可能會觸發溢位路由，將請求轉送至其他機器。請求只有送達持有相符且尚未過期快取項目的機器，才能重複使用已快取的前綴。因此，將請求路由至正確的機器，對於重複使用快取相當重要。

快取不會在組織之間共用，也無法跨越區域處理邊界重複使用。

OpenAI 會自動處理路由。在同一組織與處理區域內，特定模型的路由取決於：

機器目前的負載與可用容量。
隱藏的 OpenAI 內容之後，起始 Token 的雜湊值；若有工具定義，也會納入其中。用來計算雜湊的 Token 數量依模型而異。
提供的 prompt_cache_key，可讓不同請求群組分別重用各自的快取，並有助於最佳化 GPT-5.6 之前模型的快取路由。

模型差異摘要

行為	GPT-5.6 及後續模型	GPT-5.5 和 GPT-5.5 Pro	其他較早的模型
隱式中斷點	位於最新一則符合條件的訊息結尾。	每隔 2,048 個 Token 設置一個。	以固定間隔設置，間隔長度依模型而異。
顯式中斷點	支援	不支援	不支援
`prompt_cache_key`	可選用，用於分別核算快取用量與費用	使用固定的鍵來最佳化快取路由	使用固定的鍵來最佳化快取路由
可快取的最短前綴	1,024 個可見的輸入 Token	依請求設定而異	依請求設定而異
快取 Token 數量回報	精確計算至符合條件的邊界，不含隱藏 Token	排除隱藏 Token，並向下取整至 128 的倍數	排除隱藏 Token，並向下取整至 128 的倍數
快取讀取費用	未快取輸入 Token 費率的 0.1 倍	依模型而定的快取輸入費率	依模型而定的快取輸入費率
快取寫入費用	未快取輸入 Token 費率的 1.25 倍	不另收快取寫入費用	不另收快取寫入費用
快取存留時間控制	`prompt_cache_options.ttl`	`prompt_cache_retention`	`prompt_cache_retention`
支援的保留設定值	`"30m"`	僅支援 `"24h"`	`"in_memory"` 或 `"24h"`^*
快取存留時間	最近一次寫入或重複使用後至少 30 分鐘	通常約 30 分鐘，最長可達 24 小時	`in_memory` 通常在未使用後保留 5 至 10 分鐘，`24h` 則最長可保留 24 小時

* gpt-5.5、gpt-5.5-pro、gpt-5.4、gpt-5.2、gpt-5.1-codex-max、gpt-5.1、gpt-5.1-codex、gpt-5.1-codex-mini、gpt-5.1-chat-latest、gpt-5、gpt-5-codex 和 gpt-4.1 支援延長保留。

對於 GPT-5.6 之前的模型，可快取的最短輸入長度會隨請求設定而異，包括工具、圖像、輸出結構描述、推理強度及回覆詳細程度。

請 ChatGPT 找出我的請求可快取的最短輸入長度

如何最佳化提示詞快取

重點是保留對話記錄、保持工具定義穩定，以及選擇快取的位置。使用 GPT-5.6 及更新版本的模型時，請透過 prompt_cache_options.mode 和 prompt_cache_breakpoint 控制快取中斷點。若您的應用程式需要為客戶分別核算快取用量與費用，也可以選用 prompt_cache_key。使用 GPT-5.6 之前的模型時，請為共用可重用前綴的請求使用固定的 prompt_cache_key，以最佳化快取路由。

請 ChatGPT 協助最佳化我的提示詞快取

在多輪對話應用程式中，重複使用持續累積的對話歷史記錄，比只快取最初的指示更能節省輸入 Token。保留先前的訊息與工具結果，讓後續輪次能重複使用完整的共用前綴。

保持前綴穩定。 將穩定的開發者指示與共用參考資料放在最前面。如果開發者指示或共用資料包含時間戳記、使用者專屬內容或其他動態內容，請將這些內容放在末尾，而非開頭，或移至後續的對話訊息中。
保留對話歷史記錄。 附加新訊息，不要改寫先前的對話輪次。摘要、壓縮或截斷上下文都可能改變前綴，導致快取重複使用必須重新開始。
在不改寫前綴的情況下變更推理強度。 在 GPT-6 Astra 中，附加一個 configuration_update 輸入項目，即可在回應之間變更推理強度，同時保持請求層級的 reasoning.effort 不變。這樣可保留原始前綴，以便重複使用快取。如需範例與相容性限制，請參閱在對話中途變更推理強度。

將會變動的內容放在中斷點之後

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26{
  "model": "gpt-5.6",
  "reasoning": { "effort": "low", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "developer",
      "content": "Dynamic developer instructions, such as user-specific content and timestamps..."
    },
    {
      "role": "user",
      "content": "The user's current question..."
    }
  ]
}

在支援此功能的 GPT-6 及更新模型中，附加一個 configuration_update 輸入項目，即可在對話過程中變更推理強度，同時保留先前已快取的前綴。請保持最上層的 reasoning.effort 為原始值，因為變更此設定可能會改寫隱藏系統指示中的內容。

最新的組態更新會決定後續回應的推理強度。例如，將此項目附加至現有的 input 陣列，即可讓後續請求切換至 high 推理強度：

要附加至 input 陣列的項目

1
2
3
4{
  "type": "configuration_update",
  "reasoning": { "effort": "high" }
}

如果許多請求重複使用相同的開發者指示與工具定義，但共用前綴未達模型的最低可快取長度，可考慮縮短前綴，或加入有用且穩定的指示、範例或參考資料來擴充前綴。請衡量重複使用快取所節省的費用，是否足以抵銷額外的輸入 Token 與任何快取寫入費用，並確保評估結果與行為維持穩定。

圖表突顯了最低可快取長度的成本陷阱：較短的前綴無法使用快取，其成本可能高於將前綴擴充至最低可快取 Token 長度的成本。

提示詞長度與輸入成本

可快取的最低 Token 數每次寫入後的完整快取讀取次數快取讀取費率倍數快取寫入費率倍數

500

1,000

1,500

2,000

可重用前綴長度（Token 數）

若只比較成本，令 $M$ 為可快取的最短長度， $L < M$ 為原始前綴長度， $r$ 為快取讀取費率倍數， $w$ 為快取寫入費率倍數，而 $N$ 為請求總數。假設擴展後的前綴恰好包含 $M$ 個 Token，只寫入一次，且後續每個請求都會完整重用。以未快取輸入 Token 的等值數量計算，保留原始前綴的成本為 $N \times L$ ，擴展前綴的成本則為 $M \left[w + (N - 1)r\right]$ 。兩者成本相同時的原始長度為：

L_{\mathrm{break\text{-}even}} = M\left(r + \frac{w-r}{N}\right)

適合擴展前綴的條件為 $L > L_{\mathrm{break\text{-}even}}$ ；保留較短前綴成本較低的條件為 $L < L_{\mathrm{break\text{-}even}}$ 。相等時，兩者成本相同。擴展前綴可降低成本的最小整數 Token 長度為 $\left\lfloor L_{\mathrm{break\text{-}even}} \right\rfloor + 1$ 。反之，將可快取的前綴縮短至低於 $M$ 就無法使用快取：在相同假設下，較短且未快取的前綴必須短於 $L_{\mathrm{break\text{-}even}}$ ，成本才會低於快取 $M$ 個 Token 的成本。沒有一個通用的提示詞長度會讓成本最高；成本交叉點取決於重用次數與定價。

例如，當 $M = 1{,}024$ 、 $r = 0.1$ ，且 $w = 1.25$ 時，成本交叉點為 $102.4 + \frac{1{,}177.6}{N}$ 個 Token。以 10 次請求計算，將至少 221 個 Token 的原始前綴擴展至 1,024 個 Token，成本會更低。隨著重用次數增加，成本交叉點會趨近 102.4 個 Token。長度為 103 個 Token 的前綴，總共至少需要 1,963 次請求才能受益；在這些假設下，長度為 102 個 Token 或更短的前綴則永遠無法受益。這項比較未納入效能、輸出 Token，以及不變的請求成本。額外的快取未命中、寫入，或不同的模型費率都會改變結果。

測量實際快取效能。 追蹤 usage.input_tokens_details.cached_tokens、usage.input_tokens_details.cache_write_tokens、輸入 Token 數、延遲與實際成本。將快取 Token 總數除以輸入 Token 總數，即可追蹤 Token 快取命中率；計算時，依使用者、工作區、日期或其他實用的分組方式彙總這兩項數據。
計算輸入成本。 使用 response.usage 中的 Token 數與模型的每百萬 Token 價格來計算。
使用提示詞快取儀表板。 在提示詞快取儀表板中監控快取命中率。

計算輸入成本

JavaScript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18function calculateInputCost(
  usage,
  inputPricePerMillion,
  cacheInputMultiplier = 0.1,
  cacheWriteMultiplier = 1.25
) {
  const inputTokens = usage.input_tokens;
  const cachedTokens = usage.input_tokens_details.cached_tokens;
  const cacheWriteTokens = usage.input_tokens_details.cache_write_tokens;
  const ordinaryInputTokens = inputTokens - cachedTokens - cacheWriteTokens;

  const weightedInputTokens =
    ordinaryInputTokens +
    cachedTokens * cacheInputMultiplier +
    cacheWriteTokens * cacheWriteMultiplier;
  const inputCost = (weightedInputTokens * inputPricePerMillion) / 1_000_000;
  return inputCost;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21from openai.types.responses import ResponseUsage


def calculate_input_cost(
    usage: ResponseUsage,
    input_price_per_million: float,
    cache_input_multiplier: float = 0.1,
    cache_write_multiplier: float = 1.25,
) -> float:
    input_tokens = usage.input_tokens
    cached_tokens = usage.input_tokens_details.cached_tokens
    cache_write_tokens = usage.input_tokens_details.cache_write_tokens
    ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

    weighted_input_tokens = (
        ordinary_input_tokens
        + cached_tokens * cache_input_multiplier
        + cache_write_tokens * cache_write_multiplier
    )
    input_cost = weighted_input_tokens * input_price_per_million / 1_000_000
    return input_cost

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17def calculate_input_cost(
  usage,
  input_price_per_million,
  cache_input_multiplier = 0.1,
  cache_write_multiplier = 1.25
)
  input_tokens = usage.input_tokens
  details = usage.input_tokens_details
  cached_tokens = details.cached_tokens
  cache_write_tokens = details.cache_write_tokens
  ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

  weighted_input_tokens = ordinary_input_tokens +
                          (cached_tokens * cache_input_multiplier) +
                          (cache_write_tokens * cache_write_multiplier)
  (weighted_input_tokens * input_price_per_million) / 1_000_000
end

範例

以下範例適用於 GPT-5.6 及更新版本的模型。

以單輪 LLM 評判為例：它會檢視已完成的互動，判斷是否有證據顯示使用者在與聊天機器人互動後感到滿意。每個請求都使用相同的評分準則與已標註的少樣本範例，來評估不同的互動。

保留前綴： 將固定的評分準則與範例放在最前面。選用有助於校準評判模型的材料，並刻意將兩者的總長度維持在略高於模型的可快取最短長度。將待評估的互動放在最後。
快取模式與斷點： 啟用僅明確快取模式，並在固定的評分準則與範例之後設定斷點。待評估的使用者與聊天機器人對話放在該斷點之後，不會寫入快取，避免為不太可能重用的內容支付快取寫入費用。

某個採用這些原則的部署案例回報， Token 快取命中率約為 70%。這個數字僅用來說明一種可能的結果。實際的快取命中率上限取決於您的上下文與應用程式使用情況。

單輪評判的 Responses API 請求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Judge whether the completed interaction provides evidence that the user is satisfied. Return true or false. Full grading rubric and labeled few-shot examples...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "user",
      "content": "Completed interaction to evaluate..."
    }
  ]
}

以使用長篇共用開發者指令、且頻繁呼叫工具的多輪智慧體為例。典型使用情況是使用者同時與智慧體進行多個工作階段，並經常為對話串建立分支。

保留前綴：每一輪都會附加新的訊息、工具呼叫與結果，而不改寫先前的上下文，因此可重用前綴會隨時間增長。
選用的提示詞快取鍵： 此範例使用 agent_123_v1:user_456 為使用者 456 維持獨立的快取用量核算，讓其快取 Token 用量與計費更容易說明。這也有助於防止使用者透過快取命中情況探測其他使用者的內容。該使用者與智慧體的各個工作階段及分支都使用相同的鍵。如果應用程式不需要這種區隔，可以省略此鍵。
隱含快取模式： 啟用隱含快取，讓最新一則符合條件的使用者或工具訊息提供斷點。
明確斷點： 在每個工具結果之後加入斷點，以保留先前可重用的前綴，並提高建立分支時的快取效率。

某個採用這些原則的部署案例回報， Token 快取命中率 >90%。這個數字僅用來說明一種可能的結果。實際的快取命中率上限取決於您的上下文與應用程式使用情況。

多輪智慧體的 Responses API 請求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_key": "agent_123_v1:user_456",
  "prompt_cache_options": { "mode": "implicit" },
  "tools": [
    {
      "type": "function",
      "name": "function_name",
      "description": "Function description",
      "parameters": { "...": "..." }
    }
  ],
  "input": [
    {
      "role": "developer",
      "content": "Stable developer instructions and reference material..."
    },
    { "role": "user", "content": "Can you do...?" },
    {
      "type": "function_call",
      "call_id": "call_123",
      "name": "function_name",
      "arguments": "..."
    },
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": [
        {
          "type": "input_text",
          "text": "Tool result...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "assistant", "content": "Assistant response..." },
    { "role": "user", "content": "Can you also do...?" }
  ]
}

常見陷阱

由於隱式快取的行為有所改變，這種情況在從較早的模型遷移至 GPT-5.6 或更新版本時尤其常見。如果多個請求共用一段較長的前綴，但後綴不同，僅以隱式快取儲存第一個完整請求，並不會讓其中較短的共用前綴變得可重用。

假設每個請求都先包含一則靜態開發人員訊息，接著是一則動態使用者訊息。這個請求會將包含動態內容在內的整段前綴寫入快取。如果下一個請求改變了動態內容，就無法符合快取中較長的前綴，而靜態內容之後也沒有獨立的斷點。

未在靜態內容之後設定斷點

1
2
3
4
5
6
7
8
9
10{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "implicit" },
  "input": [
    { "role": "developer", "content": "Static content..." },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

若要解決這個問題，請在兩個請求的靜態內容之後都設定顯式斷點。第一個請求會寫入可重用的前綴；下一個請求即使動態內容改變，仍可重用該前綴。這個範例使用僅顯式模式，避免將動態內容寫入快取。

在靜態內容之後設定斷點

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Static content...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

假設請求 1 使用隱式模式，將截至某則使用者訊息結尾的前綴寫入快取，接著請求 2 保留該前綴，但改用 prompt_cache_options.mode: "explicit"。如前綴比對的運作方式所述，請求 2 只會檢查自身輸入中的顯式斷點，因此不會重用請求 1 儲存的隱式前綴，除非請求 2 中的某個顯式斷點與請求 1 的快取終點相符。

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message] ▼

- Request 2: explicit-only mode. Does not hit cache.
  [Developer message][User message][Follow-up] ▼

若要重用請求 1 的隱式前綴，請在請求 2 中對應的內容區塊邊界設定顯式斷點，或繼續啟用隱式模式，讓先前符合條件的訊息結尾仍可作為快取查找的候選位置。

即使兩個請求都使用隱式模式，保留相同的起始 Token 也不一定足夠。假設請求 1 的最後一則使用者訊息包含 Content A，接著請求 2 將同一則訊息延長為 Content A + Content B。原本位於 Content A 之後的終點，現在落在訊息內部，而非訊息結尾。如前綴比對的運作方式所述，如果沒有在該邊界設定顯式斷點，請求 2 就不會重用儲存在該處的前綴。

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message: Content A] ▼

- Request 2: implicit mode. Cannot reuse the prefix through Content A.
  [Developer message][User message: Content A + Content B] ▼

如果對話結構允許，請保留原始訊息，改為附加一則新訊息。否則，請將可重用的文字放在獨立的內容區塊中，並在兩個請求中都於該區塊之後設定顯式斷點。

建議

開始使用

核心概念

SDK 與 CLI

資源

舊版 API

選擇模型

文字與程式碼

提示詞

推理

圖像與影片

即時互動與音訊

專用模型

智慧體 API

智慧體 SDK

ChatKit

搜尋與檢索

連接工具與資料

建立工具工作流程

電腦與程式碼

媒體

GPT-Live

Realtime API

開發語音應用

連線

音訊處理

正式上線

效能與品質

成本與吞吐量

安全與治理

基礎架構與存取

營運

核心概念

Plan

Build

Test and publish

Conversion specs

指南

資源

開始使用

指南

File Upload

API

Measurement

Advertiser API

API 參考文件

開始使用

基礎

探索

適用平台

版本資訊

工作流程

能力

參考資料

自訂

設定檔

智慧體組態

擴充 ChatGPT 與 Codex 的功能

Linux

Windows

開發工作流程

擴充與自動化

環境

使用 Codex 進行建置

第三方整合

參考資料

權限

Codex Security

網路安全

開始使用

ChatGPT Work

身分識別與身分驗證

工作區存取權、政策與模型

外掛程式與連接器控制措施

使用情況、治理與合規

部署與模型供應商

社群

部落格

社群

部落格