減少Token反而更貴？Claude Code 費用怎麼算？「這個」才是成本主角

如果你看 Claude Code 帳單的時候，第一反應是「這個月怎麼又這麼貴」，然後直覺想把 context 砍短、少輸入一點——我懂這個感覺，我自己也這樣做過。
問題是：這個直覺是錯的，而且錯得很貴。
一篇分析了 2,908 次 Claude Code（Anthropic 開發的 AI 寫程式工具）真實帳單的研究顯示，帳單的主體根本不是 token（AI 處理文字的最小單位）數量——是暫存機制在掌控大局。搞清楚這個結構，Claude Code 費用才有辦法真正被管理。

prompt cache怎收費

帳單的 80–87% 是 prompt cache（暫存機制）在收費，不是你輸入了幾個字。這個數字來自 arXiv 預印本研究 2607.12161，樣本是 2,908 次 Claude Code 工作階段（一次工作階段 = 從開始到結束的一段連續操作），目前尚未經過同儕審查，適用條件是 Claude Code 特定工作流程 + Anthropic API 計費結構。

prompt cache 的費率結構是關鍵：

• cache read（讀取暫存）：基本費的 0.1 倍——便宜十倍

• cache write（寫入暫存）：基本費的 1.25 至 2 倍——比基本費更貴

• 一般 token 輸入：基本費 1 倍

這代表你的 Claude Code 帳單高低，最關鍵的變數不是「你打了幾個字」，而是暫存命中率高不高。命中率高 → cache read 佔大頭 → 便宜；命中率低或暫存被破壞 → cache write 頻繁觸發 → 貴。
開發者 bmdpat 做過一個實測：同一個 170 輪的 Claude Opus（Anthropic 最高階的 AI 模型）工作階段，關掉暫存要花 168 美元，打開暫存只要 21 美元。差了 8 倍，跟你輸入多少字沒有關係。

省token為何變貴

這是最容易踩的坑，也是前面那篇研究最反直覺的發現。
把工具回傳給 AI 的結果（tool-output token）壓縮掉 38%，帳單的成本反而上升了 6.8%。來源：arXiv 2607.12161，同樣適用條件限定在 Claude Code 工作流程。
原因是：暴力壓縮破壞了 cache prefix（暫存的前置索引），讓系統無法辨識「這段 context 跟上次一樣」，因此觸發更多高價的 cache write，把省下來的 token 費用加倍補回去。
換句話說，你砍掉的那些「多餘」資料，可能正是讓暫存系統能識別「這段對話跟上次一樣、可以直接取用」的關鍵 pattern。砍掉的不是冗餘，而是 AI 完成工作的隱性基礎設施。
這個道理我自己在跑 AI 自動化流程的時候也碰過類似結構：量的減少看起來很精實，但量會騙人——行數會膨風，token 數也一樣。你以為砍掉了廢話，其實砍掉了 AI 修東西需要的上下文。

語意摘要（semantic summarization）的做法是：先用 AI 把工具的冗長輸出濃縮成重點摘要，再用那份摘要繼續後續任務。這樣既壓縮了實際傳遞的字數，又不破壞 cache prefix 的結構，才是有效的 Claude Code 成本控制。

不只看token用量

我跑 AI 自動化流程超過一年，早期也是看 token 用量在管理成本。後來才意識到，回報才是該被管理的，不是計數器上的數字。
我目前看帳單的方式是先確認兩件事：第一，這個工作階段的 cache read 佔比是不是健康的（命中率偏低代表 context 結構可能需要調整）；第二，這些 token 最後換回了什麼——完成了什麼任務、省掉了多少手動時間。
只看 token 量，就像只看餐廳的食材重量來決定值不值得吃一樣。
有一次我讓 AI 自動化流程跑了一整套資料處理，token 用量不算多，但後來才發現 cache 命中率只有 30% 左右，代表大部分工作階段都在重複寫入暫存——等於花了兩倍錢做同樣的事。
那次之後我才開始把 cache read vs cache write 的比例當成每次看 Claude Code 帳單的第一個指標。

token壓縮怎麼做

有，但論文批評的是錯誤的壓縮手法，不是所有 token 壓縮都是壞事。
BCG（波士頓顧問公司）和 MindStudio 的研究都指出，在保護暫存穩定性的前提下，以下做法是有效的 AI coding 成本控制：
語意摘要：不要直接截斷工具輸出，而是先用 AI 把冗長結果濃縮成有意義的摘要再繼續。這個做法保留了 context 的語意完整性，同時降低後續步驟的 token 用量。
任務路由到廉價模型：並非所有子任務都需要最貴的模型。把查詢、格式化、簡單判斷等步驟路由到較廉價的模型，高階模型只負責需要深度推理的部分。
滾動式上下文（rolling context）：維護一份精簡但完整的「工作記憶」，不讓 context 無限膨脹，但也不暴力截斷。
這些方法的共同點：都在保護 cache prefix 穩定性的前提下操作，不是盲目砍量。

