SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 已更新 2026-10-28

Claude 的 1M tokens 要多少錢?

Claude API 以每百萬 tokens 計價,輸入與輸出分開收費。了解 Haiku 4.5、Sonnet 5 與 Opus 5 的費率,並用實際算式估算每月帳單。

Claude 中的 1M tokens 是多少?

1M tokens 代表 1,000,000 個 tokens,也是 Claude API(應用程式介面)模型報價所使用的單位。它沒有單一價格,因為輸入與輸出會以不同費率計費,而且每個模型都有各自的費率組合。Claude Haiku 5.5 有兩組費率:prompt 不超過 100,000 個 tokens 時適用一組,超過時則適用較高的另一組。截至 2026 年 10 月,Claude Haiku 4.5 的 1,000,000 個輸入 tokens 費用為 $1,Claude Sonnet 5 為 $2,Claude Opus 5 為 $5。

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

本頁說明單位成本:token 的價格,以及建置前如何估算費用。若要了解工作期間 tokens 實際用在何處,請閱讀 Claude Code 工作階段中 tokens 的使用位置。

1M tokens 的規模

Token 是模型讀取或寫出的文字片段。Anthropic 的詞彙表指出,在 Claude 4.7 以前的模型中,1 token 約等於 3.5 個英文字元。Anthropic 的模型概覽表示,這類模型的 1 million tokens 約可容納 750,000 個單字;以每個 token 3.5 個字元計算,約等於 3.5 million 個字元,也就是約 3.5 MB 的純英文文字。在 Claude Opus 4.7 導入的新 tokenizer 中,相同的 1 million tokens 約可容納 555,000 個單字,或約 2.5 million 個字元。

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

