Claude Code Token 砍 43% 實測:能省的前提是先量得到

這篇是我把「Claude 怎麼用才划算」整套想法收成的一篇長文:從實測數據(省了多少、省在哪)、到分流大局(訂閱 / API / Foundry / 本地怎麼選)、到底層功夫(context 乘數、cache_read、compact/clear、API 算錢與快取),最後拆解我用一整套 Claude Code hook 把這些紀律自動化的設計。所有定價與快取數字都以官方資料核對過。

先講最反直覺的起點:我知道「長對話又貴又笨」這個原理超過一個月,但用量一直降不下來。真正讓它砍半的,不是又讀一篇原理,而是一支只負責「記帳」的 hook——它什麼都不強迫,只是讓我每天看得到自己的 context 有多肥。能管理的前提是能量測,這句老話在 token 上完全成立。我們就從那個被量出來的數字開始。

實測:三天習慣改變,省了多少?

資料來源是 Claude Code transcript 裡每則 assistant 回應的 message.usage——這是真實計費欄位,不是估算。我把「改習慣前 7 天(6/18–6/24)」對比「改習慣後 3 天(6/25–6/27)」,並正規化到「每則回應」,排除「那幾天剛好做比較多事」的干擾,單純看習慣的效果。

每則回應平均	改習慣前 (6/18–24)	改習慣後 (6/25–27)	變化
context 大小	327K tokens	147K tokens	↓ 55%
cache_read(長對話最大成本源)	313K tokens	140K tokens	↓ 55%
換算 API 成本(Opus 4.8 估價)	$0.81 / 則	$0.46 / 則	↓ 43%
fat%(context > 300K 的回應佔比)	43%	10%	↓ 3/4
max_cr(單一對話衝到的最大 context)	999K(貼著 1M 上限)	522K	不再撞頂

換成美金是多少?訂閱戶省的是另一種東西

每則省 $0.34 美金(API 等值)。以我最近的實際節奏(約 1,150 則回應/天)推算:每天約 $390、一個月約 $11,000 美金等值。但這裡要誠實:我是訂閱戶,不是按 token 付費,不會真的有一張「省了 $11,000」的帳單。這個數字的正確讀法是:

你走哪個通道	省 token 實際省到什麼
訂閱 (Max / Team)	省的是額度與速率上限——同樣月費能多撐近一倍工作量,更不容易撞 rate limit 被迫停手
API / Foundry	省的是真金白銀——那 43% 直接從帳單上消失
兩者皆是	省的是智商——context 短一半,模型不掉進 context rot,判斷更準

為什麼長對話又貴又笨:context 是乘數,cache_read 是帳單

上面那欄 cache_read 是理解整件事的鑰匙。Context(對話視窗)不是只算一次,而是每一輪都重算一次。我在對話早期讀進一個 2,000 行的檔,那 2,000 行接下來每一輪都重新帶著計費——這個「重讀歷史」的量,在帳單上的名字就叫 cache_read。所以「在對話早期讀一個大檔」會污染後面整段對話的成本。我改習慣前,平均每則回應拖著 313K tokens 的歷史在重讀;最肥時單一對話衝到 999K(貼著 100 萬 token 上限),等於每講一句話都要重付近百萬 token 的「閱讀費」。

更關鍵的是:長 context 不只貴,還會讓模型變笨。Chroma 對 18 個前沿模型(含 Claude Opus 4、GPT-4.1、Gemini 2.5)的實測顯示,每一個都隨輸入變長而退化——即使「需要的資訊 100% 在 context 裡」,準確率仍隨長度掉 13.9% 到 85%。這叫 context rot。所以省 token 同時是讓模型保持聰明。另外兩個失效模式:lost in the middle(關鍵埋中段準確率掉 30%+,重要指令放開頭、當前問題放最後)、context poisoning(混進一個幻覺會被當前提複製,該截斷到污染點之前重啟)。

三個動作:繼續、compact、clear 怎麼選

