Response Cache
相同請求直接回傳快取結果，不呼叫上游、不計費
Response Cache 讓完全相同的請求直接回傳上一次的回應：不呼叫上游、延遲只剩毫秒級，而且不計費。適用於 POST /v1/chat/completions 與 POST /v1/responses（含串流）。
與 Prompt Cache 不同：Prompt Cache 仍會呼叫上游、只是前綴比較便宜；Response Cache 則完全不打上游。
啟用方式
預設關閉。用請求 header 開啟，或在 Preset 設定預設值：
curl https://api.hakila.ai/v1/chat/completions \
-H "Authorization: Bearer $HAKILA_API_KEY" \
-H "Content-Type: application/json" \
-H "X-Hakila-Cache: true" \
-H "X-Hakila-Cache-TTL: 600" \
-d '{"model":"openai/gpt-5.6-luna","messages":[{"role":"user","content":"用一句話介紹 Hakila"}]}'請求 header
| Header | 值 | 說明 |
|---|---|---|
X-Hakila-Cache | true / false | 開啟或關閉這次請求的快取 |
X-Hakila-Cache-TTL | 秒數 | 存活時間，範圍 1–86400（只取前導數字，超出範圍會夾到邊界） |
X-Hakila-Cache-Clear | true | 先刪除同一把 key 的舊條目，再照常呼叫上游並存入新結果 |
開關優先順序
- Preset 設為強制關閉 → 關閉（header 無法開啟）
X-Hakila-Cache: false→ 關閉X-Hakila-Cache: true→ 開啟- Preset 設為預設開啟 → 開啟
- 其他情況 → 關閉
TTL 依序取 X-Hakila-Cache-TTL → Preset 的 TTL → 預設 300 秒。
回應 header
啟用快取時，回應會帶上：
| Header | 何時出現 | 說明 |
|---|---|---|
X-Hakila-Cache-Status | 一律 | HIT 或 MISS |
X-Hakila-Cache-TTL | 一律 | MISS：這次存入的 TTL；HIT：剩餘秒數 |
X-Hakila-Cache-Age | HIT | 條目存入至今的秒數 |
X-Hakila-Cache-Source-Id | HIT | 當初產生這筆快取的請求 id |
Cache key
下列項目全部相同才會命中：
- 同一把 Hakila API Key（不同金鑰、不同工作區之間不共用）
- 同一個端點（
/v1/chat/completions與/v1/responses各自獨立） - 串流與否（
stream: true與非串流各自獨立） - 請求 body：套用 Preset、清除空欄位之後的 JSON 字串
body 以字串比對，欄位順序不同就是不同的 key；temperature、seed 等任何參數不同也不會命中。
命中時的回應
- Chat Completions：
id換成新的請求 id、created換成現在時間 - Responses：
id維持原值（之後 retrieve 或previous_response_id仍可使用） usage內所有數字歸零- 串流請求會以 SSE 回放完整事件（逐行改寫後送出，結尾一樣是
data: [DONE]）
用量紀錄會記為 HIT、tokens 0、不產生費用；Console 的 Logs 會顯示「Cache HIT」徽章。
什麼時候不會存
- 上游回應不是 2xx，或串流中途出現錯誤事件
- 呼叫端提前斷線、串流沒有正常結束
- 回應超過 1 MB
- Responses 的
background: true請求，或狀態不是completed的回應
注意事項
- 同時送出的相同請求不會合併，會各自呼叫上游
- 命中時仍會檢查模型允許清單；若模型已被移出允許清單，請求會照常走路由並回
400 - 組織儲值餘額或預算用盡時，請求在進入快取前就會被
402擋下 - 快取結果不會因為上游模型更新而失效，需要時請用
X-Hakila-Cache-Clear: true或縮短 TTL