Claude 的 1M tokens 要多少錢？

Claude 中的 1M tokens 是多少？

1M tokens 代表 1,000,000 個 tokens，也是所有 Claude API（application programming interface）價格採用的計價單位。它沒有單一價格，因為輸入與輸出採用不同費率，而且每個模型都有各自的費率組合。截至 August 2026，Claude Haiku 4.5 的 1,000,000 個輸入 tokens 費用為 $1，Claude Sonnet 5 為 $2，Claude Opus 5 為 $5。

輸出是費用較高的部分。所有目前的模型，其輸出費率都是輸入費率的 5 倍，因此輸入與輸出的比例，比表面上的單價更能決定實際帳單。傳送長篇文件並回傳簡短答案的應用程式，與根據簡短提示撰寫長篇答案的應用程式，費用結構會大不相同。

本頁介紹單位經濟：token 的成本，以及如何在建置前估算費用。若要了解工作期間 tokens 實際流向何處，請閱讀 Claude Code 工作階段中 tokens 的流向。

1M tokens 的規模

Token 是模型讀取或產生的文字片段。Anthropic 的粗略估算是每 4 個字元約 1 個 token，英文約為 0.75 個單字。因此，1 million tokens 約等於 750,000 個單字，或約 4 MB 的純文字。

常見輸入的公開估算值，更能幫助理解這個規模。

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

依照這些比例，1M tokens 約等於讀取 400 個一般網頁一次，或 8 篇同等規模的研究論文。這相當於完整處理一個中型程式碼庫一次，或供 1 個人輕度聊天使用 1 個月。

以上都只能視為估算值。程式碼、JSON 及英文以外語言的文字，每個 token 包含的單字較少，因此 0.75 這個比例屬於較樂觀的情況。還有一項因素會影響計數：Claude Opus 4.7 及後續版本，包括 Opus 5 和 Sonnet 5，採用較新的 tokenizer。相較於 Sonnet 4.6 及更早版本，處理相同文字時產生的 token 約多 30%。Claude Haiku 4.5 使用較舊的 tokenizer。因此，若在 Haiku 4.5 上測得某個數量，對相同輸入而言，這個數量會低估 Sonnet 5 的 token 數。這表示跨越這個分界直接比較每 million tokens 的價格並不公平。決定前，請先將相同提示分別交給兩個模型計數。

Claude 每 1 百萬個 token 的收費

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 在 2026 年 8 月 31 日前採用介紹性定價，輸入費用為 $2，輸出費用為 $10。自 2026 年 9 月 1 日起，改用標準費率：輸入費用為 $3，輸出費用為 $15。Claude Opus 5 的輸入費用為 $5，輸出費用為 $25。還有一個模型的價格遠高於上述範圍：Claude Fable 5 的輸入費用為 $10，輸出費用為 $50，因此這些費率是否值得支付取決於你實際交給它處理的工作。

費率可能變動。請將本頁的所有數字視為截至 2026 年 8 月的計算範例，並在核定預算前，於官方定價頁面確認目前的數字。

這些費率說明 Claude 的成本，但無法判斷它是否適合你的工作負載，也不代表它是較便宜的選項；以 Claude 和 ChatGPT 分別計算的 3 項工作成本會說明哪個 API 的成本較低。

context 長度不會改變費率。在 Claude 4.6 及後續版本中，完整的 1M token context window 會依標準定價計費，因此 900,000 token 的請求與 9,000 token 的請求，每個 token 的費用相同。較長的 prompt 會增加費用，是因為 token 數量較多，而不是因為另有 long-context 費率。

價格變動後仍然有效的計算方式

每張帳單都包含兩次乘法和一次加法。

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

寫成可執行的程式碼：

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

這會輸出 0.0126。在 Sonnet 5 上，傳送 4,300 個輸入 token 並收到 400 個輸出 token 的請求，成本約為 1.3 美分。請將兩個費率集中放在程式碼中的同一處。價格變動時只需修改兩行，系統中的所有估算就會同步更新。

實際應用程式的估算範例

以支援助理為例。它的 system prompt 與產品文件合計 4,000 tokens，而且每次請求都會傳送，因為 Messages API 沒有狀態，模型也不會在呼叫之間保留記憶。使用者問題約增加 300 tokens。回答約 400 tokens。每次請求因此包含 4,300 個輸入 tokens 與 400 個輸出 tokens。

1,000,000 個輸入 tokens 約可支援 232 次這類請求。每天發出 1,000 次請求時，應用程式每天會消耗 4,300,000 個輸入 tokens，因此「1M tokens」的流量不到 6 小時就會用完。

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