動作	對之前對話做了什麼	能否接著聊同一件事
繼續聊	全部逐字帶著	能,但越疊越大、越慢、越貴、越笨
/compact 壓縮	換成一份摘要(有損,細節掉、重點留)	能,thread 不斷
/clear 清除	全部丟掉(只剩 CLAUDE.md、auto memory 重載)	不能,這次記憶歸零

原則:同一件事還要繼續且馬上繼續,用 compact;要停一陣、換事、或 context 已經很肥,先寫筆記再 clear。我那 43% 的省下,核心就是把「繼續聊到 999K」這個壞習慣,換成勤 clear。

5 層記憶模型:Note 與 Brain 是兩條垂直的軸

clear 之所以敢用,是因為「該留的」不靠 context 留,而靠下面這套外接記憶。把記憶拆成五層,各管各的存活週期:

層	存什麼	活多久 / 何時載入
Context	這次對話的一切	clear 就沒;每輪都在、每輪算錢
Note 接手筆記	做到哪、下一步	任務做完即丟;叫它讀才讀
MEMORY.md	你是誰、偏好、專案狀態	跨所有對話;每次開對話自動載
Brain 腦子檔	踩過的坑 + 領域知識	永久跨專案;宣告 Domain Brain 才載
Skill	正確做法的模板	永久;用到才呼叫

最容易混淆的是 Note 跟 Brain,它們是兩條互相垂直的軸:Note 答「這次做到哪」(短期、綁任務、會過期);Brain 答「這類事怎麼做才不踩坑」(永久、跨專案)。clear 時 Note 把工作進度帶過去、Brain 把教訓帶過去——不是二選一,兩個都寫但寫不同東西,一個搬狀態、一個搬智慧。這也是後面那套 hook 存在的全部理由:確保「經驗 → Brain」這條路徑不會因為健忘而斷掉。

Context × Loop:乘數效應在迴圈裡會放大

用 /loop 或排程反覆跑時,單輪成本是「context 大小 × 1」,但帶著肥大 context 的迴圈是「context 大小 × 迭代次數」。所以每一輪開始前把 context 收乾淨,比一路累積更省也更準:每次迭代讀回精簡狀態檔(Note)→ 做這一輪 → 寫回狀態檔 → 收掉工作 context。狀態活在檔案裡,活躍 context 保持小而新鮮,這就是 long-running agent 能跑幾十輪不退化的關鍵。同理,像 ccbot 那種「review → triage → 逐條修」一次幾十條 finding 的流程,該被當成一個「UI 工具」逐條決策,而不是用來長壓 context 的容器——一個 finding 就是一個任務邊界,分批做、批次之間 clear。

分流:哪種工作走哪個通道(比省 token 更上層)

講完「進了通道怎麼省」,要往上拉一層:很多人把「用 AI 怎麼划算」想成「省 token」,其實真正的重點在更上層——哪種工作該走哪個通道。把通道分對、把資料分流對,比你在單一通道裡省那幾個 token 重要太多。

第一件要釐清的事:「訂閱 vs API」不是「機密與否」的軸。訂閱和 API 都是把資料送到 Anthropic 雲端,差別是計費方式與資料條款,不是「資料會不會外洩」。真正的機密分流靠第三、第四個選項。先把三條軸分開:

• 機密軸:本地 ↔ 雲端。決定資料能不能離開公司。
• 信任邊界軸:Anthropic 自己的雲 ↔ 你既有的雲(Azure/AWS/GCP)。Foundry 讓資料留在公司已核准的 Azure 邊界。
• 計費 + 模式軸:訂閱(互動、固定費)↔ API(程式化、按量、商用條款)。

資料類型	走哪	為什麼
公開 / 不重要	訂閱	便宜;公開資料不怕被拿去訓練
內部但不機密(已在 Azure)	Azure Foundry(或商用 API)	留 Azure 邊界、預設不訓練、可開 ZDR
機敏 / 涉密 / 不確定	本地 / 地端 LLM	絕不上雲;default-deny,不確定就當機敏

