Claude Token 是什麼？為什麼 Claude Code 成本這麼高？

Claude 中的 token 是什麼？

token 是 Claude 讀取與寫入的文字單位：即單詞的片段，大約等於 3.5 個 English 字符。根據 Anthropic 的定義，若將空格與標點符號納入計算，每個單詞所佔用的 token 遠超過 1 個，因此 1,000 個單詞的散文內容通常會超過 1,300 個 token。程式碼的 token 消耗較高：由於大括號、運算子、底線與縮排會導致每個字元拆解出比 English 更多的 token，因此數百行的原始碼檔案通常會佔用數千個 token。若 Agent 決定讀取一個 2,000 行的檔案，在撰寫任何新程式碼之前，就已消耗了五位數的 token 額度。

關於 tokenizer 有兩點常令使用者困惑。首先，tokenizer 是針對特定模型設計的。截至 2026 年 7 月，Opus 4.7 及後續版本、Sonnet 5 以及 Fable 5 使用了較新的 tokenizer；處理相同文本時，產生的 token 數量比早期的 Claude 模型多出約 30%（確切增幅視內容而定），這會改變 token 預算，即便單個 token 的價格並未隨之調升。其次，tiktoken 是部落格文章中最常引用的函式庫，但它是 OpenAI 的 tokenizer，對於一般文本會比 Claude 少估約 15–20%，程式碼的誤差則更大。唯一可靠的計算方式是下文介紹的 count_tokens endpoint。

為什麼您的程式開發成本會如此高昂

無論是 API 帳單或訂閱額度，所有 Claude 的費用都取決於單一計費指標：輸入與輸出之 tokens。定價頁面看起來很簡單：每百萬個 input tokens 收取多少金額，每百萬個 output tokens 收取多少金額。但它未說明的是，在 agentic coding session 中，輸入端的消耗遠比直覺更高，因為每一次對話輪次都會重新傳送完整的對話內容。我從事計費基礎設施銷售已有 15 年，而 tokens 是我見過第一個大多數客戶都無法準確判斷消耗原因的計費指標。本教學將說明：在 agentic session 中，哪些內容被計為 input 與 output、為何重傳迴圈（resend loop）如此昂貴、為何 prompt caching 會改變計算邏輯，以及哪些因素會實際影響最終金額。

Everything is input: 計費基準的實際內容

使用者通常認為費用是支付給 Claude 產生的程式碼。但在 Agent 模式的對話中，這僅佔極小部分。Input tokens 的單價較低，但數量龐大，包含以下項目：

• System prompt。 包含 Claude Code 的框架指令，以及在對話開始時載入，並隨後包含在每次請求中的 CLAUDE.md 與 memory 檔案。
• Tool definitions。 Agent 可調用的所有工具 schema。每當 連接 MCP server 都會增加此固定開銷。雖然 Claude Code 目前預設會延遲載入完整的 MCP 工具定義，僅在工具首次使用時才將其放入 context，這雖減輕了成本，但無法完全消除。
• Agent 讀取的每個檔案。 若對原始碼檔案進行 Read，則整個檔案都會進入 context 並持續存在。
• 每個工具的執行結果。 測試執行結果、grep 輸出、終端機輸出、編譯日誌——所有內容都會轉換為 input tokens。若測試失敗並輸出 8,000 行內容，其費用相當於一本小冊子。
• 每次對話輪次重新傳送的完整對話紀錄。 此項需特別說明。

重新傳送導致成本增加

Claude API 是無狀態的 (stateless)。它不會在請求之間記憶您的工作階段 (session) —— 任何系統都不會。因此，在第 2 輪對話時，用戶端會傳送第 1 輪的內容、其回應以及您的新訊息。到了第 50 輪，它會重新傳送第 1 輪至第 49 輪的所有內容 —— 包含每一次的檔案讀取、每個工具結果、每個 diff —— 加上第 50 輪。模型每次都會重新閱讀整個對話紀錄，而每一次重新閱讀的 token 都會被計入輸入成本 (input billing)。

