Claude Code 額度少了 17%:5 招實測拿回來

2026 年 9 月中旬夏季加碼結束,Claude Code 的每週額度少了 17%。最高方案的用戶現在回報,週三就用光整週額度。Anthropic 自己的公告說額度永久調高 25%,緊接著的下一則貼文卻把同一個變動稱為減少 17%。

每份省額度的小撇步清單,都沒有附上任何一個數字。這篇文章幫每一招配上實測數字,並依效果排名。有兩個結果特別突出:一個月的 token 有將近一半被 subagent 用掉,而且只要中斷一次較長的休息,下一則訊息就得重寫大半個 session。

這裡的測量來自一位開發者一個月的 Claude Code 紀錄:9 月 3 日到 10 月 3 日,共 455 個 session、63,398 次請求。

加碼活動從 5 月進行到 9 月 13 日,讓每週額度高出 50%。每個五小時視窗的額度則從未改變。8 月底,Anthropic 的開發者帳號宣布永久調高 25%,而同一串貼文往下一則,又說實際算起來是減少 17%。兩種說法都是對的:

期間	每週額度(舊額度 = 100)
加碼之前	100
加碼期間(5 月到 9 月 13 日)	150
9 月 14 日起的永久額度	125

從 150 掉到 125,就是大家感受到的 17%。一位同時有兩個最高方案的用戶寫道,週三就用到 100%,以前從來沒發生過。另一位同方案的用戶,週二早上就已經 86%。額度下修並不是唯一原因:9 月初推出了一個更耗額度的模型,所以並非每個提早見底的一週都來自這次變動。

你自己這邊只看得到百分比。/usage 畫面會把近期用量拆成 skill、subagent、外掛,以及每個已連接的 MCP 伺服器,還會標出快取未命中。按一個鍵就能在最近一天和最近七天之間切換。看不到的是額度以 token 計有多大:Anthropic 只公布百分比和倍數,從不公布 token 數。因此下面所有測量都是以 token 為單位,來自單一工作負載,不代表你一週的佔比。

用紀錄算 token 有個陷阱。紀錄會把同一個回答寫好幾次,所以把每一行加起來會得到 186 億個 token。只算一次的話,是 93 億。直接加總會讓所有數字幾乎翻倍。

subagent 是你的 session 為了處理旁支工作而啟動的另一個 Claude,做完會回報。在測量的這個月裡,subagent 在 2,631 次執行中用掉所有 token 的 48.1%。

項目	subagent 的佔比
所有 token	48.1%
輸出 token	63.9%
依公開價目表對輸出和快取寫入的加權方式計算	55.3%

每個 subagent 還要先付一筆入場費。在它做任何事之前,第一個請求就已經帶著中位數 47,117 個 token:指示、工具清單和 skill 清單,全部重新送一遍。另一個人在不同的機器上測過,發現即使 agent 自己的 prompt 很短,每次啟動也要 16,000 到 21,000 個 token。就像那篇文章說的,agent 檔案在它自己的啟動成本裡只是個四捨五入的誤差。

模型是另一半。預設情況下,subagent 會繼承主對話的模型,所以把 session 切到最大的模型,每個幫手也跟著用最大的。在測量的紀錄裡,最小的模型處理的 subagent 請求不到 1%。解法是在 agent 檔案裡加一行:把 model 欄位設成較小的模型,用在跑測試或搜尋檔案這類工作上。

這帶來兩個習慣。小工作自己就能直接做的話,就別開 subagent;留下來的 subagent,就固定用小模型。

這個結果的限制:沒有人量過固定模型能省下一週的多少比例,而且需要更多回合的小模型,可能反而花更多。48% 來自大量扇出的工作。你自己的佔比,看 /usage 畫面就知道。

Claude Code 會把你的對話存在伺服器端的 prompt 快取裡,讀回來的成本只是重送的一小部分。主 session 的快取能活一小時,subagent 的只能活五分鐘。

文件寫得很明白:即使是訂閱方案,subagent 也只有五分鐘,除非你選擇更久。主對話以外的所有東西都一樣,包括背景工作和壓縮。測量的紀錄也吻合:subagent 的每一次快取寫入都落在五分鐘這一層,主 session 的每一次都落在一小時這一層。

Reddit 上有位開發者注意到這會造成什麼:他的一個 subagent 在一天之內把整個 context 重寫了八次。解法是在設定檔裡加一行 "subagentPromptCacheTtl": "1h"。

他的測量	之前	之後
快取寫入	1,220 萬個 token	300 萬個 token
有四個 subagent 的五小時視窗	從 2% 到 100%	從 0% 到 22%

這是一位用戶比較兩個不同的日子,不是對照實驗。在這裡測量的紀錄中,影響其實很小:41,790 次 subagent 後續請求裡,只有 95 次(約千分之二)是在等了超過五分鐘之後才發出,不過每一次都重寫了約 75,000 個 token。

所以要看你的 subagent 怎麼運作。如果它們要等很久的建置、等審查或等你,就打開。如果它們是短時間爆發式執行,就別動,因為能撐一小時的快取,寫入成本更高。

主 session 的快取能撐一小時。休息得更久,快取就沒了,下一則訊息什麼都讀不回來。文件說得很清楚:休息後送出的那則訊息會未命中快取,並重新處理你的完整 context。

訊息前的暫停時間	請求數	重寫的快取(中位數)
少於 5 分鐘	18,029	1,176 個 token
5 到 60 分鐘	414	1,327 個 token
超過 60 分鐘	79	130,332 個 token

