Claude Code 每月燒 $200 — 五種實測省一半的方法

$200 的問題出在哪

早上九點打開 Claude Code session。下午三點，rate limit 的進度條已經閃紅燈。你一整天都在叫 Opus 4.6 幫你重新命名變數、查函式簽名、回答「這個做什麼？」的問題。這就像請腦外科醫師來貼 OK 繃。

Claude Code Max 20x 每月 $200。這能買到每週約 240-480 小時的 Sonnet 4.6 和 24-40 小時的 Opus 4.6，對重度專業使用綽綽有餘。問題不在預算。問題在多數開發者拿 Opus 等級的推理 token 去處理根本不需要 Opus 的任務。

我追蹤了自己四週的使用紀錄。結果：大約 40% 的互動是簡單任務 — 查檔案、小修改、一行修正、「這個函式做什麼？」之類的問題。另外 25% 是中等複雜度 — 寫測試、code review、寫文件。真正需要深度多步驟推理的只有 35%：複雜重構、架構決策、跨多檔案的 debug session。

65% 的 token 預算花在了可以更便宜、更快、或兩者兼得的任務上。以下是我實測的五個方法，附真實的前後對比數字。

方法一：用 /effort 控制推理深度

把 /effort 想成 Claude Code 大腦的音量旋鈕。簡單任務轉小聲。問題真的很難時轉大聲。別什麼事都開最大音量。

四個等級：low、medium、high（預設）和 max（僅限 Opus 4.6）。越低的 effort 代表每次互動消耗越少的思考 token。

運作方式

在 session 中執行 /effort low，之後每次回應都用最低限度的推理 — Claude 跳過延伸思考、直接回應。需要處理困難任務時切回 /effort high。/effort auto 讓 Claude 根據查詢複雜度自行判斷。

任務路由表

前後對比

之前： 100% 的互動用 high effort。Pro 方案到下午就撞 rate limit。 之後： 40% 用 low、25% 用 medium、35% 用 high。同一個 Pro 方案能撐完整天。

預估省下：總 token 用量的 30-40%。

方法二：寫好 CLAUDE.md 消滅浪費的來回

每個錯誤答案讓你付兩次錢。一次是壞的輸出。一次是修正的 prompt。搞錯慣例、用錯測試框架、寫出你會拒絕的程式碼風格 — 每一個都是用 token 付費的來回。

寫好 CLAUDE.md 就是在一開始就防堵最常見的誤解。不是文件。是一份精簡的指令集，在誤解發生之前就擋住它。

CLAUDE.md 該放什麼

# Project: my-app

## Architecture
- Next.js 15 App Router, TypeScript strict mode
- Database: PostgreSQL via Drizzle ORM
- Styling: Tailwind CSS v4, no CSS modules

## Conventions
- Components: named exports, no default exports
- Tests: Vitest, co-located in __tests__ directories
- Error handling: Result pattern, never throw in business logic

## Active Context
- Currently refactoring auth flow from NextAuth to custom JWT
- Migration in progress: /src/lib/auth/ is the new path

## Do NOT
- Use default exports
- Add console.log (use project logger at src/lib/logger.ts)
- Create new API routes under /pages/api (deprecated)

為什麼這能省錢

沒有 CLAUDE.md 時，Claude Code 靠掃描你的程式碼來推斷慣例 — 第一次嘗試常常猜錯。每次修正都是完整的來回：你的 prompt、Claude 的回應、你的修正、Claude 修正後的回應。

有了好的 CLAUDE.md：慣例第一次就到位。首次正確率大幅提升。讀檔次數下降。

前後對比

之前： 每個任務平均 2.3 次迭代。Claude 經常用錯 pattern。 之後： 每個任務平均 1.4 次迭代。只有真正模糊的需求才需要修正。

預估省下：總 token 用量的 25-35%。 複利效應很重要 — 更少的浪費來回代表每個任務消耗更少 token，在 rate limit 內能完成更多任務。

CLAUDE.md 控制在 500 行以內。裡面每個 token 每次 session 都會被載入。臃腫的 context 檔完全適得其反。AI CLI 工具完全指南有更深入的 CLAUDE.md 最佳實踐。

方法三：把簡單任務分流到 Gemini CLI（免費）

單一改變中影響最大的。Gemini CLI 是免費的 — 每天 1,000 次模型請求、每分鐘 60 次，Gemini 2.5 Pro 搭配 100 萬 token context window。不用信用卡、沒有試用期。

那 40% 的簡單任務？Gemini CLI 處理得不錯。在複雜任務上不如 Claude Code — 但對直接了當的工作來說，品質差距可以忽略。成本差距卻是 $200 對 $0。

路由法則

在 Claude Code 打字之前，問自己一個問題：這個任務需要跨多個檔案的多步驟推理嗎？

• 需要 — 用 Claude Code。
• 不需要 — 用 Gemini CLI。

這個單一判斷標準能正確處理 90% 的路由決策。雙工具策略指南有完整的決策框架，但光靠這個一問法就能拿到 80% 的效益。

Gemini CLI 擅長的任務

• 解釋不熟悉的程式碼
• 替單一函式寫單元測試
• 產生樣板（元件、API route、設定檔）
• 小型變更的快速 code review
• 文件初稿
• 單一檔案內的簡單重構
• 回答「在框架 Y 怎麼做 X」的問題