在 Claude Opus 5 上，這樣的流量每 1,000 次請求成本為 $31.50。在 Sonnet 5 上則為 $12.60。改用 Claude Haiku 4.5 後，成本降至 $6.30；而 Sonnet 5 啟用暖的 prompt cache 後，成本還會進一步降至 $5.40。

將這個流量乘以 30，就是一個月的成本。Sonnet 5 按牌價計算，每月約 $378。同一個應用程式啟用暖的 cache 後，每月約 $162。在這個用量下，模型選擇與快取決策各自帶來的影響，都大於你能談到的任何費率折扣。要使用哪個模型是另一個問題；只要能通過評估，最便宜的模型就是最佳選擇：選擇 Opus、Sonnet 與 Haiku說明如何正確測試。

Prompt caching 可降低重複內容的成本

每個請求中的前綴都相同，長度為 4,000 tokens，但每次都必須按照完整輸入價格付費。Prompt caching 會儲存已處理的前綴，重複使用時則按照較低費率計費。

讀取快取的費用是基本輸入費率的 0.1 倍。快取寫入在 5 minute 生命週期內，費用是基本費率的 1.25 倍；在 1 hour 生命週期內，費用是基本費率的 2 倍。因此，5 minute 快取讀取 1 次即可回本，因為寫入成本只多出 0.25 倍，而每次讀取可節省 0.9 倍。1 hour 快取則需要讀取 2 次才能損益兩平。

啟用快取最簡單的方法，是加入單一頂層欄位：

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

接著讀取回應中的 usage 區塊：

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

這 3 個輸入計數器的計費費率各不相同，合計後才是實際輸入量：total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens。啟用快取後，如果只讀取 input_tokens 來估算成本，結果會嚴重失準。

有 2 個因素會讓快取無法發揮效益，而且兩者都不會明確回報錯誤。

前綴必須逐位元組相同。 快取查找會比對前綴，因此在 system prompt 開頭加入時間戳記或使用者名稱，會讓前綴在每個請求中都不同。此時每次都必須支付基本輸入費率的 1.25 倍，而且一次快取讀取都不會發生。其徵兆是 cache_creation_input_tokens 持續偏高，而 cache_read_input_tokens 維持 0。將 cache_control 放在跨請求內容相同的最後一個區塊，並把所有會變動的內容放在其後。變更 tools 定義會使其下方的整個快取失效，因為失效會依照 tools、system、messages 的順序向下套用。

前綴必須足夠長。 Opus 5 的最小可快取長度為 512 tokens，Sonnet 5 為 1,024，Haiku 4.5 為 4,096。較短的 prompt 不會快取，也不會回傳錯誤。上述範例的 4,000 token 前綴可在 Sonnet 5 上快取，但在 Haiku 4.5 上無法快取，因為 4,000 低於該模型的最低長度。當兩個計數器都為 0 時，表示沒有任何內容被快取。

批次處理可將費率降低一半

Batch API 會以非同步方式處理請求，輸入與輸出皆享有 50 percent 的折扣。以上述範例而言，每 1,000 個請求的費用會從 $12.60 降至 $6.30。此折扣可與提示快取疊加，因此使用快取的批次工作是執行大量工作的最低成本方式。

代價是延遲時間增加，因此不適合需要人員等待結果的工作。這種方式適合夜間分類處理與文件回填。

單一對話中的聊天成本為何會增加

由於 API 不會保留狀態，您的用戶端必須在每一輪重新傳送完整對話。因此，單一聊天中的 token 用量會隨對話長度平方成長，而不是直線增加。

假設每輪平均使用 500 個 token。第 1 輪會傳送 500 個輸入 token，第 2 輪會傳送 1,000 個，第 20 輪則會傳送 10,000 個。使用 n(n+1)/2 加總後，20 輪對話總共會傳送約 105,000 個輸入 token，但對話記錄本身只有 10,000 個 token。

因此，聊天功能的成本會高於對話記錄所顯示的數字。在長對話中，快取穩定的前綴或摘要整理較早的輪次，通常很快就能抵銷成本。會反覆執行工具呼叫的 agent 也有相同的成長模式，而且情況更嚴重：每個工具結果都會保留在歷史記錄中，並在之後的每一輪重新傳送。為自行執行的 agent 設定嚴格的支出上限在這種情況下尤其重要，因為成本會自動增加，且沒有人持續監控。

先計算 token，再進行推測

