Token燒太快？官方給出4條Claude Code建議，這樣做降低額度消耗|數位時代 BusinessNext

Anthropic 近日針對「Claude Code 用量暴衝」的爭議做出說明。許多用戶反映，自己明明只是做了幾個操作，卻在短時間內用掉大量配額，甚至在升級到更昂貴的方案後，實際可用的時間與token用量反而大幅下降，引發不少不滿。

負責 Claude Code 的 Lydia Hallie 在 X 上表示，團隊這段時間蒐集了大量回報與數據後發現，發現多數 token「燒得特別快」的情況，其實來自幾種非常消耗額度的使用模式。同時，她也提出4個官方建議，希望用戶可以降低不必要消耗。

一、優先使用 Sonnet 4.6，避免 Opus 過度消耗

首先，在 Pro 方案中，Anthropic 建議預設改用 Sonnet 4.6，而不是更高階的 Opus。原因在於，Opus 的代幣消耗大約是 Sonnet 的兩倍，如果不是每一次都需要最強、最深度的推理能力，其實沒有必要全程使用 Opus，否則會很快碰到用量上限。

二、調整運算強度與延伸思考功能

其次，Claude Code 提供「運算強度」（effort level）與「延伸思考」（extended thinking）等參數，這些功能會讓模型進行更多步驟的推理，自然也會大幅增加token的使用量。官方建議，如果只是處理一般的程式輔助或輕量任務，可以適度調低運算強度，甚至在不需要深度推理時關閉延伸思考，把成本壓下來。

三、避免長時間續用巨大對話工作階段

第三，Lydia 提醒，用戶不要長期「續命」一個放著不動的大型對話。如果某個工作階段（session）已經閒置約一小時以上，且累積了龐大的上下文內容，繼續在同一個工作階段裡操作，模型每次都要重新處理這段長上下文，自然會讓一次互動就吃掉大量token。她建議改成重新開啟一個新工作階段，比較節省資源。

四、透過上下文視窗上限控制對話長度

第四，Anthropic 也在 Claude Code 中提供「上下文視窗」（context window）上限設定，例如使用環境變數（environment variable）‎CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000 來自動壓縮過長的上下文。對常態開啟大型專案、讀取多檔案的開發者來說，這可以避免模型每次都帶著過量歷史內容一起運算。

Lydia 表示，團隊已經陸續推出多項效率優化，並在產品內加入提示視窗，幫助使用者避免觸發大型提示快取失誤（large prompt cache misses）等高成本情境。她也提醒，用戶務必確認自己使用的是最新版本。如果仍然遇到「明明只是個小操作，卻吃掉不成比例的大量額度」的狀況，可以在產品內執行 ‎/feedback 指令，讓團隊進一步調查。

Gemini 的額度其實也很容易被「用法」吃掉

前面幾點是 Anthropic 自己點名的 Claude Code 省 token 方式，但實際上，現在多數訂閱型 AI 服務的額度，都跟「怎麼使用」高度相關。以 Google AI 的 Gemini 為例，如果有訂閱相關方案，也要特別留意使用方式，才不會很快把每日額度燒光。

雖然官方文件沒有直接標註「哪些行為是浪費額度」，但從使用說明與各項功能限制中，其實可以整理出幾種特別容易消耗額度的使用模式，作為規劃使用策略的參考。

一、提問本身的長度與複雜度

提示詞越長、結構越複雜，模型在背後需要投入的運算資源就越高；如果在同一個對話串中，多次追加篇幅較長、層次繁複的追問，使用量會持續往上疊加。換句話說，能用精準語句表達清楚的問題，就應該盡量避免鋪陳過多背景與枝節內容，而在單一對話中無限制延伸討論，也會讓額度消耗速度明顯加快。

二、容易被忽略的來源

一口氣上傳數量眾多的檔案，會比事先精選少量關鍵檔案更快耗用額度；而且檔案容量越大，例如長時間影片、頁數龐大的 PDF 報告，模型為了讀懂內容所需的處理資源與上下文空間也會同步增加。較佳的做法，是先預先整理，只上傳「確實需要 Gemini 協助分析」的檔案，而不是把整個資料夾原封不動丟進去。

三、本身就屬於高成本的進階功能

Deep Research 會依方案不同設定每日或每月可產生的報告數量上限；圖像、影片、音樂生成等功能，也都有明確的每日張數或曲數限制，而且官方特別提醒這些需求量高的服務，限額未來可能因為成本壓力而調整；至於 Agent、螢幕自動化、簡報生成等功能，多半也設有每日可使用次數或同時執行數量上限。

若想實際降低額度浪費，可以從幾個面向著手調整。問題設計上，盡量聚焦核心需求，優先追求「精準與清楚」，而不是刻意拉長篇幅或追求華麗文采；在對話結構上，當討論主題已經大幅轉變，或是單一對話變得過長時，適度開啟新對話，有助於減少不必要的歷史上下文負擔；在檔案管理上，只上傳實際需要分析的檔案，避免一次性投入大量冗餘資料；至於生成內容，若是為了比較模型輸出品質而重生多個版本，事先替自己訂一個合理上限，避免無節制反覆生成，也能有效控制整體用量。