為什麼公司資料走 Foundry 是最佳解?因為信任邊界早就跨過了。如果你的 code 已經在 Azure DevOps、公司也接受 Azure Foundry,那走 Foundry 的 Claude 是留在同一個 Azure 邊界裡推論,不是再送到 Anthropic 自己的雲——邊際的資料暴露趨近於零,還複用你早就過關的 Azure 合約。(注意:Foundry 是功能子集,不支援 Anthropic 的 Managed Agents 與 server 端工具,純 code 生成 / 對話 / 一般 tool use 沒問題。)

切換規則:只要問 2 個問題

預設是訂閱(互動 + 公開),只有「踩到公司資料」或「要自動化」才翻到 Foundry / API。重點:這是按任務類型路由,不是每句話狂切——你開一個工作時就決定走哪條,不會中途換。

公司用的「訂閱」是商用方案,不是員工個人帳號

處理公司的東西,要用「公司開的商用訂閱」(Team / Enterprise),不是員工個人的消費級 Pro / Max。這跟資料機不機密是兩道分開的閘——就算沒機敏問題,帳戶條款與治理仍是另一關。

帳戶	處理公司(非機敏)事	為什麼
員工個人 Pro / Max(消費級)	⚠️ 不建議	消費級條款,資料預設可能被訓練;無 DPA;公司無管控/稽核;綁個人帳號,離職即失去
公司開的 Team / Enterprise	✅ 可以	商用條款、不訓練、有 DPA、admin 管控、帳號歸公司
公司 API / Azure Foundry	✅ 可以	商用條款、可自動化;Foundry 還能留 Azure 邊界

從零開發:原型用訂閱,串真資料才切 Foundry

把原理套到「從零開發一個東西」的生命週期,就是最實用的一招:原型階段沒有任何公司資料,用訂閱快速迭代;等要串接真實公司資料,才切到 Foundry。但切換點不是「原型做完了」這種階段標籤,而是一個具體的資料事件:第一次「真公司資料 / 真 schema / 真憑證 / 真專有邏輯」要進 prompt 的那一刻——在這之前,即使在寫串接用的 code,只要餵的是假資料 / mock / 通用結構,就還能留在訂閱。

真機敏值要產出時,用假資料混合法:① 在自己這端把機敏欄位換成假資料 / 佔位符;② 把「假資料版」丟給雲端 LLM 產出結構、內容、框架;③ 在自己這端把真值 find-replace 換回佔位符。關鍵是佔位符要一致、可一鍵全域取代(用穩定命名如 [公司名]、{{2025_範疇一排放量}})。程式碼也適用:含活憑證(API key、DB 密碼、內部 endpoint)的檔案一律先抽掉再送。

API / Foundry 端怎麼算成本(含程式範例)

走 API / Foundry 時 token 直接是帳單,值得認真算。先講怎麼量——不要用 tiktoken(那是 OpenAI 的 tokenizer,對 Claude 會低估 15–20%)。用官方 count_tokens:

from anthropic import Anthropic
client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": open("CLAUDE.md").read()}],
)
print(resp.input_tokens)

成本公式:(input ÷ 1,000,000 × input 單價) + (output ÷ 1,000,000 × output 單價)。加上 prompt caching(同一大前綴重複用):讀取只要基礎 input 價約 0.1 倍,寫入 1.25 倍(5 分鐘)或 2 倍(1 小時)。同樣 50K 前綴重複 10 次:不快取 $2.50,有快取 ≈ $0.54,省約 78%。

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": LARGE_STABLE_CONTEXT,        # 穩定的大前綴
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": user_question}],  # 變動內容放後面
)
print(response.usage.cache_read_input_tokens)  # 驗證命中;一直是 0 = 前綴被污染