AI成本指標怎看

這個問題值得正視：就算我們接受「不看 token 量看產能」，新指標真的能算清楚嗎？
CIO.com 的數據顯示，只有 10% 的企業能量化 AI 的真實投資報酬率（ROI，投入後換回多少效益）。McKinsey 說 AI 輔助能讓例行任務省 46% 時間，但同時 AI 輔助的程式碼審查（PR，程式碼審查流程）多出 1.7 倍問題——如果品質沒納入計算，「每百萬 token 換回什麼產能」這個指標同樣可能被高估。
換度量衡是對的方向，但不要急著追新指標。先從最基本的問一個問題開始：這次用 AI 完成的事情，不用 AI 要多久？這個時間差，就是你目前能量化的最直接回報。
從這個差距建立第一個錨點，再慢慢往精細化演進。
Uber 四月就燒完了全年 AI 預算，但財務主管說不清楚 token 換回了什麼具體產品影響。這不是花太多的問題，是根本沒有建立衡量框架。先有框架，再談優化。

80%數字可信嗎

需要標明適用條件，但方向可信。
arXiv 2607.12161 目前仍是預印本，尚未完成同儕審查，不應被當作最終定論。2,908 次的樣本數在工作階段分析中算合理規模，但代表的是 Claude Code 特定工作流程和 Anthropic API 計費結構下的快照。
如果你用的是 OpenAI Codex（OpenAI 的程式碼 AI 工具）或 Google Gemini Code Assist（Google 的 AI 程式輔助工具），計費結構不同，暫存比例和成本影響可能有所差異。
但「暫存機制主導帳單」這個方向在多數大型 AI 服務的架構下都成立——只要該服務有 prompt caching，cache 費率差異就會在高頻使用情境下主導帳單結構。
精確的 80–87% 不該套用到其他 AI coding 工具，但「先看 cache 命中率」這個判準是跨工具適用的。

Claude帳單怎健檢

帶走一個可以馬上執行的框架：
第一步，看 cache read vs cache write 的比例。打開 Anthropic Console 的用量詳細報告，找 prompt cache read 跟 prompt cache write 的 token 用量比例。健康的工作階段 cache read 應該遠高於 cache write（bmdpat 的實測是 98% 輸入以 cache read 計費）。
第二步，確認你的壓縮手法。如果你有在壓縮 context，確認是語意摘要型（先濃縮再繼續），不是直接截斷 tool-output。後者很可能在破壞 cache prefix。
第三步，換一個問法看帳單。不要問「這個月燒了幾個 token」，問「這些 token 換回了什麼產能」。先從「不用 AI 要花多少時間」開始量，建立你自己的第一個回報錨點。
自我檢查問題：你現在看 AI 工具帳單的時候，是在看 token 量，還是在看 cache 命中率？你有沒有辦法說出「這個月的 AI 投入換回了什麼」？

常見問題

• Claude Code 費用怎麼計算？ 主要由三部分組成：cache read（基本費 0.1 倍）、cache write（基本費 1.25–2 倍）、一般 token 輸入（基本費 1 倍）。高頻使用情境下 cache 費用佔帳單 80–87%（此數字限定在 Claude Code 工作流程，來源：arXiv 預印本 2607.12161）。

• prompt cache 是什麼？怎麼讓帳單變便宜？ prompt cache（暫存機制）是把 AI 已經處理過的對話 context 暫存起來，下次遇到相同的前置 context 直接取用、不重新計算。命中率高時費用只有基本費的 1/10。確保你的工作階段有穩定的 context 前置結構，是提升命中率的關鍵。

• 壓縮 token 有沒有效？ 取決於壓縮手法。暴力截斷 tool-output 會破壞 cache prefix 穩定性，反而讓帳單上升（實測 -38% input → +6.8% cost）。語意摘要型壓縮（先濃縮成重點再繼續）在保護暫存的前提下有效。

• Claude Code 帳單太貴怎麼辦？ 先查 cache read vs cache write 的比例，確認命中率是否健康。再確認壓縮手法是語意層壓縮不是暴力截斷。然後把「換回什麼產能」納入你對帳單的判斷——如果產能回報高，貴的帳單可能仍然划算；如果說不清楚換回什麼，那才是真的問題。

• 這些數字適用於所有 AI 寫程式工具嗎？ 不。80–87% 是 Claude Code 特定工作流程 + Anthropic 計費結構下的數字，OpenAI Codex 或 Gemini Code Assist 的計費結構不同，比例可能有差。但「先看暫存命中率」的判準跨工具適用。