結果：每輪對話的成本會隨工作階段長度呈線性增長，而總工作階段成本則呈二次方增長。在第 3 輪時僅需 0.5 美分的一行問題，到了第 60 輪可能會變成原來的 20 倍，因為它承載了 60 輪的資料量。這項事實解釋了大多數「為什麼帳單金額這麼高」的支援案件，且這並非 Claude 的特性 —— 每個具備狀態感 (stateful-feeling) 的 LLM 產品，底層都是透過重新傳送迴圈 (resend loop) 來運作的無狀態 API。

Output：您所看到的內容，以及您未看到的思考過程

輸出 Token 的成本較高 —— 在目前的產品線中，其費率為輸入費率的五倍（截至 2026 年 7 月，Opus 4.8 為 $5/$25，Sonnet 5 為 $3/$15，Haiku 4.5 為 $1/$5）。輸出內容包含 Claude 生成的文字與程式碼，以及 thinking tokens：模型在回答前進行的內部推理。這裡有兩個重點：首先，思考過程按輸出費率計費，並計入 max_tokens —— 若 API 回應因 stop_reason: "max_tokens" 而中斷，且答案被截斷，通常是因為思考過程已耗盡預算。其次，在目前的模型中，推理摘要可能完全不顯示 —— Opus 4.8、Sonnet 5 與 Fable 5 預設會省略摘要 —— 但思考過程確實存在且仍會計費。隱藏並不代表免費。

Claude Code 預設啟用擴展思考功能，因為這能顯著提升多步驟任務的表現，且預設預算每次請求可達數萬個 Token。針對簡單任務，您可以降低其強度：透過 /effort 或 /model 降低投入程度，或在 /config 中調整思考設定。這是一種實質的成本控制手段，而非迷信。

Prompt caching 重塑成本計算

Prompt caching 是避免重複傳送導致成本失控的關鍵。API 可以快取提示詞中穩定的前綴（例如：system prompt、tool definitions、對話歷史），並在下次請求時以極低的價格提供服務。截至 2026 年 7 月，倍率計算如下：快取寫入（write）的成本為基礎輸入費率的 1.25×（1 小時版本為 2×），而快取讀取（read）的成本僅為 0.1×。寫入屬於溢價項目，而讀取則享有 90% 的折扣。單次讀取所節省的費用，就足以抵銷 5 分鐘寫入所產生的溢價。

Claude Code 會自動管理快取。在正常的對話階段，大部分重複傳送的內容都會從快取中取得。然而，預設快取的有效期為最後一次使用後的 5 分鐘。若暫時離開太久，回來傳送訊息時，快取已過期，導致整個累積的前綴必須以 1.25× 的價格重新寫入，而非以 0.1× 進行讀取。在一個 150K-token 的對話階段中，這一次冷啟動（cold turn）的成本會超過十幾次熱啟動（warm turns）。這是一個值得記住的反直覺結果：間歇性的工作節奏可能比持續工作更貴，因為任何超過 TTL 的閒置間隔，都會將下一次請求從廉價的讀取轉變為昂貴的重寫。建議分段工作，不要每 10 分鐘才傳送一則訊息來維持大型對話。

若您是從 VPS 上的自有應用程式呼叫 API，則無法直接享有這些優勢。常見的錯誤是在 system prompt 中加入 timestamp 或 request ID，這會導致每次請求的前綴位元組（prefix bytes）都在變動，進而使快取失效。判斷依據是當請求內容看似相同時，usage.cache_read_input_tokens 卻持續為零。

公式與實作範例

請忽略任何僅提供單一固定成本（例如「每次 session 花費 $X」）的說法。Session 的成本差異可達兩個數量級。核心原則是以下公式：

turn cost = (uncached input      x base input price)
          + (cache writes        x 1.25 x base input price)
          + (cache reads         x 0.10 x base input price)
          + (output incl. thinking x output price)

session cost = sum over all turns

以 Claude Opus 4.8 為例進行計算。截至 2026 年 7 月，其輸入成本為每百萬 token $5，輸出成本為每百萬 token $25。假設一個 session 中間的對話回合包含 80,000 token 的累積 context：其中 75,000 token 從 cache 讀取，3,000 token 為新寫入，2,000 token 為未經 cache 的新輸入，1,500 token 為包含 thinking 的輸出。

