Day 15｜token、快取與成本：帳到底怎麼算

Day 14 寫過一句話：快取寫入分成短、長兩種存活期，短存活期那一欄全部是 0，查「大於 0」的列，回傳 0 筆。那次的量測日是 2026-09-20，當天查到的確實如此。2026-09-27 我為這篇重跑同一組查詢，那一欄出現了第一筆非 0：1 列、87,534 個 token，全部落在 2026-09-23 這一天。

上一篇才寫它恆為 0，幾天後它就出現了第一筆。Day 14 沒有寫錯，它提醒我的是另一件事：「目前為 0」只是某一天的觀測，不是這個欄位的性質。接下來的問題是，這一筆會不會動到帳？要回答，得先把帳怎麼算講清楚，而這剛好就是 Day 14 結尾留下的三個問題。

事故：照著單價表重算，對不上紀錄

第一問：定價本身怎麼構成？ 我的等價成本按官方 API 定價換算。下文的等價成本分兩種：系統當下寫進紀錄的紀錄值，和事後照 token 數重算的重算值。單價表以每百萬 token 計，每個模型只給兩個基本價：輸入和輸出。最貴的那個模型（總經理用）是輸入 10、輸出 50 美元，Opus 5 是 5 和 25，Sonnet 是 2 和 10，Haiku 是 1 和 5。其餘價錢都是拿輸入價乘倍率：快取讀取是輸入價的 0.1 倍（Opus 5.5 的基本價另訂，快取讀取是 0.05 倍），短存活期快取寫入是 1.25 倍，長存活期快取寫入是 2 倍。

所以一輪的等價成本就是五項相加：一般輸入、輸出、兩種快取寫入、快取讀取，各自乘上自己的單價。思考量不另外計價：算式裡只有輸出一項，思考是包在輸出裡面的一部分，這是我從算式和欄位說明推出來的。全期的思考量約占輸出的 30.55%，都按輸出價算，沒有第二筆。

有了算式，我做了最直覺的驗算：把紀錄資料庫裡每個模型的 token 數乘上單價，再和同一批列的金額紀錄值對照。

結果對不上。排除 7 個單價表裡沒有的模型之後，金額紀錄值合計 15,472.21 美元（等價成本），照 token 重算只有 5,656.70 美元，差了 9,815.51 美元。只有 Sonnet 和 Haiku 各一列分毫不差，落差大部分集中在最貴的那個模型。金額和 token 數都是系統自己寫下的，放在同一張表的同一批列上。

我第一個念頭是單價表改過，或倍率套錯。我把這筆落差逐條查過，這兩個假說都不成立：這段期間單價與倍率只改過一次，最多只牽涉 1 列、0.19 美元（等價成本）；也找不到任何一筆紀錄比重算還低。問題不在算術，而在兩個數字量的根本不是同一件事。這個答案放到解法段講，先看 token 本身長什麼樣子。

證據：刻度是快取畫出來的

第二問：快取為什麼會讓同樣一段內容差出一截？ 先看數量。全期（2026-09-05 到 09-27）的 token 裡，快取讀取占 95.221%，一般輸入只有 0.341%。這個數量占比只含主控，也包含一批 token 欄位不齊全的舊列，只能當量級看。量級已經很清楚：我送進模型的內容，絕大部分不是「新的輸入」，而是從快取重讀的舊內容。

同一段內容，命運可以差很多。第一次進快取要付寫入價，長存活期是輸入價的 2 倍；之後每一輪重讀只付 0.1 倍。長、短兩種寫入之間，單價差 2 ÷ 1.25 = 1.6 倍。所以同樣一段規則檔或對話前文，讀了幾次、寫的是哪一種存活期、中途有沒有過期重寫，會讓它換算出來的數字差出一截。等價成本這把尺的刻度，就是快取型態畫出來的。

只取逐輪即時寫入的列（排除事後回填的舊列），用 token 數乘現行單價重算，只含主控、不含 subagent。短存活期快取寫入單獨一層，換算約 0.44 美元（等價成本），在這根柱子上幾乎看不見。

