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

$200 的問題出在哪

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

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

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

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

Claude Code 的 /effort 指令控制模型在回應前的推理深度。四個等級可選：low、medium、high（預設）和 max（僅限 Opus 4.6）。越低的 effort 代表越少的思考 token，也就是每次互動消耗越少的使用額度。

運作方式

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

任務路由表

前後對比

一天的混合使用在預設 high effort 下，rate limit 消耗速度大約是實際需求的 2 倍。把簡單查詢設成 /effort low、中等任務設成 /effort medium，總 token 消耗預估可降 30-40%。

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

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

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

每次浪費的來回都在燒 token。Claude Code 搞錯你的專案結構、用了錯誤的測試框架、或是寫出你會拒絕的程式碼風格，這代表你要付兩次錢：一次是錯誤答案，一次是修正指令。

寫好 CLAUDE.md 就是在一開始就給 Claude Code 足夠的上下文，預防最常見的誤解。這不是文件，而是一份精簡的指令集。

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 的回應再加上新的修正 prompt。

有了好的 CLAUDE.md：Claude 第一次就拿到正確慣例，首次嘗試的正確率大幅提升，需要讀取的檔案數也變少。

前後對比

之前： 每個任務平均 2.3 次迭代。Claude 經常用錯 pattern，需要修正 prompt。 之後： 每個任務平均 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 的上下文窗口。不用信用卡、沒有試用期。

那 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 除錯
• 需要深度理解程式庫的架構決策
• 複雜的 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 預算（同方案、更多餘裕）。

方法四：策略性使用子代理（不是什麼都丟給子代理）

Claude Code 的子代理系統可以產生子程序來平行工作。子代理在探索型任務上很強，搜尋大型程式庫、同時調查多個潛在根因、或是研究 API 文件。但它們不是免費的。

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

什麼時候子代理反而省錢

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

好的子代理使用場景：

• 搜尋大型程式庫中所有使用已棄用 API 的地方（子代理探索，主代理根據結果行動）
• 同時調查 3 個潛在的 bug 根因
• 做架構決策前從多個文件來源蒐集上下文
• 在另一個 context 跑測試，同時你繼續開發

不適合的子代理使用場景：

• 讀取單一檔案（直接讀就好，啟動子代理的成本更高）
• 簡單的搜尋取代操作
• 需要查看的檔案不超過 3 個
• 你已經知道要做什麼、只需要執行的任務

3 檔案法則

如果一個任務涉及的探索少於 3 個檔案，在主 session 直接做。如果涉及 3 個以上檔案的探索，再考慮用子代理。這個簡單門檻能防止最常見的濫用模式。

前後對比

之前： 幾乎每個任務都開子代理，因為「平行比較快」。Token 消耗比實際需求多 3-5 倍。 之後： 只在真正的探索型任務才開子代理。Token 消耗在子代理密集的工作流中下降 40-60%。

預估省下：總 token 用量的 20-30%（針對有使用子代理的開發者，沒用子代理的不受影響）。

方法五：上下文管理：/compact 和 /clear

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

兩個指令負責管理這件事：/compact 和 /clear。

/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 條訊息的除錯死路在壓縮後價值為零，告訴 Claude 把它們丟掉。

/clear：從零開始

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

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

工作流

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 減少了那些任務中的浪費來回、上下文管理讓你的 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 等級、清楚的專案上下文、簡單任務用互補工具、有紀律的子代理使用、主動管理上下文。

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