如果啟動開銷是固定的、幾乎省不掉，那 Prompt Caching 到底有什麼實質幫助？
幫助集中在計費，而不是上下文空間。Prompt Caching 針對的是那些每一輪都會重複送出、內容沒有變化的部分（系統提示詞、CLAUDE.md、工具定義），把這些內容標記為可快取，後續請求命中快取時，這部分的計費可以有約九成的折扣。對於一個會話輪數多、每輪都要重新送出同一份固定內容的長對話，這筆折扣累加起來相當可觀。
但這裡的分寸要抓準：快取降低的是「這些 token 花你多少錢」，不是「這些 token 占了上下文視窗多少空間」。200K 的視窗上限，看的是實際占用的 token 數，不是計費後的折扣價，所以即使命中快取、帳單變少，視窗裡的空間該占多少還是占多少，長對話一樣會走向壓縮或摘要。
已經連接、但這次對話沒實際用到的 MCP 伺服器，也會拖累啟動開銷嗎？
會。官方文件與社群拆解都指出，每一個已連接的 MCP 伺服器，即使你這個 session 完全沒呼叫它，它的工具 schema 依然會被載入到系統提示詞裡，讓 Claude 知道「這個工具存在、可以在需要時使用」——這是為了讓 Claude 能正確判斷何時該用這個工具，但代價是每個已連接的伺服器，都會在每一則訊息裡帶來一筆小而確實存在的固定開銷。
實務上的建議做法是定期檢視自己掛載的 MCP 清單：如果某個伺服器一週以上沒被實際呼叫過，先中斷連線，需要用到時再重新連上，這是一個十秒鐘就能做完、但長期下來會持續累積節省效果的動作，不需要因為「以後可能用得到」就讓它常態性地佔著開銷。
除了 /context、/memory、/usage，還有沒有其他方法能更早發現用量異常，而不是等到帳單出來才知道？
有的，而且不需要等到 session 結束。除了這三個內建指令即時查看，社群也發展出獨立的測量工具，例如像 context-budget 這類 CLI 工具，能在你實際把檔案載入對話之前，先掃描工作目錄、列出每個檔案各自的 token 成本，讓你在真正執行「載入這份文件」的動作之前，就先看到代價，而不是載入之後才發現視窗被吃掉一大塊。
另一個實務習慣是分階段檢查：一次 session 剛開始時跑一次 /context 記下啟動基準值，做完一輪明顯會拉進大量檔案或執行大量指令的操作後，再跑一次比對差異，這樣能具體看出「剛才那個動作實際花了多少」，而不是籠統地在 session 結束時才發現總量偏高，卻已經很難回頭定位是哪個步驟造成的。
我不是重度使用者，只是偶爾用 Claude Code 處理小任務，這篇講的內容還有意義嗎？
有意義，但意義的重點不太一樣。如果你的使用模式是「偶爾開一個 session、問幾個問題就結束」，固定啟動開銷占你總用量的比例本來就會偏高——因為你沒有足夠多的後續對話輪次去稀釋那筆先付的成本，這種情況下更該關心的反而是「有沒有必要開這麼多獨立的短 session」，把幾個小任務合併在同一個 session 裡處理，能讓那筆固定成本分攤得更划算。
如果你的任務本身很單純、不太涉及大量檔案讀取或重複執行指令，那麼複利增長的部分（未過濾輸出、累積讀檔）對你的影響本來就有限，這篇文章裡最相關的部分反而是啟動開銷本身的認知——知道那 2 到 3 萬 token 是怎麼回事，至少能讓你在看到用量數字時，不會誤以為系統本身有問題，而是先確認這是不是正常的固定成本。
GitHub 上有一則具體的錯誤回報（issue #52979）：在一個完全乾淨的資料夾裡開一個新 session，什麼檔案、工具、CLAUDE.md 都沒有，只打了一個字「hi」，結果 token 用量顯示約 3 萬——這不是單一使用者的異常個案，firecrawl.dev 整理的優化指南也把「session 開始時就先吃掉 2 萬到 3 萬 token」直接稱為「不是 bug，是 Claude Code 初始化的固定開銷」。這篇要拆解的，就是這筆錢到底花在哪裡，以及哪些部分你真的能省、哪些部分你省不掉。
Claude Code 在你打出第一個字之前，就已經把好幾樣東西塞進上下文：系統提示詞本身、內建工具的定義（官方文件說明工具定義被摺進系統提示詞裡一併計算，不會單獨列出）、專案與全域層級的 CLAUDE.md、記憶檔案、已連接 MCP 伺服器的工具 schema，以及已安裝 Skill 的名稱與描述。這些東西每一則訊息都會重新送一次——因為 API 本質上是無狀態的，沒有「記得住」這回事，每一輪對話都是把整疊資料重新攤開一次。
這也是為什麼「刪掉 CLAUDE.md 裡一段話、覺得應該有省到」這種直覺式優化，實際效果往往模糊不清：你看得到的只是自己主動加進去的那部分，系統提示詞、工具 schema 這些固定成本，不會因為你刪減自己寫的內容而消失。
官方文件與多篇技術拆解都提到同一個關鍵區分：Prompt Caching 能把這些固定重複送出的內容快取起來，實際計費可以有九成左右的折扣，但快取省的是「錢」，不是「上下文空間」。這些 token 依然完整佔用著 200K 的上下文視窗、依然計入速率限制，內容一多，一樣會讓輸出品質在視窗填滿到 5 到 7 成之後開始下滑——這正是上下文腐化要處理的問題。便宜不等於免費，更不等於不佔位置。
把啟動時那 2 到 3 萬 token 當成固定樓地板去接受，通常是務實的——這筆錢幾乎每個人都要付。真正值得花時間排查的，是那些會隨著 session 拉長而不斷疊加、複利增長的部分。一個具體案例來自社群整理的實測數據：測試指令沒有做輸出過濾時，單次輸出約 2,131 tokens，一小時跑個三、四次，疊加起來的量遠遠超過你花一整晚精心修剪的 CLAUDE.md；同一個指令改成只輸出失敗項目後，單次成本降到約 363 tokens——這是那份整理裡標註為「槓桿最高、但幾乎沒人做」的單一改動。
另一個常被低估的複利來源是已讀取的檔案：Claude Code 每讀一個檔案，那份內容就永久留在對話歷史裡，往後每一則訊息都要重新處理一次。一次 PR 審查拉進 20 個檔案，意味著這 20 個檔案的內容，會在這個 session 剩下的每一輪對話裡反覆重新送出——這不是一次性成本，是會跟著 session 長度一起累積的成本。
比起憑直覺猜測「這樣改應該有省到」，Claude Code 本身提供了幾個可以直接看到數字的工具：/context 即時列出目前上下文視窗裡每一項元素各佔多少 token，總用量一目瞭然；/memory 顯示這個 session 啟動時究竟載入了哪些 CLAUDE.md 與記憶檔案；/usage（Opus 4.8 起提供）能具體指出目前的用量集中在哪個成分上。與其先刪東西再觀察「感覺變快了」，不如先跑一次 /context，看清楚錢實際花在哪裡，再決定要不要動手。
下次覺得「這個 session 用量怎麼衝這麼快」時，先分清楚問題落在哪一類：是每個 session 都要付一次的固定啟動開銷（系統提示詞、CLAUDE.md、已連接的 MCP 與 Skill），還是會隨對話輪數複利增長的可變成本（未過濾的指令輸出、逐步累積的已讀檔案）。前者接受它是先天成本、頂多做微幅裁剪；後者才是真正值得花時間排查、且改一次就能持續受益的地方。