• Cache reads: 75,000 × $0.50/M = $0.0375
• Cache writes: 3,000 × $6.25/M = $0.019
• Uncached input: 2,000 × $5/M = $0.010
• Output: 1,500 × $25/M = $0.0375

單次回合成本約為 $0.10；若有五十次相同的回合，總成本約為 $5。若在 cache 過期後進行相同的對話：在輸出之前，必須以 $6.25/M 的價格重新寫入全部 80,000 token，成本為 $0.50 —— 這比原本熱啟動（warm）回合的總成本高出約五倍，但工作量完全相同。這個差距即是 caching 技術的核心價值。

用於校準而非預測：根據 Anthropic 截至 2026 年 7 月發布的企業級 Claude Code 部署數據，每位開發者每日平均花費約 $13（每月 $150–250），且 90% 的使用者每日花費低於 $30。實際成本取決於模型選擇、session 管理習慣以及 codebase 大小，這正是下述控制因素至關重要的原因。

查看您的使用量

在 Claude Code 中，指令為 /usage（/cost 仍可使用，其為別名）。頂部的 Session 區塊會顯示 Token 統計數據，以及針對當前 Session 的本地計算成本估算；若使用訂閱方案，該畫面會顯示方案限制進度條，並將近期使用量細分為 skills、subagents、plugins 及各個 MCP servers。若要取得 API 帳戶的正式帳單資訊，請以 Claude Console 中的 usage 頁面為準，CLI 顯示的數值僅為估算值。使用 /context 可繪製彩色網格，顯示 佔用 context window 的內容 — 包括 system prompt、tools、MCP definitions、files 及 history — 這是快速找出 CLAUDE.md 過載或 MCP server 通訊過於頻繁的最快方法；傳入 all 參數可展開各項目的詳細細目。

透過 API，每個回應都會準確說明執行狀況：

response = client.messages.create(model="claude-sonnet-5", max_tokens=2048,
                                  messages=messages)
u = response.usage
total_prompt = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
print(f"uncached={u.input_tokens} written={u.cache_creation_input_tokens} "
      f"read={u.cache_read_input_tokens} output={u.output_tokens}")

請注意，input_tokens 僅代表 未經快取的剩餘量 — 實際的 prompt size 為所有三個輸入欄位的總和。若一個執行一小時的 agent 顯示 input_tokens: 4000，其成本並不低；另外 200,000 tokens 是從 cache 中讀取的。若要在發送前進行估算，請使用 token-counting endpoint — 此呼叫不需付費，擁有獨立的 rate limit，並會根據您指定的模型使用其 tokenizer 進行計算（請將結果視為接近的估算值；實際帳單以真實請求為準）：

count = client.messages.count_tokens(model="claude-sonnet-5",
                                     messages=[{"role": "user", "content": big_file}])
print(count.input_tokens)

基於上述原因，請勿使用 tiktoken。

訂閱方案與按量計費之比較

本指南中的運作機制在各處皆相同，僅結算方式不同。使用 API key 時，Anthropic 會依據公布費率按 token 進行按量計費（pay-as-you-go）——上述所有數字皆代表實際金額。若使用 Claude 訂閱方案（Pro, Max, Team, Enterprise），Claude Code 的用量會從方案包含的額度中扣除：截至 2026 年 7 月，該額度包含一個滾動的 5 小時工作階段視窗與一個每週視窗，並由各個模型與 claude.ai 聊天功能共用；其中的 /usage 美元數值僅供參考，並非帳單金額。若用盡視窗，系統會顯示 "You've hit your session limit" 或 "You've hit your weekly limit" 並顯示重設時間 —— 使用 /model 切換模型無法恢復存取權限，因為各模型共用相同的視窗。方案可選擇啟用使用額度（usage credits），並透過 /usage-credits 進行管理，以便在達到上限後購買額外用量。我不會列出各方案的配額：這些數值變動最頻繁，請直接查看 claude.com/pricing 與您個人的 /usage 進度條。在訂閱模式下，token 機制依然重要 —— 浪費的 session 會像消耗金錢一樣消耗您的視窗額度。關於訂閱方案的詳細資訊，請參閱 哪種 Claude 方案符合您的需求。