圖表Approximate input token counts for common content, published estimates
此圖表背後的資料
[
  {
    "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 篇相同規模的研究論文。這相當於完整處理一個中型 codebase,或供 1 個人進行 1 個月的輕度聊天使用。

上述數值都只能視為估算。Code、JSON 及英文以外語言的文字,每個 token 可容納的單字較少,因此這些單字數屬於偏樂觀的估計。還有一項因素會改變計數:Claude Opus 4.7 及後續版本,包括 Opus 5 和 Sonnet 5,使用較新的 tokenizer。相同文字在這些 tokenizer 中產生的 tokens,約比 Sonnet 4.6 及更早版本多 30 percent。Claude Haiku 4.5 使用較舊的 tokenizer。因此,對相同輸入而言,在 Haiku 4.5 上測得的計數會低估 Sonnet 5 的計數,也表示跨越這個界線直接比較每 million tokens 的價格並不公平。決定前,請先對 2 個模型使用相同的 prompt 進行計數。

Claude 每百萬個 token 的費用

圖表Claude API list price in USD per million tokens, October 2026
此圖表背後的資料
[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 4.6",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 的輸入費用為 $2,輸出費用為 $10。Anthropic 起初將這個價格作為優惠價格提供至 31 August 2026,之後改為標準價格,並取消原定調漲至 $3 和 $15 的計畫。Claude Opus 5 的輸入與輸出費用分別為 $5 和 $25。Fable 系列模型的價格則完全高於上述範圍:Claude Fable 5 與較新的 Claude Fable 5.1,輸入費用均為 $10,輸出費用均為 $50,因此這些費率是否值得支付取決於你實際交給它處理的工作。

Anthropic 目前的產品陣容比本頁列出價格的模型更新。Claude Opus 5.5 的輸入費用為 $4、輸出費用為 $20;Claude Sonnet 5.5 為 $2 和 $10;Claude Haiku 5.5 則為 $0.10 和 $0.50 起。Opus 5、Sonnet 5、Haiku 4.5 與 Fable 5 現在列為仍可使用的 legacy models,因此下方的實作範例仍可依原樣執行。Haiku 5.5 的費用與適用情境介紹這些新模型中價格最低的一款。

費率會變動。本頁所有數字都應視為截至 October 2026 的實作範例。正式核定預算前,請在官方定價頁面確認目前的數字。

這些費率說明 Claude 的費用,但無法說明它是否適合你的工作負載,且Claude 與 ChatGPT 的 3 項工作成本比較會顯示兩者的 API 在哪些情況下較具成本優勢。

有一項因素不會改變費率:context length,但有一個例外。在 Claude 4.6 及後續模型中,除了 Claude Haiku 5.5 以外,完整的 1M token context window 都按照標準價格計費。因此,900,000 token 的請求與 9,000 token 的請求,每個 token 的費用相同。較長的 prompt 之所以費用較高,是因為 token 數量較多,並不適用另一套長 context 費率。Claude Haiku 5.5 則依 prompt 長度定價:prompt 超過 100,000 token 的請求,每百萬個 token 的輸入費用為 $0.50、輸出費用為 $2.50,而不是 $0.10 和 $0.50;cache reads 與 cache writes 也會計入這項門檻。

價格變動後仍然適用的計算方式

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

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, October 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 個輸入 tokens 並取得 400 個輸出 tokens 的請求,成本約為 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 小時就會用完。

圖表Estimated cost per 1,000 requests at 4,300 input and 400 output tokens
此圖表背後的資料
[
  {
    "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 token 的前綴在每次請求中都完全相同,而你每次都必須支付完整的輸入價格。Prompt caching 會儲存已處理的前綴,並以較低的費率收取重複使用費用。

在本頁價格表與範例使用的模型(Haiku 4.5、Sonnet 5、Sonnet 4.6 和 Opus 5)以及 Fable 5 中,cache read 的費用是基本輸入費率的 0.1 倍。部分較新的模型對 read 收費更低:Opus 5.5 和 Sonnet 5.5 收取 0.05 倍,Fable 5.1 和 Mythos 5.1 收取 0.025 倍。寫入 cache 的費用,在 5 minute lifetime 中是基本費率的 1.25 倍,在 1 hour lifetime 中是 2 倍。因此,對於費率為 0.1 倍的模型,5 minute cache 只要 read 1 次即可回本,因為寫入成本多出 0.25 倍,而每次 read 可節省 0.9 倍。1 hour cache 則需要 read 2 次才能回本。

啟用方式最簡單,只需加入 1 個頂層欄位:

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。啟用 caching 後,如果只讀取 input_tokens,成本估算會嚴重失準。

有 2 種情況會使 cache 無法發揮效益,而且 2 種情況都不會顯示錯誤。

前綴必須逐 byte 完全相同。 Cache lookup 會比對前綴,因此如果在 system prompt 開頭加入 timestamp 或使用者名稱,每次請求的前綴都會改變。如此一來,每次都必須支付基本輸入費率的 1.25 倍,且一次 cache read 都不會發生。其特徵是 cache_creation_input_tokens 維持高值,而 cache_read_input_tokens 維持 0。請將 cache_control 放在跨請求內容相同的最後一個區塊,並將所有會變動的內容放在其後。修改 tools definitions 會使其下方的整個 cache 失效,因為失效處理會依序向下套用到 tools、system,再到 messages。

前綴必須足夠長。 Opus 5 的最小 cacheable 長度是 512 tokens,Sonnet 5 是 1,024,Haiku 4.5 是 4,096。較短的 prompt 不會被 caching,也不會回傳錯誤。上例中的 4,000 token 前綴會在 Sonnet 5 上被 caching,但不會在 Haiku 4.5 上被 caching,因為 4,000 低於該模型的最低長度。當 2 個計數器都為 0 時,表示沒有內容被 caching。

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

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 會替你計算,而且不收費;這項計算使用的 rate limit 與訊息建立分開。

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 使用與訊息請求相同的 body,因此以 base64 傳送的圖片和 PDF 也能正確計算。它不接受 web search 和 web fetch 等 server tools,也不接受透過 URL 或 file reference 傳入的圖片或文件。有兩點需要注意。這個數量是估算值,可能與計費數字略有差異。此外,計算會使用你傳入之 model 的 tokenizer,因此應傳入實際執行時會使用的 model。

無法事先計算 output tokens,因為它們尚未產生。使用 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 是輸入還是輸出。截至 2026 年 10 月,在 Claude Haiku 4.5 上,1M 個輸入 tokens 的費用為 $1;在 Claude Sonnet 5 上為 $2;在 Claude Opus 5 上為 $5。較新的 Claude Haiku 5.5 對不超過 100,000 個 tokens 的提示,輸入費用自每 1M 個 tokens $0.10 起算;超過此數量後則為 $0.50。上述各模型的輸出費用都是輸入費率的 5 倍。費率會變動,因此在將數字編入預算前,請先在官方定價頁面確認。

1M 個 tokens 等於 1M 個單字嗎?

不是。在 Claude Opus 4.7 之前的模型中,Anthropic 表示 1 個 token 約包含 3.5 個英文字元,1M 個 tokens 約可容納 750,000 個單字。Claude Opus 4.7 及後續版本使用較新的 tokenizer,1M 個 tokens 約可容納 555,000 個單字,因為對相同文字而言,該 tokenizer 產生的 tokens 約比 Claude Sonnet 4.6 及更早版本多 30%。這些比例只能作為參考。程式碼、JSON 及英文以外的語言,每個單字使用的 tokens 會更多,而且不同模型世代之間的計數方式無法直接通用。請使用免費的 /v1/messages/count_tokens endpoint,並傳入預計執行的模型,以取得實際計數。

Prompt caching 是否一定能省錢?

不是。5 分鐘的快取寫入費用是基本輸入費率的 1.25 倍,因此寫入後從未讀取的前綴,費用會比直接傳送高 25%。只要讀取 1 次即可回本。它會以 2 種方式靜默失效。如果每次請求之間的快取前綴有所變更,查找就永遠不會相符,因為這是完全相同的前綴比對。如果前綴短於模型可快取的最小長度,Sonnet 5 為 1,024 個 tokens,Haiku 4.5 為 4,096 個 tokens,則不會快取任何內容,也不會傳回錯誤。當 cache_creation_input_tokens 與 cache_read_input_tokens 都是 0 時,表示快取沒有作用。

為什麼帳單增加的速度比訊息數量快?

因為每一輪都會重新傳送完整對話。Messages API 不會保留狀態,因此聊天進行到第 20 輪時,會再次將前 19 輪全部作為輸入傳送。若每輪平均 500 個 tokens,20 輪對話會傳送約 105,000 個輸入 tokens,但逐字稿長度只有 10,000 個 tokens。Agent 迴圈的情況相同,因為每個工具結果都會保留在歷史記錄中。請快取穩定的前綴,或摘要較早的對話輪次,並從請求中移除原始內容。

這篇文章對您有幫助嗎?