Claude Code /usage 完整教學 — 看你的額度花在哪個 Skill、Subagent、Plugin、MCP server

打開 Claude Code 還沒輸入任何指令，光是 boot 起來這層 context window 就已經吃掉了——多少？

預設安裝一個 CLAUDE.md、五個 MCP server、幾個 skills，根據 Claude Code 官方文件的估算，起跳就要五萬個 token。其中光 GitHub MCP 一個就佔了一半以上。

這還是「什麼都還沒做」的數字。

5 月的 /usage 升級之後，這層消耗變得可見了——指令會把 skills、subagents、plugins、每個 MCP server 各自吃掉多少額度列成一張表。本來這層是黑盒子，現在打開了。

這篇拆解三件事：/usage 報表怎麼看、看到之後該怎麼動手減重、為什麼這個指令的設計值得抄到自己的工作流。

`/usage` 跟 `/cost` 跟 `/stats` 不是同一件事

先把容易混淆的三個指令分開：

指令	看什麼	適用對象
`/usage`	Pro / Max 訂閱的額度還剩多少、各 category 吃掉多少	訂閱戶
`/cost`	這個 session 跑下來花了多少美金	用 API key 的人
`/stats`	使用模式統計（指令次數、模型切換等）	都可以用

訂閱戶最常用的是 /usage——它不是看「錢花多少」，是看「這 5 小時 / 這禮拜的額度被吃掉幾成」。Claude Code 的計費是雙層滾動窗：

5 小時滾動窗：短期使用上限，每 5 小時重新計算
每週上限：覆蓋七天的總計 active compute time

兩條曲線都會在 /usage 看到，但更值錢的是底下那層 per-category breakdown —— skills、subagents、plugins、MCP 各別貢獻多少。

為什麼這層 breakdown 很重要

直覺上，token 用太多就少寫幾個 prompt 就好——但這個直覺只對了一半。

實際的問題是，很多 token 在你還沒輸入任何東西時就已經被吃掉了。

把每次 boot Claude Code 想成搬家。你進新房子之前，家具已經先擺好——CLAUDE.md 是你的書桌、每個 skill 是一個工具櫃、每個 MCP server 是一台冰箱。家具還沒用就佔了客廳的空間，等你開始活動，剩下的空間才是「能用的」。

問題是冰箱有大有小：

一個 skill 大約 100 token（lazy load，沒用到不算）
一個典型 MCP server 5-10 個 tools，預載大概 5,000-10,000 token
GitHub 官方 MCP 一個就吃 1-3 萬 token（超過 50 個 tools）
CLAUDE.md 寫得詳細的話 2,000-5,000 token
全部加起來可以輕鬆破 5 萬

/usage 的 breakdown 等於把這份「家具帳單」攤開給你看。看到帳單你才會發現「啊原來那個 MCP server 我根本沒用過、佔位佔了三個月」。

打開 `/usage` 報表怎麼讀

在 Claude Code 裡輸入：

/usage

你會看到大概這個結構（每個人配置不同，數字會差很多）：

Limits this 5h window:    62%
Weekly cap:               31%

Breakdown by category:
  - MCP servers:           41%
    - github               24%
    - filesystem            8%
    - playwright            6%
    - notion-local          3%
  - Skills:                 8%
  - Subagents:              3%
  - Plugins:                5%
  - Conversation:          43%

幾條解讀規則：

Conversation 佔比過高（>50%） 通常代表你最近跑了長對話、長 context 的任務（例如 code review 整個 codebase）。這層是健康的——這就是你買 Claude Code 訂閱在做的事。

MCP servers 佔比過高（>40%） 通常代表你裝了用不到的 MCP server。看 sub-breakdown，最大那個如果你最近根本沒用，就該卸載。

Skills 佔比過高（>30%） 很少見，通常表示你寫了太多大型 SKILL.md（單檔過長），或是 alwaysApply 的規則寫得太貪心。

Subagents 跟 Plugins 通常是個位數百分比。如果突然飆高，多半是某個 plugin 把 MCP server / skill 都包進去了，要去看那個 plugin 本身。

從報表反推：該砍掉哪些

舉個常見的場景：你的 /usage 顯示 GitHub MCP 佔 24%，但你最近兩個月一個 issue 都沒查過——這就是該動手砍的訊號。

砍的方法不是刪掉它，是從 settings 把它停用。Claude Code 的 settings 通常在 ~/.claude/settings.json 或者 .claude/settings.json（專案層級），裡面 mcpServers 區段把那個 entry 註解掉就好：

{
  "mcpServers": {
    // "github": { ... },  // 暫停，需要時再打開
    "filesystem": { ... }
  }
}

restart Claude Code，再跑一次 /usage，會看到 baseline 直接掉一截。