快取是前綴完全比對,差一個字元就全 miss——常見元兇:datetime.now()、UUID、沒排序的 json.dumps()、或工具清單變動(工具一改整個快取全滅)。非即時的批量工作可走 Batches API,直接半價。

各模型定價與快取門檻(官方數字)

模型	Input $/1M	Output $/1M	適合的活
Fable 5	$10	$50	最難的長程推理 / agentic
Opus 4.8	$5	$25	架構決策、複雜推理、跨檔案邏輯
Sonnet 4.6	$3	$15	CRUD、API 對接、測試、文件
Haiku 4.5	$1	$5	檔案掃描、目錄盤點、簡單搜尋

「最低可快取前綴」門檻各模型不同,而且不按貴賤排——這點最反直覺:

模型	最低可快取前綴
Opus 4.8 / Haiku 4.5	4,096 tokens
Sonnet 4.6 / Fable 5	2,048 tokens

具體後果:同樣一段 3,000 token 的前綴,在 Sonnet 4.6 與 Fable 5 快取得起來,在 Opus 4.8 與 Haiku 4.5 卻會靜默不快取——你不會收到錯誤,只會發現帳單沒省到。用 Haiku 做大量小請求時,若前綴不到 4,096,拿不到任何 cache 折扣。門檻不按貴賤排,別憑感覺假設;不同模型 tokenizer 也不同,跨模型估成本一定要用該模型自己的 count_tokens 重算。

省過頭反而害事:三個要避免的過度優化

• 壓縮砍太狠:摘要寧可先求高 recall(多留)再慢慢收。一開始壓很乾,會砍掉日後才變關鍵的細節,逼出更多來回反而更貴。
• 為省而硬拆多輪:研究顯示同一 prompt 拆成多輪累積,品質掉 39%(context clash)。該一次講清的別硬切。
• 濫用子代理:多代理約用 15 倍 token。廣度研究、檔案掃描很划算;緊耦合、要共享上下文的事用子代理反而又貴又糊。判準:任務價值 > token 成本才划算。

我那一整套 Hook 在做什麼:逐一拆給你看

上面講的都是「該怎麼做」,但人(包括用 AI 的我)會偷懶、會忘。所以我把這些紀律用 Claude Code 的 hook 自動化。hook 機制很單純:特定事件發生時,Claude Code 把一包 JSON 從 stdin 餵給腳本;腳本可以回傳 additionalContext 改變 AI 下一步(會花 token,等於往對話塞字)、回傳 systemMessage 把訊息秀給我看(不進 AI,不花 token)、或什麼都不回只在背後做事(記 log、發通知)。我目前掛 8 支:

Hook(觸發時機)	做什麼	分類
token-log.py(Stop)	算本輪真實 token 增量,寫 log + systemMessage 秀給我看	可觀測性
fix-detect.sh(PostToolUse)	偵測 fix: commit,注入「去更新 brain,不准做下一件事」	知識紀律
precompact.sh(PreCompact)	壓縮前掃最近 5 commit,提醒「brain 寫了嗎」	知識紀律
stop-check.sh(Stop)	比對今天 fix: commit vs brain 修改時間,有修沒記就警告	知識紀律
session-start.sh(SessionStart)	touch 時間戳基準線,給 stop-check 比對	知識紀律(輔助)
walsin-driver-anchor.sh(SessionStart)	特定專案注入「身份錨定」,防 /compact 後角色崩潰	知識紀律
claude-notify(Stop / Notification)	發 Telegram 通知到手機(完成 / 需要我)	人機介面
ccbot(SessionStart)	Telegram 機器人整合,用手機遠端驅動 Claude Code	人機介面

三道知識紀律關卡(fix-detect / precompact / stop-check)不是各自獨立,而是沿著「一條教訓從產生到消失」的時間軸,各對應一個偷懶藉口:修完當下「等下再寫」被 fix-detect 擋下、壓縮前「忘了還沒寫」被 precompact 救回、session 結束「這次算了吧」被 stop-check 抓出。而 stop-check 怎麼知道有沒有動過 brain?用一個無資料庫的巧招:session-start 時 touch 一根時間戳,結束時 find -newer 數出比基準線新的 brain 檔有幾個——0 個就警告。這套機制的完整設計我在 《讓 AI 不再失憶:用 Claude Code Hooks 打造大腦反饋迴路》 有更深的拆解。

