/model 來切換模型只是一瞬間的事。只要快取還是熱的，還會跳出確認視窗（2.1.238 之後）。那麼，這時候到底丟掉了什麼？
因為 Claude Code 2.1.251 開始，提示詞快取可以用數字看得見了，所以我實測了一下。
同一個工作階段持續 重寫 197 個 token
切換到 sonnet 重寫 56,584 個 token ← 287 倍
維持 sonnet 繼續 重寫 149 個 token
切回 opus 重寫 67 個 token ← 回程比較便宜驗證環境：Windows 10 / Claude Code 2.1.251 / 測量截至 2026-09-01
現在可以看到什麼
從 2.1.251（8/28）開始，/usage 會出現 Prompt cache (main) 這一行。可以看到命中率、未命中次數，以及現在是不是 warm 狀態。從 statusline 也能透過 prompt_cache 讀到同樣的數字。
另外，/cost 和 /usage 其實是同一個畫面。 changelog 說的是「加到 /cost」，文件則寫成「執行 /usage」。用 -p 兩邊都打一次，輸出完全一樣（不過 -p 顯示的是方案使用量畫面，Prompt cache (main) 那一行只有在互動式工作階段才會出現）。
如果要自己量測，--output-format json 最快。
claude -p "hi" --resume <工作階段 ID> --output-format json要看的欄位是 cache_read_input_tokens（讀到的部分）和 cache_creation_input_tokens（重新寫入的部分）這兩個。
只有切換模型的那一回，重寫量就暴增 287 倍
同一個工作階段用 --resume 連續跑 4 次，中途只換了模型。
模型readcreate1opus79,0181972切換到 sonnet34,09056,5843保持 sonnet90,6741494切回 opus90,82367**暴增的只有切換那一回。 官方說明寫著「各模型都有自己的快取」「切換時會在沒有快取命中的情況下重新讀取」。重寫量暴增確實如預期，但第 2 行的 read 並沒有變成 0。 這應該是因為我在這之前，另外一個工作階段已經先跑過一次 sonnet，那份快取還留著**。如果是第一次切換，read 應該會更小才對。
有趣的是第 4 行。 切回 opus 時，重寫量只有 67 個 token。去程很貴，回程很便宜。 不過 read 卻是 90,823，超過了 opus 先前寫入的量。這部分我也解釋不通。
根據 /usage，我最近 7 天的使用量有 48% 來自開著超過 8 小時的長工作階段。工作階段越長，切換時要丟掉的東西就越多。
調整 TTL 後，快取會分裂成兩份
只要是訂閱方案內的使用量，主對話的快取就會保留 1 小時。可以用 FORCE_PROMPT_CACHING_5M=1 把它降成 5 分鐘，所以我只改 TTL，測了 5 次。
#條件readcreate1 小時框5 分鐘框1預設・第一次078,52178,52102預設・第二次25,53852,98752,98703切換成 5 分鐘078,651078,65145 分鐘・第二次25,66352,985052,9855切回預設**25,53852,98852,9880第 3 行的 read 是 0。 明明 1 小時那邊有熱快取，卻讀不到。接著看第 5 行，切回預設後，25,538 完整無誤地復活了**（和第 2 行一樣）。
不是消失了，而是被放到另一個容器裡了。 在除錯時如果加上 FORCE_PROMPT_CACHING_5M=1，就等於要付出切換那一份重寫成本。
重複執行 claude -p 的話，每次都會丟掉 5 萬個 token
我只改變了「要不要延續工作階段」這件事，連續送了 3 次短提示詞。
readcreate命中率每次都是新的 -p25,53852,98632.5%持續執行78,52436199.5%再持續78,88513399.8%52,986 變成 133，大約是 400 分之 1。
-p 每次都會產生新的工作階段。就算連續執行，讀到的也只有 32.5%。 其餘每次都得重新寫入。
如果在 CI 或批次作業中用迴圈反覆跑 -p，只要延續工作階段，重寫成本幾乎就能消失。
卡住的地方
用 -c（延續前一次對話）時，把實驗資料弄髒了。
我原本想延續測試用的工作階段，結果卻抓到了正在工作的另一個工作階段。 這時候才發現 read 高達 440 萬個 token。-c 會抓取「這個目錄最後一次跑的對話」，和 -p 搭配時，連 -p 產生的內容也會被算進去。 量測時請用 --resume 指定 ID。
還有一個地方是我的推論錯了。
一開始我在新的 -p 裡用 --model sonnet，看到 read=0，就差點寫成「改模型會讓快取失效」。但就算不改模型，只是新的 -p 第一次執行，read 也一樣是 0。 這根本沒有證明任何事。後來重新量測的結果，就是上面的表格。
總結
- 2.1.251 之後，
/usage會多出Prompt cache (main)這一行。/cost是同一個畫面 - 用
--output-format json的 read / create token 數，可以量出自己環境的狀況 - 只有切換模型的那一回，重寫量會從 197 暴增到 56,584（287 倍）。
但切回來時只有 67 個 token。去程很貴，回程很便宜 - 調整 TTL 會讓快取分裂成兩份。 切回預設後，原本的數值會完全一樣地復活
- 重複執行
claude -p的命中率只有 32.5%。 延續工作階段後可到 99.8%。重寫成本約只剩 400 分之 1
模型切換看起來像是免費的，是因為帳單延後一個回合才來。 不是在切換的當下付，而是下一次再說話時才付帳。
參考資料
- How Claude Code uses prompt caching — 會破壞快取的操作清單與 TTL 的決定方式
- Manage costs effectively —
Prompt cache (main)這一行的讀法 - Status line —
prompt_cache的所有欄位 - CLI reference —
-c和--resume的差異
相關文章
- /model 按過一次之後，ANTHROPIC_DEFAULT_MODEL 就不會生效了 — 同樣是按了
/model之後會發生的事 - 已經不能用環境變數固定子代理的模型了 — 關於模型指定優先順序的話題
JQIT 的工程師中，95% 以上都是從沒有經驗的人才錄用的。
如果可以，也歡迎來公司網站逛逛。
▶ 公司網站
我們也有工程師招募。如果有興趣的話，歡迎看看。
▶ 招募網站
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
