為什麼官方不直接給一個統一的省錢比例,而要用「一般工作負載」跟「高度 agentic 工作負載」這種模糊分類?
因為省下的比例本質上不是模型的固定屬性,而是「你的使用模式」跟「降價幅度」兩者相乘的結果——降價幅度(75%)對所有人都一樣,是固定的;但快取讀取在每個人帳單裡的佔比,完全取決於個別的使用模式,不同帳號、不同任務類型之間可以差很多。如果官方給一個單一數字,對快取佔比特別高或特別低的使用者來說,都會是不準確的資訊。
用「一般工作負載」跟「高度 agentic 工作負載」這兩個分類,本質上是在描述快取佔比的兩個典型端點,而不是精確的技術定義——這也是為什麼這篇文章建議直接回頭算自己的實際佔比,而不是先判斷自己「比較像」哪一種分類:分類本身是為了方便溝通的簡化說法,不是用來套用的精確公式。
如果我實際算出來的省下比例,跟官方說的 25% 或 45% 差很多,是我算錯了嗎?
不一定。這條公式(快取佔比乘以 75%)算出來的是理論上的預期值,實際帳單可能因為幾個因素而跟這個預期值有落差。第一個因素是效果等級(effort level)——Fable 5.1 在 Claude Code 裡預設用高強度(High effort),在 Claude Cowork 跟 Claude.ai 裡預設用中強度(Medium effort),不同效果等級本身會影響輸出 token 的數量,進而改變輸入輸出跟快取讀取三者在帳單裡的相對比例。
第二個因素是任務本身的行為變化——如果 Fable 5.1 因為推理能力提升,同一個任務用更少的來回對話就完成,或是產生的輸出內容本身更精簡,帳單的組成結構就會跟你原本用 Fable 5 時的習慣模式不一樣,直接拿舊的用量紀錄去套公式,算出來的預期值自然會跟新模型的實際帳單有出入。比較保守的做法,是拿到新模型實際跑過一段時間的用量數據之後,再重新算一次,而不是只用升級前的舊資料做一次性估算。
要實際計算自己的快取佔比,需要哪些資料,具體怎麼算?
最基本需要的是一段時間內(建議至少涵蓋幾天到一週的正常使用情況,避免單一天的異常波動)的用量明細,裡面要能區分出三個項目:新輸入的 token 用量、模型輸出的 token 用量、快取讀取的 token 用量(如果你有用到快取寫入,這部分也可以記下來,但寫入的定價本身沒有變動,不影響這次的計算)。
算法本身很直接:把快取讀取的 token 數量,除以「新輸入 token + 輸出 token + 快取讀取 token」的總和,得到的比例就是快取讀取在你帳單裡的佔比。把這個比例乘以 75%,就是你這個工作負載理論上能省下的整體費用比例。舉例來說,如果某段時間內你的快取讀取 token 是 600 萬,新輸入是 300 萬,輸出是 100 萬,總和是 1000 萬,快取讀取佔比就是 60%,乘以 75% 大約是 45%——這代表你的使用型態已經很接近官方說的「高度 agentic 工作負載」。
如果算出來的省幅不高,有沒有辦法主動提高快取讀取的佔比,讓自己更接近官方說的高省幅那一端?
有,但前提是這麼做要符合你原本的任務需求,而不是為了省錢刻意扭曲工作流程。實際能提高快取佔比的做法,通常是讓重複性高的內容(系統指令、工具定義、常用的參考文件、專案的背景說明)盡量維持穩定不變,放在對話或請求的固定位置,讓這部分內容有機會被快取命中,而不是每次都用稍微不同的措辭重新描述一遍——即使語意相同,措辭上的微小差異也可能導致快取沒有命中,退回用原價計算。
另一個方向,是評估自己的任務是不是可以合併成更長、更連續的 session,而不是拆成很多次各自獨立、彼此沒有延續脈絡的短請求——因為快取命中的前提是「這段內容之前已經被處理過」,如果每次請求都是全新開始,自然沒有快取可以命中。但這兩個調整都應該以任務本身的合理性為優先,如果你的使用情境本來就是大量獨立、彼此無關的短查詢,勉強湊成長對話反而可能犧牲回應品質,不是划算的取捨。
Claude Fable 5.1 把快取讀取(prompt cache reads)的價格從每百萬 token 1 美元降到 0.25 美元,降幅 75%。Anthropic 官方給出的估算是「一般工作負載省 25%,高度 agentic 工作負載省 45%」,但這兩個數字不是隨機分布,背後有一條可以自己計算的公式——搞懂這條公式,你就能大概估出自己的實際帳單會省多少,而不是套用官方給的兩個籠統區間。
Fable 5.1 的基礎輸入價格維持每百萬 token 10 美元,輸出價格維持 50 美元,五分鐘快取寫入維持 12.5 美元,一小時快取寫入維持 20 美元——這幾項全部沒動。唯一改變的是快取讀取:從 1 美元降到 0.25 美元。這代表你的帳單裡,只有「快取讀取」這一項的單價變便宜了,其他項目(新輸入的 token、模型輸出的 token、快取寫入)的單價完全沒變。
因為只有一項單價改變,實際省下的百分比,約略等於「快取讀取原本佔你帳單的比例」乘以「75%」。如果你的帳單裡,快取讀取原本佔三分之一,實際省下的就是 33% 乘以 75%,大約 25%——這正好對應官方說的「一般工作負載」。如果你的帳單裡快取讀取佔到六成,省下的就是 60% 乘以 75%,大約 45%——對應官方說的「高度 agentic 工作負載」。這也是為什麼官方給出的是一個範圍,而不是單一數字:因為每個人帳單裡快取讀取的實際佔比不一樣,套用同一個 75% 折扣,算出來的整體省幅自然也不一樣。
快取讀取佔比高的典型情境,是同一份大型上下文被重複讀取很多次——例如一個 agent 反覆讀取同一份程式碼庫、同一套系統指令、同一批工具定義,或是持續累積、越來越長的對話紀錄。這類任務每執行一步,通常都要把已經處理過的上下文重新讀一次,而這些重複讀取的部分,正是快取機制設計要優化的對象。相對地,如果你的使用情境是每次都送出全新、彼此不太相關的內容(例如每次都是獨立的短問答,沒有累積脈絡),快取讀取本來就佔不到帳單多少比例,這次降價對你的實際影響也會比較小。
如果你想知道自己實際落在哪個區間,而不是套用官方給的兩個籠統數字,最直接的做法是回頭看一段時間內的實際用量紀錄,把快取讀取的 token 用量,除以總 token 用量(輸入加輸出加快取讀取),算出快取讀取在整體帳單裡的實際佔比,再乘以 75%,就是你自己工作負載大概能省下的比例。如果你手上還沒有這份用量紀錄,值得先花時間把它拉出來——這比直接假設自己屬於「一般」或「高度 agentic」哪一類,估得更準。