仍然需要 Claude Code 的任務

• 有連鎖依賴的多檔案重構
• 橫跨多個模組的微妙 bug 除錯
• 需要深度理解 codebase 的架構決策
• 複雜的 git 操作和 merge conflict 解決
• 需要工具鏈串接（讀取、編輯、測試、修正）的任務

前後對比

之前： 所有任務都透過 Claude Code。Max 20x $200/月，重度使用日偶爾還是撞 rate limit。 之後： 40-50% 任務路由到 Gemini CLI。Claude Code 用量大幅下降，可以考慮降到 Max 5x $100/月，嚴格自律的話甚至 Pro $20/月。

預估省下：$100-180/月（降級方案）或40-50% 的 token 預算（同方案、更多餘裕）。

方法四：策略性使用 Subagent（不是什麼都丟）

Subagent 是 Claude Code 的平行處理系統。探索型任務很強 — 搜尋大型 codebase、同時調查多個根因、研究 API 文件。但它們不是免費的。

每個 subagent 都是獨立的 Claude 實例，有自己的 context window。一個主 agent 加上 3 個 subagent，token 消耗大約是單一 session 的 4 倍。為了瑣碎任務開 subagent，就像找四個包商來換一顆燈泡。

什麼時候 Subagent 反而省錢

替代方案更糟的時候才省錢：在單一 session 手動翻遍 20 個檔案（每次讀取都在累積 context），或因為跳過探索就反覆試錯。

好的使用場景：

• 搜尋大型 codebase 中所有使用已棄用 API 的地方
• 同時調查 3 個潛在的 bug 根因
• 做架構決策前從多個文件來源蒐集 context
• 在另一個 context 跑測試，同時你繼續開發

不適合的使用場景：

• 讀取單一檔案（直接讀就好）
• 簡單的搜尋取代
• 需要查看的檔案不超過 3 個
• 你已經知道要做什麼、只需要執行的任務

3 檔案法則

探索少於 3 個檔案？在主 session 直接做。3 個以上？考慮用 subagent。簡單門檻，防止最常見的濫用。

前後對比

之前： 幾乎每個任務都開 subagent。Token 消耗比實際需求多 3-5 倍。 之後： 只在真正的探索型任務才開 subagent。Token 消耗在 subagent 密集的 workflow 中下降 40-60%。

預估省下：總 token 用量的 20-30%（針對有使用 subagent 的開發者）。

方法五：Context 管理：/compact 和 /clear

Claude Code 的 context window 是一個持續運轉的成本計量器。每條訊息、每次檔案讀取、每個工具輸出都留在 context 中，隨後每次互動都要重新傳送。一個跑了 2 小時的 session 可以累積超過 10 萬 token，每次新互動都在為這些重量付費。

/compact：摘要後繼續

/compact 把對話摘要成精簡版本，保留關鍵決策，丟掉冗長的中間步驟。在 context 計量器到 60-70% 時使用。

加上自訂的保留指令：

/compact preserve the list of modified files and the test results

/compact keep only the architectural decisions, drop all debugging attempts

這很關鍵，因為 Claude Code 的預設壓縮會平等保留所有內容。消耗了 20 條訊息的 debug 死路在壓縮後價值為零 — 告訴 Claude 把它們丟掉。

/clear：從零開始

/clear 完全清除 context。在切換到不相關的任務時使用。塞滿 auth 重構 context 的窗口，對你接下來要做的支付整合來說完全是雜訊。

常見錯誤：跨不同任務使用同一個 session。到了第 3 小時，context 已經塞滿了前面任務的無關資訊，每次新互動都在為背負這些死重付出 token 成本。

Workflow

1. 在全新 session 或 /clear 後開始任務
2. 工作到 context 計量器到 60-70%
3. 用指定的保留指令執行 /compact
4. 繼續工作
5. 任務完成後，在開始下一個任務前執行 /clear

前後對比

之前： 單一連續 session 跑 3-4 小時。後期互動因 context 膨脹，成本是前期的 3-5 倍。 之後： 在 70% 時 compact、任務間 clear。整天的平均 context 大小維持在低 40-60% 的水位。

預估省下：總 token 用量的 20-35%。

綜合效果：五招疊加

這五個方法可以疊加。以下是全部套用的綜合影響：

節省效果是複利的。Gemini CLI 處理了 40% 的任務。/effort 降低了剩餘 60% 的 token 消耗。好的 CLAUDE.md 減少了那些任務中的浪費來回。Context 管理讓你的 session 保持精簡。綜合效果通常是 Claude Code 使用量減少 50-60%。

對 Max 20x $200/月的開發者來說，代表能降到 Max 5x $100/月。對 Max 5x $100/月的開發者來說，能降到 Pro $20/月。AI CLI 成本最佳化指南涵蓋了更多策略，包括免費額度堆疊和不同開發者類型的預算範本。

結論

Claude Code 是目前最強的 agentic 程式開發工具。$200/月不是問題，浪費才是。這五個方法不是妥協方案。它們是 Claude Code 設計上就該被使用的方式：對的任務用對的 effort 等級、清楚的專案 context、簡單任務用互補工具、有紀律的 subagent 使用、主動管理 context。

五招全上，追蹤兩週的使用量，然後決定你目前的訂閱等級是不是還適合。多數開發者會發現，至少能降一個等級而不損失任何生產力。