⚠️ 2026-08-04 更正：同一個窗口用
tokenledger.py獨立重算過，本文有兩格要修（詳見RECORD-28DAY.md末節）。 1. 總金額報少了約四分之一：「合計 $4,451」應為 $5,567。成因是 Fable 5 被按 Opus 5 的牌價計了（Fable $10/$50 vs Opus 5 $5/$25，那週 Fable 有 6,281 次呼叫）。實測憑據：把 Fable 改按 Opus 5 計價重跑同窗口得 $4,705，與本文的 $4,451 只差 5.4%——$1,116 的差額裡 $862（77%）出在 Fable 牌價，其餘才是掃描範圍。 2. 「Haiku 佔 27% 呼叫」的分母偏窄：把全部設定樹算進來（並排除<synthetic>合成紀錄）是 21.1%，往後講「兩成」比較安全。「Haiku 只佔 9% 的錢」這格經得起複驗——真實牌價下重算是 8.1%，而在本文自己那組（Fable 按 Opus 計）牌價下重算正好是 9.6%，所以本文的 9% 在它自己的計價模型內自洽，不是算錯。本文的三條方向性結論——快取已到天花板、混編模型是最有效的省錢手段、消耗集中在主線那一條——都不受影響，只有絕對金額要往上修。
為什麼要量
起因是一個很土的問題：我們的消耗看起來很大，那是機制在漏，還是真的做了很多事？
一開始我是憑印象回答的，而且連錯三次：說「一輪要幾百萬 token」（錯，看門狗量的是單次呼叫的當下脈絡，不是累計）、說「七天三千多次呼叫」（錯，少講了二十倍）、說「快取讀佔七成」（錯，是 98.45%）。三次都是被反問才發現。所以這份文件的第一個結論其實是：成本類的數字，先量再講。
量法，以及兩個會讓數字錯掉快一倍的坑
資料來源是 Claude Code 自己寫的對話紀錄檔（每個 session 一份
JSONL），裡面每一次 API 呼叫都有 usage
欄位。「一次呼叫的脈絡」＝ input_tokens ＋
cache_read_input_tokens ＋
cache_creation_input_tokens 三個相加。
坑一：同一次呼叫會被記在多個檔案裡。 session
被重啟後接手時，會把歷史重寫進新的紀錄檔。直接把每一筆都算進去，七天會算出
60,969 次呼叫、96.06 億 token；用每則訊息的 message.id
去重之後，實際是 33,336 次、54.36 億。差 1.8 倍。
這不是資料錯，是量法錯。
坑二：多條 agent 共用同一個設定目錄。 我們有六條 LINE 線＋幾個輔助行程共用一個 config dir，如果按 config 目錄分組，會得到「某一條佔 97.6%」這種毫無資訊量的結果。要按每個 session 的工作目錄分，才分得出誰是誰。
七天的原始數字（主線那一條）
| 項目 | 數值 |
|---|---|
| API 呼叫次數 | 18,909 次 |
| 處理過的脈絡總量 | 39.40 億 token |
| 每次呼叫的平均脈絡 | 209,000 token |
| 單次最大 | 527,742 token |
| 看門狗門檻 | 300,000（達到就強制收尾重啟） |
拆成三種 token：
| 種類 | 量 | 佔比 |
|---|---|---|
全新讀取（input） |
0.001 億 | 0.00% |
寫快取（cache_creation） |
0.612 億 | 1.55% |
讀快取（cache_read） |
38.82 億 | 98.45% |
輸出（output） |
0.128 億 | — |
全新讀取幾乎是零，98.45% 都是快取命中。 這是整份報告最重要的一個數字：它代表沒有任何「忘記開快取」之類的折扣可以撿，這個形狀已經貼在天花板上。
token 數量不等於花費
Anthropic 的 prompt caching 定價（相對於基準 input 價）：
- 讀快取：0.1 倍
- 寫快取：1.25 倍（5 分鐘 TTL）／2 倍（1 小時 TTL）
- 輸出：5 倍（Opus 的 input : output 是 1 : 5）
把上面的量按倍率換算（我們用 1 小時 TTL）：
| 花在哪 | 加權後佔比 |
|---|---|
| 重讀舊脈絡 | 67.5% |
| 寫新快取 | 21.3% |
| 輸出（agent 講的話、寫的 commit 訊息） | 11.1% |
如果換成 5 分鐘 TTL，是 73.4% / 14.5% / 12.1%。
有兩件事值得停一下：
- 寫快取只佔原始 token 的 1.55%，卻佔花費的 21.3%。 倍率差二十倍，直覺完全對不上。
- 輸出佔 11%。 agent 自己講話也是要錢的，而這一項是最容易砍的——不用改架構，少廢話就好。
再把寫快取拆開看它到底在寫什麼：
| 單次寫入量 | 次數 | 佔寫快取 |
|---|---|---|
| ≥ 50k（開場／整段重建） | 295 次 | 49.2% |
| 10k–50k（中段重建） | 236 次 | 13.6% |
| < 10k（每一輪的增量） | 18,379 次 | 37.2% |
所以「寫快取」不是只有重啟才發生——每一輪對話往後長，就要為新增的那一段付一次寫入，那部分佔了三分之一。
換成錢是多少：Opus 5 與 Fable 5 的實際差距
上面都是比例，這一節換成美金。先講清楚前提：這是拿 API 牌價去換算「同樣這些 token 如果按 API 計價會是多少」，不是我們真正付的帳單——這條線跑在訂閱制上，訂閱的計價方式跟這個算法無關。這個數字的用途是「比較模型之間差多少」，不是拿去對帳。
重新量了一次（比上面那批晚一小時，所以總量差不到 1%），六條線七天各類 token 是這樣：
| 線 | 呼叫次數 | 寫快取 | 讀快取 | 輸出 |
|---|---|---|---|---|
| 主線（DM） | 19,179 | 6,126 萬 | 38.57 億 | 1,273 萬 |
| 第二條 | 3,614 | 1,485 萬 | 5.84 億 | 159 萬 |
| 第三條 | 3,738 | 1,391 萬 | 3.51 億 | 149 萬 |
| 其餘三條 | 1,385 | 780 萬 | 1.59 億 | 97 萬 |
| 合計 | 27,916 | 9,782 萬 | 49.52 億 | 1,678 萬 |
按 1 小時 TTL（寫快取 2 倍價）換算：
| 模型 | 每 M token 進／出 | 主線七天 | 六線七天 | 六線推估一個月 |
|---|---|---|---|---|
| Claude Fable 5 | $10 / $50 | $5,719 | $7,748 | $33,205 |
| Claude Opus 5 | $5 / $25 | $2,860 | $3,874 | $16,603 |
| Claude Sonnet 5（標準價） | $3 / $15 | $1,716 | $2,324 | $9,962 |
| Claude Sonnet 5（優惠價） | $2 / $10 | $1,144 | $1,550 | $6,641 |
| Claude Haiku 4.5 | $1 / $5 | $572 | $775 | $3,321 |
改成 5 分鐘 TTL（寫快取 1.25 倍價），每一格大約便宜 8%——Opus 5 六線合計是 $3,507，Fable 5 是 $7,014。
一個算完才看得出來的規律
這五個模型的成本比例，跟它們的 input 牌價完全成正比。 Fable 5 剛好是 Opus 5 的兩倍，Sonnet 5 是六成，Haiku 是兩成——每一格都精準對得上，沒有任何非線性。
原因有兩個，缺一不可：一是這五個模型的 input : output 全都是 1 : 5，二是快取讀寫的價格本來就定義成 input 牌價的倍數（讀 0.1 倍、寫 1.25 或 2 倍）。所以整條帳裡沒有任何一項是獨立計價的，全部都掛在同一個底數上。
這件事的實務意義是：換模型是純粹的乘法，不會因為工作型態不同而改變比例。 不需要為了估算而重跑一次量測——把上面任何一格乘以「新模型 input 牌價 ÷ 舊模型 input 牌價」就是答案。反過來說，這也代表換模型省不到「結構」上的錢，只是換一個係數；真正改變結構的還是前面那三條（少講話、脈絡短一點、重啟便宜一點）。
換算成單次成本
主線七天 $2,860、19,179 次呼叫，平均一次 API 呼叫是 $0.149（Opus 5，1 小時 TTL）。一天是 $409。
這個數字放在旁邊看比較有感覺：一次呼叫平均帶著 20.4 萬 token 的脈絡，其中 98.45% 走快取價，所以只花掉一毛五。如果同樣這批呼叫完全不走快取、每次都用全額 input 價重讀，七天要 $19,911——快取幫這條線擋掉了 85.6% 的錢，也就是說我們現在付的是「沒有快取的話」的七分之一。這也是為什麼前面說沒有折扣可以撿：折扣早就吃滿了。
那派出去的工兵呢？（實際的混合模型帳）
上面那張表全部都是假設題：「如果整隊都跑同一個模型會花多少」。真實情況不是這樣——主線跑 Opus 5，有幾條線跑 Sonnet 5，派出去的工兵幾乎都是 Haiku 4.5。所以那張表不是帳單，是模型之間的比較尺。
先回答量的問題：在 session 裡派出去的子代理，紀錄會寫進同一個工作目錄底下的對話檔，所以它本來就被算進去了。真正漏掉的是那些住在獨立設定目錄的常駐工兵池（實體偵測器、信件分類），七天多 6,737 次呼叫、2.67 億 token，這些沒被算進「六線」那個數字。
把每一次呼叫按它自己實際用的模型計價（1 小時 TTL），七天的真實換算是：
| 群 | 呼叫次數 | 脈絡量 | 按實際模型 | 若全記 Opus 5 |
|---|---|---|---|---|
| 六條線本體 | 24,595 | 47.09 億 | $3,306 | $3,589 |
| 獨立工兵池（全 Haiku） | 6,737 | 2.67 億 | $172 | $861 |
| 其他（終端機線等） | 5,637 | 5.92 億 | $973 | $1,327 |
| 合計 | 36,969 | 55.68 億 | $4,451 | $5,777 |
（Opus 4.8 沒有單獨牌價，這裡按 Opus 5 的 $5 / $25 計；量測窗口比前面那批晚幾小時，所以總量略高。）
裡面最值得看的一格是 Haiku：全部三群加起來 10,121 次呼叫、佔總呼叫次數的 27%，卻只佔 9% 的錢（$410）。工兵幹掉了四分之一的工作量，帳單上幾乎看不到它。
這跟前面「換模型是純乘法」並不衝突，但補上了一個重要的但書：乘法只在單一模型內部成立，真實艦隊是混的，所以真實帳不是任何一格乘出來的。而混編本身就是最有效的省錢手段——把機械性的活派給 Haiku，等於用 9% 的帳單買下 27% 的工作量（Haiku 的牌價是 Opus 5 的兩成，見前面那張表；實際帳單只佔 9%，比牌價比更低）。
誰在燒：分線分佈
同一批資料按工作目錄分開（七天，已去重）：
| 線 | 佔比 | 平均脈絡／次 |
|---|---|---|
| 主要對話線 | 72.5% | 209k |
| 第二條（捕捉線） | 11.1% | 187k |
| 第三條（訪客線） | 7.0% | 113k |
| 輔助偵測行程 | 2.8% | 33k |
| 其餘四條 | 合計 6.0% | 111k–148k |
結論很單純：消耗集中在「做長時間技術工作的那一條」，不是分散在所有 agent 上。 而它貴的原因不是單次呼叫貴，是「呼叫次數 × 當下脈絡」都大。
一個更尖銳的切法：脈絡超過 250k 的呼叫只佔 33%，卻吃掉全部重讀量的 48%。 上面那三分之一的呼叫，付掉將近一半的重讀錢。
那把看門狗的門檻調低會不會比較划算？
這是最實用的問題。看門狗的規則是：單次呼叫的脈絡達到門檻就強制收尾、寫交接卡、重啟。門檻低＝每次呼叫的脈絡比較小（省重讀），但重啟次數變多（多付整段重建，而且工作被打斷）。
模型與參數（全部從實測資料校準，不是猜的）
- 開場基線 B = 73k（session 剛起來時的脈絡中位數：系統提示、專案設定、交接卡）
- 每輪脈絡增量 g = 1.3k（18,298 筆增量的平均）
- 七天共 122 個 session、18,909 次呼叫（總工作量固定，只改門檻）
- 成本 = Σ(當下脈絡 × 0.1) ＋ 每輪增量寫入 × 2 ＋ 每次重啟重建 B × 2
有一個好用的近似：在這個模型裡，每次呼叫的平均脈絡 ≈ (B + 門檻) / 2，也就是門檻的一半左右。所以門檻對重讀成本幾乎是線性的。
掃描結果（假設重啟後定位要 10 輪）
| 門檻 | 加權成本 | 重啟次數 |
|---|---|---|
| 140k | 3.64 億 | 450 |
| 160k | 3.56 億 | 331 |
| 180k | 3.59 億 | 259 |
| 200k | 3.67 億 | 214 |
| 220k | 3.79 億 | 181 |
| 240k | 3.93 億 | 158 |
| 260k | 4.07 億 | 141 |
| 280k | 4.24 億 | 126 |
| 300k | 4.39 億 | 114 |
| 320k | 4.56 億 | 105 |
最低點在 160k 附近，而且曲線很平——160k 到 220k 之間差不到 5%。這是好消息：不需要為了精確值糾結。
但答案完全取決於一個變數：重啟後要花幾輪才回到工作狀態
「定位」指的是重啟後讀交接卡、掃任務板、確認在做什麼的那幾輪。它是重啟的真實成本，而且在高脈絡上重複發生。
| 定位輪數 | 200k vs 300k |
|---|---|
| 5 輪 | 200k 便宜 18.1% |
| 10 輪 | 便宜 16.3% |
| 20 輪 | 便宜 12.1% |
| 40 輪 | 打平（−1.3%） |
| 80 輪 | 200k 貴一倍多（−121%） |
80 輪那一格是這張表最有意思的地方：門檻壓太低、定位又貴，session 會在「還沒開始做事就撞到天花板」之間來回，變成純粹的空轉。
我們實測「開場五分鐘內的呼叫數」中位數是 46 輪——但那裡面混著真的在做事的輪，純定位大概十幾輪。所以誠實的答案是：真相落在「便宜 12%」到「打平」之間。
所以結論是
先不要動門檻，先讓重啟變便宜。 定位輪數是我們自己能控制的（更精簡的交接卡、更少的開場掃描）；把它壓到十輪上下，門檻切在 180k–200k 才真的穩定省得到 16%。反過來，在定位還很貴的時候把門檻壓低，是拿確定的打斷去換不確定的節省。
已經被證偽的三個直覺
- 「把重活搬到另一個 agent 去做就會省」——錯。搬過去等於重新建立一份一樣長的快取，而寫快取是讀快取的 12.5 到 20 倍價。
- 「派子代理很笨重，因為要餵它上下文」——錯，方向反了。子代理本來就是乾淨的新脈絡，它從來不繼承主線的對話。真正的節省來源是「那十幾次工具呼叫離開了主線的大脈絡」，主線只付派出與讀報告兩次。
- 「重啟一次要十幾萬 token 的固定開銷，所以要少重啟」——數量級錯了。實測開場基線是 73k，而且是快取價；真正的變數是「在多大的脈絡上做了幾次呼叫」，不是重啟次數。
誠實的不確定性
- 上面那套模擬算出「門檻 300k ＝ 4.39 億」，而實測是 5.75 億，模型低估約 24%（沒含輸出、也沒含實際超過門檻的長尾——看門狗是輪詢的，最大一次到 527k）。所以絕對值不要當帳用，只有兩個門檻之間的相對比較可信。
- 「定位輪數」目前只有代理量（開場五分鐘內的呼叫數），沒有乾淨的量法把定位和真工作分開。這是下一步該量的東西。
- 定價倍率來自官方文件；模型與 TTL 不同會有差異，套用到你自己的環境請先確認。
一句話總結
98.45% 的快取命中率意味著沒有漏掉的折扣可以撿——快取已經擋掉 85.6% 的錢。成本結構是：三分之二在重讀長脈絡、五分之一在寫快取、十分之一在 agent 自己講話。換模型只是換一個係數（Fable 5 剛好是 Opus 5 的兩倍，精準成正比），結構不會變。要省，只有三條路——少講話、讓脈絡短一點、讓重啟便宜一點。總量大不是因為機制在漏，是因為真的做了很多事。