當時一般的 session 帶著 175,523 個 token,所以大部分都被重寫了一遍。額度計量器對寫入和讀取的算法也不一樣。有位開發者在 Claude Code 前面架了一個記錄用的代理,盯著他的五小時視窗:依他算出的比率,寫入快取的一個 token,份量大約是讀取的四十倍。

Claude Code 自己也知道這一點。當你在長時間休息後恢復一個大型 session,它會提議改從摘要恢復。接受它。

更省的習慣在更早之前。任務做完時,趁快取還熱,就把 session 清除。清除不花任何成本,下一個任務也會從小處開始。壓縮也行,但壓縮一個巨大的 session,本身就是一個巨大的請求。

休息並不是唯一會丟掉快取的情況。在 session 中途切換模型也會清空快取,因為每個模型各有自己的快取。在最新的模型上,調整 effort 則不會。Claude Code 會在快取還熱的時候,要你確認是否切換模型,那個提示就是警告。

限制:79 次冷啟動回來是很小的樣本,其中有些還接在壓縮之後。摘要也會遺失細節,所以這一招要付出一些連貫性的代價。

effort 指的是模型在回答之前被允許思考多久。共有五個等級,從 low 到 max,思考的部分以輸出計費。預設在大多數模型上是 high,最新的兩個模型上是 medium。

文件說,每次請求的思考預算可以高達數萬個 token,而且最高等級容易想太多。在最新的模型上,思考完全無法關閉,所以 effort 等級是唯一的控制手段。

有位開發者把同樣 29 個真實任務,在五個等級上各跑了一遍:

Effort 等級	每個任務的平均成本	通過的任務數(共 29)
low	$2.50	23
medium	$3.15	28
high	$5.01	26
xhigh	$6.51	25
max	$8.84	27

品質並沒有跟著成本走。medium 通過的任務比它上面任何等級都多,以每一塊錢換到的通過數來看也是最多。用他的話說,曲線似乎在 medium 達到高峰。Claude Code 團隊也是這樣做:一位工程師用 low 或 medium 來建置,做審查,只在 high 上跑驗證。

陷阱在於這一招為什麼可能損失品質。在他挑出的難題上,low 五次通過零次,high 五次通過五次。一次 low 的嘗試花兩分鐘,一次 high 的花三十三分鐘。

所以讓 effort 配合步驟:建置用 medium,犯錯代價高的時候用 high(舊程式碼裡的 bug、遷移、收尾檢查),max 幾乎不用。session 紀錄會記下每個請求的 effort,所以你可以查證自己實際跑的是哪個等級。

這些成本是在較舊的模型上以美元計算,不是一週的佔比,也沒有人公布過後者。而且一次失敗又得重跑兩次的便宜嘗試,成本比一次就成功的更高。

有些招數出現在每份清單上,卻幾乎沒什麼效果。試試看是免費的,只是一週的額度並不是花在那裡。

這一組裡真正重要的是開始時載入的內容。有篇文章量到,從空資料夾發出的第一個請求是 29,061 個 token,在真實專案裡則將近 39,000。在這裡測量的紀錄中,第一個請求的中位數是 55,989 個 token,依專案不同,範圍從 15,764 到 105,020。/context 指令會顯示裡面有什麼(記憶檔、skill、工具清單),並列出它載入的每個記憶檔。把用不到的刪掉。收益有限,因為那一塊只寫入一次,之後每一回合都從快取讀取。它的傷害出現在冷啟動和每次啟動 subagent 的時候。

熱門招數	實測結果
移除 MCP 伺服器	三個伺服器共 51 個工具是 1,350 個 token;一個伺服器、一個工具是 18 個 token
關閉提示建議	一位用戶是 3 到 4%;「最多 10%」的說法來自一個 context 極大的帳號
過濾 shell 輸出	約佔總量的 0.1%,由其中一個過濾工具的貢獻者量得

現在工具定義預設是延後載入的,所以 MCP 伺服器的份量才這麼輕。文件把提示建議的成本形容為很小。這三者都會隨你的 context 變大而增加,而在沒有延後載入的舊模型上,伺服器的成本也更高。想關就關,但別指望拿回一週的額度。

依實測結果排名:

排名	做法	實測結果	代價
1	更少、更便宜的 subagent	佔 48.1% 的 token;每次啟動 47,117 個	平行度變低
2	別恢復冷掉的 session	重寫 130,332 個 token,對比 1,176 個	摘要會遺失細節
3	Effort:建置用 medium	每個任務 $3.15 對比 $5.01;29 個通過 28 個	low 在難題上會失敗
4	subagent 快取設為一小時	快取寫入從 1,220 萬降到 300 萬個 token	只有 subagent 要等的時候才划算
5	精簡開始時載入的內容	在 29,061 的基準上多出 9,744 個 token	每個 session 只付一次

那三個熱門招數(MCP 伺服器、提示建議、shell 輸出)並不是一週額度花掉的地方。

直白地說限制:這份排名以 token 為單位,來自一個人一個月的工作,再加上其他人的測量。Anthropic 不公布額度以 token 計的大小,所以外人沒辦法把這些換算成你一週的佔比。你的順序可能不同,/usage 畫面會告訴你。

最大的兩招是習慣,不是設定,而且都免費:少開 subagent,以及絕不完整恢復一個冷掉的 session。