圖上只用即時寫入的列：快取讀取 46.40%、長存活期快取寫入 35.16%、輸出 18.40%、一般輸入 0.04%。回到開頭那個矛盾：它確實出現了，但以等價成本來說，占比低到在圖上要用標註才找得到。全期（含舊列）長存活期寫入累積了 114,651,958 個 token，這把尺的刻度還是由它和快取讀取決定。

再來是訂閱額度。紀錄資料庫從 2026-09-12 起才有額度欄，到 09-27 共 1,539 列有值，其中幅度不為 0 的：5 小時窗 621 列、每週全模型窗 217 列、每週 Fable 窗 178 列。

左軸是逐日等價成本累計（紀錄值，含 subagent），右軸是三個額度窗的當日最大百分比。額度含同時段其他 session 與裝置的消耗，而且只有整數百分比。

兩條線走的不是同一個節奏。09-22 是期間單日等價成本最高的一天，1,403.70 美元（等價成本紀錄值），5 小時窗當天最高只到 35%；09-18 只有 662.64 美元，5 小時窗卻到了 100%。額度含其他 session 與裝置的用量，這個差異不能算在本機頭上。

解法：把尺和帳分開讀

先回到事故。那 9,815.51 美元（等價成本）的落差，扣掉前面那 0.19 美元和重算時沒算進去的短存活期寫入 0.44 美元，其餘全部可以按列的來源歸因。金額紀錄值記的是「主控加上這一輪所有 subagent」的花費，token 欄只記主控自己；即時寫入列的落差全屬這一類，共 5,834.94 美元，占 59.45%。另外 3,979.94 美元、占 40.55%，出在事後回填的舊列：回填時一般輸入寫死為 0，快取欄大多補 0，金額卻一樣含 subagent。兩個數字都沒算錯：前一部分是口徑差，後一部分是口徑差再疊上回填缺欄。落差集中在最貴的那個模型，也是同一個原因：subagent 的花費一律記在主控所用模型的名下。

這也順帶修正我對 Day 14 那組數字的讀法：它們量得沒錯，但只涵蓋主控，也沒有包含回填的舊列。

第三問：訂閱制底下，這些數字怎麼解讀才不會自欺？ 我現在守四條：

一、等價成本只當尺，不當帳單。訂閱制實際不按它計費，它只能拿來做相對比較，不能推出「花了多少錢」。

二、總額用紀錄值，組成用重算值。總額要含 subagent，所以用紀錄值；要按 token 類別拆，紀錄值拆不開，只能用即時寫入列重算，而且要寫明只含主控。這裡還有一個口徑限制我還沒補上：要把 subagent 的 token 也拆進來，得另外加總另一份紀錄，這次沒做。

三、不跨表相加。派工稽核裡每個 subagent 的金額，已經包含在逐輪紀錄值裡，兩邊相加就是重複計。

四、額度只看趨勢。它含其他 session 與裝置、只有整數，不能換算成某一輪的消耗。

另外補一條：「恆為 0」要附量測日期。開頭那一欄就是例子。

新問題：每個 session 開門先付的那一筆

四條讀法把尺和帳分開了，卻也讓一個數字變得刺眼：長存活期快取寫入占了主控重算等價成本的 35.16%。

寫入發生在內容第一次進快取的時候。新開一個 session，常駐指示、規則檔、工具定義都得先寫進去一次，後面的輪次才有便宜的讀取可以用。照這個機制，每開一次 session 就要付一次入場費。不過這三成五裡，有多少是開場那幾輪付的、有多少是中途過期重寫，我還沒量過，這裡不做推算。

如果入場費占的比例夠大，開 session 的方式本身就值得設計：規則檔該多長、什麼時候該接續舊 session 而不是新開。那是下一篇的事。

明日預告：Day 16｜冷啟動：新開一個 session 要先付什麼