不要再根據字數推算 token 數量。API 會替你計算 token，而且不收費；此功能使用的速率限制與建立訊息的速率限制分開。

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

回應包含一個欄位：

{ "input_tokens": 14 }

將實際的 system prompt 與工具定義，以及具代表性的使用者訊息傳入，然後把取得的數字代入上方的成本函式。此 endpoint 接受與訊息請求相同的 request body，因此圖片與 PDF 也能正確計算。需要注意兩點。這個數量是估算值，可能與計費數字略有差異。此外，計算會使用你傳入之模型的 tokenizer，因此應傳入實際要執行的模型。

無法事先計算 output token，因為它們尚未產生。使用 max_tokens 設定上限，再從即時流量的 usage.output_tokens 測量實際分布。

帳單中還有哪些費用

Token 佔據帳單的大部分。還有幾項費用不是 token，卻常讓人意外。

• 工具定義會在每次請求中轉換成輸入 token。僅 Opus 5 的工具使用系統提示就會增加 286 到 406 個 token，還未計入您自己的結構描述。10 個冗長的工具說明，可能讓小型提示的大小增加一倍。
• Web search 的費用為每 1,000 次搜尋 $10，此外，搜尋結果進入內容後所消耗的 token 也會計費。
• Web fetch 本身不收取額外費用，但擷取的頁面會轉換成輸入 token。100 kB 的說明文件頁面大約包含 25,000 個 token。
• 在 Claude 4.6 及後續版本中，使用 inference_geo 要求僅在 US 執行推論，會對每一類 token 套用 1.1 倍乘數，也包含快取讀取與寫入。

API 是否值得購買，完全取決於您的使用量。通常是方案達到用量上限後，才會開始思考這個問題；而 突破用量限制的方法，從等待限制視窗結束，到將這些工作改用按量計費的 API 執行都有。使用量低於某個程度時，固定月費方案明顯更划算；將 API 與 Claude 訂閱方案比較則會以實際數字進行比較。

FAQ

Claude 中 1M tokens 的費用是多少？

這取決於模型，以及 tokens 是輸入還是輸出。截至 August 2026，Claude Haiku 4.5 的一百萬個輸入 tokens 費用為 $1；Claude Sonnet 5 採 introductory pricing，每一百萬個輸入 tokens 費用為 $2；Claude Opus 5 則為 $5。這些模型的輸出費用都是輸入費率的 5 倍。Sonnet 5 將於 1 September 2026 調整為每一百萬個輸入 tokens $3，輸出 tokens $15。費率會變動，因此在將數字編入預算前，請先在官方定價頁面確認。

1M tokens 等於 1M words 嗎？

不等於。一個 token 約含 4 個英文字符，或約 0.75 個 words，因此一百萬個 tokens 約等於 750,000 個 words。這個比例只能作為參考。程式碼、JSON 及英文以外的語言，每個 word 使用的 tokens 較多。Claude Opus 4.7 及後續版本也使用較新的 tokenizer；對相同文字產生的 tokens 約比 Claude Sonnet 4.6 及更早版本多 30 percent，因此不同模型世代之間的計數不具可移植性。請使用免費的 /v1/messages/count_tokens endpoint，並傳入預計執行的模型來測量。

prompt caching 一定能節省費用嗎？

不一定。5 minute 的 cache write 費用是基本輸入費率的 1.25 倍，因此寫入後從未讀取的 prefix，費用會比直接傳送高 25 percent。只要讀取 1 次就能回本。它會以兩種方式失效，而且都不會顯示錯誤。如果每次 request 之間的 cached prefix 有變更，lookup 永遠不會相符，因為這是 exact prefix match。如果 prefix 短於模型可快取的最小長度，Sonnet 5 為 1,024 tokens、Haiku 4.5 為 4,096 tokens，則不會快取任何內容，也不會回傳錯誤。當 cache_creation_input_tokens 和 cache_read_input_tokens 都讀取為 0 時，表示 cache 沒有發揮作用。

為什麼帳單增長速度比訊息數量快？

因為每一輪都會重新傳送完整對話。Messages API 不會保存狀態，因此對話的第 20 輪會再次將前 19 輪全部作為輸入傳送。若每輪平均 500 tokens，20 輪對話會傳送約 105,000 個輸入 tokens，即使 transcript 長度只有 10,000 tokens。Agent loop 也是相同情況，因為每個 tool result 都會留在 history 中。請快取穩定的 prefix，或摘要較早的輪次，並將這些內容從 request 中移除。