真正的因果鏈:能省的前提是「量得到」

注意上表唯一被標成「可觀測性」綠色的那支:token-log.py。它在每輪結束時從 transcript 算出真實 token 增量,寫 log 並用 systemMessage 把數字秀在我眼前。它不阻止、不命令,只是讓「我的對話有多肥」從不可見變可見。配上一支自查腳本(我包成 token-health skill),我每天能看到兩個關鍵指標:fat%(多少比例的回應拖著 > 300K 的肥 context)與 max_cr(單一對話衝到多大)。

真正改變行為的瞬間,是我看到那行 max_cr = 999K 的時候——原來我有好幾天都把對話養到貼著 100 萬 token 上限。看到數字才會痛,痛了才會改。改法就是前面講過的老招:同一件事用 /compact,換事或太肥就先寫筆記再 /clear。原理我老早就知道,但知道和做到之間,差的就是這支把數字攤在臉上的 hook。

那些紀律 Hook 花多少 token?0.36%,而且超值

會注入 context 的紀律 hook(fix-detect / precompact / driver-anchor)本身是花 token 的。花多少?我把每支注入的字串實際抓出來估 token,以改習慣後每輪平均 context(約 147K)為分母:

Hook	一次注入	占一輪比重	多久觸發
driver-anchor	~308 tok	0.21%	限特定專案,每次開 session
fix-detect	~135 tok	0.09%	只在 fix: commit 後
precompact	~84 tok	0.06%	/compact 前(下一步就被壓掉,近乎 0)
stop-check	0 tok	0%	systemMessage,只給人看
全部加總(上限)	~527 tok	0.36%	假設全部同時觸發的最壞情況

乘數效應不放大比重:注入是「固定重量」,driver-anchor 騎完整場 session,不管 10 輪還是 30 輪都占每輪 0.21%。跟省下來的放一起看才知道量級差多少:改習慣每輪省約 180,000 tokens,全部注入型 hook 每輪最多花約 527 tokens——比例 1 : 342。

但這筆 token 不是「成本」,是不對稱投資

講到這裡要修正一個容易被誤導的框架:把這些紀律 hook 當成「要控制的成本」是錯的。對記帳 hook 而言,「能用事後讀 log 解決的就別事中注入」是對的;但對腦子紀律 hook 而言,那個注入不是副作用,就是本體——你沒辦法用「事後讀 log」逼自己更新 brain,唯一有效的就是在當下、在 context 裡擋你一下。它們存在的必要,是強化我的腦子系統,而那套腦子系統會在關鍵時刻——查一個難纏的 bug、確認整個系統的完整度——讓我不重踩已知的坑。這點價值,遠遠蓋過那 0.36%。

用會回本的方式算這筆帳:這是一個極度不對稱的賭注。

	量級	說明
成本側(每月)	~30K tokens	腦子紀律 hook 全部注入加總,≈ 改習慣後 0.2 輪對話
報酬側(一次)	50K–200K+ tokens	重新 debug 一個 brain 早記過的雷:重讀檔案+探索+試錯,輕鬆燒掉這麼多

而且這件事我們有實測佐證:context 是在哪幾天衝到 999K 的?就是 debug 的時候。重 debug 本身就是 context 爆炸、模型變笨的重災區。所以一個月只要 brain 救你一次,就回本還倒賺;救第二次以後全是淨賺。這還沒算「系統完整度」「不在關鍵時刻漏掉已知陷阱」這種沒法用 token 標價的價值——那才是你真正在買的東西。那 0.36% 不是要忍受的稅,是近乎免費的保險費。

一句話心法