有效的控制手段

• 限制 Agent 的讀取範圍。 「修正 auth.py 中的驗證錯誤」僅讀取一個檔案；「優化此程式碼庫」則會讀取 40 個檔案。保持 CLAUDE.md 精簡 —— 因為它會載入至每個 session，請僅保留核心內容 —— 並將特定工作流的指令移至按需載入的 skills 中。
• 清晰且精簡。 在不相關的任務之間使用 /clear —— 過時的 context 會在後續每則訊息中被重複傳送並重複計費。在單一長任務中，/compact Focus on the failing tests and the diff 會摘要歷史紀錄，避免 Token 消耗呈平方級增長。
• 選擇合適的模型規模。 截至 2026 年 7 月的入門價格，Sonnet 處理多數編碼工作 每百萬 Token 為 $2/$10（標價為 $3/$15，相比之下 Opus 為 $5/$25），而 Haiku 每百萬 Token $1/$5 則是處理日誌篩選等機械式 subagent 工作最合適的工具。/model 可在 session 中進行切換。
• 預先過濾冗長的輸出。 使用 hook 對測試結果進行 grep，在 Claude 讀取前僅保留失敗項目，可將 20,000 tokens 的工具結果縮減至 300 tokens，且在該回合後續的每次重傳中皆能生效。
• 批次處理非互動式任務。 對於您自有的 API pipeline（如分類、大量審核、夜間作業），Batches API 提供 50% 的折扣，代價是改為非同步交付。
• 注意快取時效。 進行連續的工作。在 VPS 上的 tmux 執行 Claude Code session 閒置時不需付費 —— 僅在執行回合時消耗 Token —— 但閒置會導致 warm cache 失效，下一個回合必須支付重新寫入的費用。

FAQ

Claude Code 的編碼工作階段會消耗多少 token？

沒有固定數值。隨著檔案與歷史紀錄累積，單次中等規模的對話通常會包含數萬個 prompt tokens；整個工作階段的總量則會達到數百萬。大部分 token 是透過 cache 處理，費用僅為基礎費率的十分之一。參考 Anthropic 於 2026 年 7 月發布的企業數據，每位開發者每日活躍的平均費用約為 $13，90% 的使用者費用在 $30 以下。請在您的工作階段執行 /usage；觀察五分鐘的結果會比任何發布的平均值都更準確。

即使我看不到 thinking tokens，也會產生費用嗎？

會。Thinking tokens 會按 output tokens（較高費率）計費，並計入 max_tokens。即使介面未顯示推理摘要，目前的模型仍會對其計費。若回應在可見答案完成前，因 stop_reason: "max_tokens" 而中斷，通常是因為 thinking tokens 耗盡了預算。在 Claude Code 中，對於不需要深度推理的任務，請使用 /effort 降低 effort level。

為什麼 Claude Code 的長工作階段每則訊息成本會增加？

因為 API 是無狀態的（stateless）：每一次對話都會將整個對話內容（包含所有讀取的檔案、工具結果與先前的對話）作為輸入重新傳送並計費，因此第 50 次對話會包含第 1 到 49 次對話的內容。Prompt caching 可以將重複的前綴（prefix）成本降至基礎輸入價格的約十分之一，但前綴本身會持續成長；若超過 cache TTL，下一次對話將會以全額重新計算。使用 /compact 可縮減歷史紀錄；使用 /clear 可重設歷史紀錄。

如何檢查我的 Claude token 使用量與成本？

在 Claude Code 中，/usage 可顯示工作階段的 token 統計、本地成本估計，以及訂閱方案的限制進度條（/cost 為其別名）；/context 則顯示目前佔用視窗的內容。若要取得權威的 API 帳單資訊，請使用 Claude Console 中的 usage 頁面。在程式碼中，請讀取 response.usage —— 將 input_tokens、cache_creation_input_tokens 與 cache_read_input_tokens 加總即為真實的 prompt size —— 並請使用 count_tokens 端點進行預估，切勿使用 tiktoken。