幾個常見的「該重新評估」名單：

GitHub MCP：tools 太多、context 太重，如果你只用 gh CLI 已經夠了，可以拿掉
Playwright MCP：只有寫 E2E 測試才用得到，平常 standby 太浪費
Notion MCP：寫筆記才用，寫程式時可以關掉
多個資料庫 MCP（mysql / postgres / mssql 同時開）：留你現在這個專案用到的那個就好

砍掉的不是工具，是「用不到的工具預載」。要用時再打開比常駐便宜得多。

為什麼 lazy loading 很重要

這個觀念底下有一條更普遍的規則：不要為了「可能會用到」付固定成本。

Skills 的設計示範這條規則的反面——一個 skill 不被觸發時只佔約 100 個 token（只載入名字跟簡介），被觸發時才把完整內容讀進來。這叫 progressive disclosure —— 預先告訴 agent「有這個東西可以用」，但細節等需要時再讀。

MCP 沒有這層 lazy loading。一個 MCP server 一旦註冊，它的 tools schema 全部要載入到 context window，因為 LLM 必須事先知道有哪些 tool function、各自接受什麼參數，才能決定要不要呼叫。這就是為什麼一個 GitHub MCP 動輒上萬 token——50 個 tool 各自的 schema 加起來就是這個量級。

設計差異的根源很單純：skill 是文件，MCP 是 RPC。文件可以等讀者翻到再看，RPC 必須事先知道介面。

對你的影響是：

大量 skill 沒關係，沒用到不收費
少量但每個都精選的 MCP server，比一堆「以防萬一」的 MCP 划算

挑 MCP 時的判斷標準是「我這禮拜會用到嗎」，不是「以後可能會用到嗎」。

進階：監控你的 weekly cap 曲線

/usage 的「Weekly cap」這條曲線比 5-hour window 更值錢。原因是 5-hour 那條會自己 reset，你被卡了等等就好；weekly cap 卡了，整週都會手綁。

幾個經驗法則：

**週一到週三超過 60%**：表示這禮拜你不能放開來跑 long agent loop，要更省著用
**連續兩週都 < 50%**：你買的方案可能 over-spec 了，可以考慮降一階
**單一 5h 窗口 > 80% 但 weekly cap < 30%**：表示你有突發爆量任務，需要更平均地分配跑大型任務的時段

把 /usage 跑成每天早上的習慣（跟看 git status 一樣），你會慢慢內化出「我這禮拜還剩多少預算」這個直覺，不會月底才發現額度爆了。

跟錢有關的版本：API key 用法

如果你用的是 API key 而不是訂閱：

/cost

這個指令會印目前 session 跑下來累積的美金消耗。對 API 使用者來說，這比 /usage 直接——畢竟你看的不是「額度百分比」，是「實際燒了多少錢」。

實務上建議：

跑大任務前 /cost 一次當基準
跑完再 /cost 一次看消耗
慢慢內化每種任務的「typical cost」，下次估價時心裡有譜

API 用法跟訂閱用法差異很大的點是「沒有額度上限」——只要你的信用卡額度還在就會繼續跑。所以 API key 使用者的紀律比訂閱戶更需要主動，因為訂閱戶會被擋住、API 戶不會。

實際應用情境

場景一：發現額度突然燒得快

打 /usage 看是哪個 category 暴增。最常見是某個 skill / MCP 改版後體積變大、或者你最近開了一個新 plugin 把整套 stack 預載進來。

場景二：規劃下週的大任務

週日晚上跑 /usage，看 weekly cap 還剩多少。如果接下來這禮拜要做 migration、要跑長對話 review、要平行多 session，得先把不必要的 MCP 關掉騰預算。

場景三：評估訂閱方案

連續四週看 /usage，看 weekly cap 平均落在哪。長期都用不到 50%，可以考慮降階；經常打到 80%+，就升一階。

場景四：團隊內部選工具

如果你在團隊內部推薦工具，先用 /usage 算清楚 baseline cost，比給人空泛建議有說服力——「裝這套會吃掉你 30% baseline」比「我覺得不錯」管用多了。

一些踩坑點

/usage 不會自動 refresh：每次跑都是當下快照，要看趨勢得手動連續執行
Plugin 內含的 MCP / skill 不會獨立列出：plugin 是包裹層，breakdown 顯示在 plugins 那欄，要看細節要去 plugin 設定
claude.ai 用的 token 也算進來：因為 Pro / Max 跨產品共用額度，你在 claude.ai 開了長對話會吃 Claude Code 的額度
restart 之後 baseline 會跳一下才穩定：因為 MCP 重新註冊有 warm-up，看 baseline 等 1-2 分鐘再讀比較準