9月2日我寫了「Claude Fable 5.1 的第 2 回合有時會命中快取、有時不會」。測了 18 次、13 次沒命中,原因不明。
隔天 9 月 3 日的 2.1.260,Fable 5.1 的快取修正進了 3 個。重新測試後如下:
2.1.260 / Fable 5.1 第 2 回合命中率
使用工具 99.7 99.7 99.7 99.7 99.7 99.7 6 次全都命中
不使用工具 38.6 38.6 38.6 38.6 38.6 99.7 … 9 次中 8 次沒命中
我先前測的,不在這次修正的範圍內。
驗證環境:Windows 10 / Claude Code 2.1.260 / 測量時間:2026-09-04
這是發行說明的內容:
Fixed prompt caching on Claude Fable 5.1 not covering the context attached after tool results, so it was re-sent as uncached input on every tool-call turn
(修正了 Fable 5.1 的提示快取沒有涵蓋在工具結果之後附加的 context,導致每次工具呼叫回合都會以未快取輸入重新送出)
條件是「工具結果之後」。
9 月 2 日我測的是 claude -p "hi",一次都沒有呼叫工具。 條件不同。
我用 --resume 延續同一個 session,分別測了使用工具與不使用工具兩種情況。
不使用工具(hi → hi again)
試行readcreate命中率1〜532,047約51,00038.6%682,69621199.7%7〜932,047約51,00038.6%**使用工具**(先用 Read 讀取 1 個 .md 檔,再繼續)
試行readcreate命中率1〜6約163,000425〜49699.7%**6 次全部命中。** 沒有波動。
2.1.258(9/2)2.1.260(9/4)使用工具的回合未測定6 次全都 99.7%**不使用工具的回合18 次中 13 次約 40%9 次中 8 次是 38.6%**不使用工具那一側,還是原樣保留。 甚至往比較低的方向去了(72% → 89%)。試行次數只有 9 次,這個差異可能在誤差範圍內。
把約 50,959 個 token 重新寫入,依照價目表換算。Fable 5.1 的 1 小時快取寫入是 $20/M。
沒命中時 50,959 tok × $20/M = $1.02
命中時 496 tok × $20/M = $0.010
單一回合就差不多 1 美元。 我是訂閱制,不會被另外收費,但以 API 定價來看就是這樣。
讓它呼叫工具就會命中(6 次全都 99.7%)。實際寫程式時通常都會讀檔,所以如果是這種用法,影響應該不大。這部分是推測,沒有實測。
我實際測到的是,不使用工具的那一側還存在。
claude -p 這種只丟問題的 batch這類用法會變成,第 2 回合要重寫 5 萬個 token。
9 月 2 日的文章裡我寫了「18 次中有 13 次沒命中。原因不明」。那是 2.1.258 的實測,記錄本身是正確的。
這次得知的是,那個現象不是 2.1.260 修正的對象。 我認為沒有先假設「既然出了修正就一定好了」而是重新測量,是對的。
「官方發了修正」和「我看到的現象已經修好了」是兩回事。
不要跳過發行說明中的條件。
這次修正附帶了「after tool results」這個限制。若漏看了這點,就會變成:
我差點做成後者。 本來可能會因為用不使用工具都測成一樣,然後直接下結論「沒修好」。
只有在改變條件後重新測試,才算完成驗證。
claude -p 只丟問題 的用法最容易受到影響當發行說明裡寫了條件時,請用那個條件重新測試。 我差點就停在「沒修好」這個結論。
參考資料
※ 引用同時附上原文與日文翻譯。翻譯以易讀性為優先,精確表述請以原典為準。
JQIT 的工程師中,95% 以上都是從零經驗錄用的。
歡迎也來公司網站逛逛。
▶ 公司網站
我們也在招募工程師,如果有興趣,歡迎看看。
▶ 招募網站