AI Coding 成本怎麼控：從 Token 用量到 Model Routing
這是「Agentic Engineering 實戰手冊」系列的第十一篇。上一篇：Multi-Agent 編排實戰
上個月帳單 $287，這個月 $148
上個月我的 AI coding 總帳單是 $287。嚇了一跳。
不是用太多，工作量其實差不多，問題出在使用方式：超長的 session 導致 context window 持續膨脹、探索性的 codebase 搜尋吃掉大量 token、該用便宜 model 的地方用了貴的。
花了一個週末分析之後，下一個帳期降到 $148。我的工作型態大致相近，但這不是控制實驗：任務難度、模型更新與快取命中都可能影響結果。能確定的是，我同時改了 context pruning、model routing 與 session management，帳單下降了 48%。
重點不是「少用」，是「聰明用」。如果你也有 token 燒光的焦慮，這篇從工程面給你具體的解法。
Token 成本解剖學
要省錢，先搞懂錢花在哪。
先看用量桶，不要假設三種價格
| Token 類型 | 什麼時候產生 | 你能控制嗎 |
|---|---|---|
| Input tokens | 你給 model 的一切：system prompt、CLAUDE.md、conversation history、code context | 是——context engineering 直接影響 |
| Output tokens | Model 回給你的一切：code、解釋、tool calls | 部分——精準的 spec 讓 agent 少寫廢話 |
| Thinking / reasoning | 部分模型推理時產生的 token或用量 | 視產品而定；有些會併入 output 計費，不是固定的第三種單價 |
真正隱藏的成本殺手是 input tokens。
在我的長 session 裡，input tokens 常高於 output，因為每一輪都要帶上可用的 history、instructions 與 code context。但比例會受工具的 compaction、cache、deferred tool loading 和任務型態影響，不能把 3–5 倍當通則。
一個 session 跑了 50 輪對話，最後幾輪每次都要送入幾十萬 token 的 history——光是這些重複的 input 就占了帳單的大頭。
一次「幫我修這個 bug」的用量怎麼看
下面是我某次 session 的粗略拆分，用來說明觀念，不是 Claude Code 的正式 billing 明細：
System prompt + CLAUDE.md: ~5,000 tokens
Conversation history (20 輪): ~40,000 tokens
Agent 讀的 code files: ~15,000 tokens
Agent 的 tool calls: ~8,000 tokens
Agent 的 output (code + 說明): ~3,000 tokens
Extended thinking: ~5,000 tokens
─────────────────────────────────────────────
Total: ~76,000 tokens這筆紀錄裡，最後產生的 code 只占很小一部分，history 才是主要來源。換一個 output-heavy 的文件任務，比例可能完全不同；所以第一步應該看自己的 usage report，不是套我的百分比。
別把任務類型換算成固定美元
模型價格、訂閱額度與 cache 折扣都會變，同一個「修 bug」也可能差兩個數量級。比較耐用的算法是：
單次 API 成本 ≈
未快取 input tokens × input 單價
+ cache write / read tokens × 對應單價
+ billed output tokens × output 單價實際欄位以供應商帳單為準；使用訂閱方案時，還要把 rate limit 與超額規則算進來。文章不寫死單價，請查 Claude API 官方 pricing 文件或你所用供應商的即時頁面。
Token 黑洞排行：
- Refactor——agent 需要讀很多檔案，理解整體架構，然後做大量修改
- Codebase exploration——「幫我搞懂這個系統怎麼運作」類型的任務，agent 會讀幾十個檔案
- Long debugging sessions——history 本身通常是逐步累積，不是指數成長；但若每輪都重送愈來愈長的前文，整個 session 的累計 input 可能接近二次成長
優化策略一：Context Pruning
回到 Context Engineering 的核心觀念：context 不是越多越好，剛好夠就行。
精簡 CLAUDE.md
每多一行 CLAUDE.md，就多花幾個 token 在每一輪對話裡。乘以 session 裡的對話輪數，成本累積驚人。
Before（示意）：400 行的 CLAUDE.md，假設每輪約 4,000 tokens；若完全未快取，30 輪的累計原始輸入約為 120,000 tokens
After：100 行的 CLAUDE.md，每輪 ~1000 tokens × 30 輪 = 30,000 tokens
原始輸入差 90K tokens，但實際帳單差額還要看 prompt caching、方案與模型價格，不能直接從這個示意推導每月省 $90。
Session 管理紀律
黃金法則就一句：一個 session 做一件事。
一個 session 跑太久，conversation history 會持續膨脹。若每輪都帶上前面內容，單輪 input 會變長，累計用量也會加速上升；工具的 compaction 與 caching 會改變實際成本。
改善做法：
- 一個 task 一個 session。task 做完就關，開新 session 做下一個。
- 如果 task 需要多輪 iteration，中途做 checkpoint（更新 plan/TODO），然後開新 session 繼續。
- 利用 Claude Code 的 context compaction，當 context 太大時它會自動壓縮舊的對話。但與其依賴自動壓縮，不如主動控制 session 長度。
Sub-Agent 模式
探索性的任務（「幫我搞懂這個模組的架構」）特別燒 token。解法是用 sub-agent：
主 agent: 「研究 auth 模組的架構」
→ 派出 sub-agent（cheap model、獨立 context）
→ sub-agent 讀 20 個檔案，消耗 200K tokens
→ 回報 2000 token 的摘要給主 agent主 agent 的 context 可能只增加一份摘要，但整體系統仍然付了 sub-agent 的探索成本，還多了摘要與協調開銷。這招主要是保護主 context、隔離雜訊，不保證總 token 更少；只有換用較便宜模型、避免重複探索時才可能省錢。
優化策略二：Model Routing
不是所有任務都需要最貴的模型。
我的 Model 選擇框架
| 任務類型 | 先選的能力層級 | 原因 |
|---|---|---|
| 簡單問答、分類 | 快速／低成本 | 先用最便宜、能穩定達標的模型 |
| 日常 coding、bug fix | 中階通用 | 用測試結果決定是否升級 |
| 複雜架構決策 | 高推理 | 同時保留人類評估與第二意見 |
| Code review | 中階起跑 | 高風險 diff 再升級 |
| Commit message | 快速／低成本 | 任務短、格式容易驗收 |
| 長篇寫作 | 依品質評測 | 長度不等於一定要最貴模型 |
| Codebase exploration | 中階或較便宜 sub-agent | 先限制範圍，避免重複讀檔 |
實際省下多少？
別先套一張看似精準的模型價目表。價格、快取折扣與可用模型都會變，任務的 token 分布也不一樣。比較可靠的做法，是從自己的帳單與 eval 開始：
- 把常見任務分成簡單、標準與高推理三組。
- 各組挑一批真實案例，記錄成功率、review 時間、返工與缺陷。
- 先用較便宜的可用模型跑，再把失敗或高風險案例升級。
- 用同一時期的官方單價與實際 billed tokens 計算差額。
這樣算出的才是你的節省，不是別人的模型組合在理想條件下推導出的數字。
怎麼切換
Claude Code 可以用 /model 切換當前可用模型；確切 alias 會隨產品更新。我的 commit skill 只要求「使用能穩定產生正確格式的最低成本層級」，不把某個家族名稱永久寫死。
優化策略三：Prompt Caching & Batching
Prompt Caching
Anthropic 的 prompt caching 會對符合條件的相同 prefix 重用快取，降低後續 input 成本。Claude Code 或 API 是否自動啟用、最小長度、TTL 與單價都可能變，應看當前 usage 欄位，不要只憑 session 看起來一樣就假設命中。
怎麼提高 cache hit rate：
- CLAUDE.md 保持穩定——頻繁修改 CLAUDE.md 會導致 cache miss
- 把穩定內容放前面、動態內容放後面（cache 是 prefix-based）
- 避免在穩定 prefix 中插入 timestamp、random ID 等每次變動的資料
Batching 策略
把相似的小任務合成一個 request：
Before（5 個獨立 request）：
1. "修正 Button component 的 hover color"
2. "修正 Card component 的 border radius"
3. "修正 Input component 的 focus style"
4. "修正 Modal component 的 backdrop color"
5. "修正 Toast component 的 animation"5 次 system prompt 載入 + 5 次 CLAUDE.md 載入 = 大量重複的 input tokens。
After（1 個 batch request）：
修正以下 5 個 component 的 CSS 問題：
1. Button: hover color
2. Card: border radius
3. Input: focus style
4. Modal: backdrop color
5. Toast: animation這樣可以減少重複探索與請求 overhead，但不保證省 60%。Batch 太大也會擴張 scope、增加 review 難度，甚至讓其中一個錯誤拖累全部；只有彼此相關、能一起驗收的小修改才適合合併。
預算不要從別人的級距抄
我以前把每月 $20–300 分成 Light、Medium、Heavy，後來覺得這種表沒有決策價值。同樣 $150，對個人 side project 可能太高，對能縮短事故時間的團隊工具可能很便宜。更實用的是先設定三個欄位：
| 欄位 | 怎麼定 |
|---|---|
| 成本上限 | 你願意為這類工作承擔的月費、API 與維運成本 |
| 成功指標 | lead time、review 時間、返工率、缺陷或事故時間 |
| 停損條件 | 連續幾週沒有改善，或品質／安全指標惡化就降級或停用 |
ROI 計算
不要拿一個沒有來源的「台灣工程師平均時薪」去替自己算 ROI。用你的實際成本：
月收益 ≈ 可重新利用的淨節省時數 × 你的機會成本
+ 減少缺陷／事故的預期價值
月總成本 = 訂閱 + API + review／返工 + 維運與安全成本只有「省下來的時間真的被重新利用」，才能全額算收益。第 7 篇的單一案例也不能當成每天固定省兩小時的證據。
我具體做了什麼把帳單從 $287 降到 $148
- Session 拆分：從平均 45 分鐘/session 降到 20 分鐘/session。對話輪數從 30 降到 12。
- Model routing：約 70% 任務改用較低成本層級（之前大多用最高階層級）。
- Sub-agent 探索：邊界清楚的 codebase exploration 改由 sub-agent 執行，保護主 context；它不一定降低總用量。
- CLAUDE.md 瘦身：從 400 行精簡到 100 行。任務特定的指令移到 rules files 和 skills。
- Batch 處理：小任務合併。一天 15 個 request 降到 8 個。
每一項單獨看都不是巨大的改變；同一個帳期間合計看到 48% 降幅。因為同時改了多個變數，我不能把比例精確歸因到某一招。
Takeaway
-
先看自己的 usage，再找最大的用量來源。我的長 session 主要花在 history，但別人的工作可能是 output 或工具結果。縮短 session 與精簡常駐 context 常有效；sub-agent 主要隔離 context，不保證省總 token。
-
Model routing 要用 eval 守住品質。從最低成本、能達標的模型開始；成功率、review 時間或缺陷惡化就升級。不能先承諾一定省 40–50% 且品質不變。
-
沒有適用所有人的月費甜蜜點。用成本上限、成功指標與停損條件管理，比抄別人的 $100–200 或 5–10x ROI 更可靠。
上一篇：Multi-Agent 編排實戰 下一篇：Agent 安全網設計
