Claude 模型該選哪款？各版本價格與用途比較

我該使用哪款 Claude 模型？

關於該選擇哪款 Claude 模型的簡短答案：請從 Claude Opus 4.8 開始使用，除非有明確理由才更換模型。Anthropic 的建議亦同：「若不確定該使用哪款模型，針對複雜的 Agentic 編碼與企業級工作，請從 Claude Opus 4.8 開始。」當任務需求明確且每日執行次數頻繁時，請改用 Claude Sonnet 5。若為已知的機械式、高量工作，請改用 Claude Haiku 4.5。Claude Fable 5 則適用於需要長時間運行的 Agent。

選擇模型需支付相應費用。以下為 2026 年 7 月 23 日 Claude API (application programming interface) 每百萬 token（文件標記為 MTok）的費率。

• Claude Fable 5 (claude-fable-5)：輸入 $10 / MTok，輸出 $50 / MTok。1M context。
• Claude Opus 4.8 (claude-opus-4-8)：輸入 $5，輸出 $25。1M context。
• Claude Opus 4.7 (claude-opus-4-7)：輸入 $5，輸出 $25。1M context。
• Claude Sonnet 5 (claude-sonnet-5)：於 2026 年 8 月 31 日前享優惠價，輸入 $2，輸出 $10。2026 年 9 月 1 日起恢復標準費率 $3 輸入，$15 輸出。1M context。
• Claude Haiku 4.5 (claude-haiku-4-5)：輸入 $1，輸出 $5。200K context。

上述識別碼（identifiers）內容完整，不需額外附加內容。

1M-token 模型本身不收取額外費用：「900k-token 的請求與 9k-token 請求的每 token 費率相同。」

各個模型的實際用途

Anthropic 對於產品線的描述為每個模型提供一行說明，這些說明比任何排行榜都更具參考價值。

• Claude Fable 5：「適用於長期運作代理（agents）的次世代智慧。」在四個模型中延遲（latency）最慢。
• Claude Opus 4.8：「適用於複雜的代理編碼與企業工作。」延遲程度適中。
• Claude Sonnet 5：「速度與智慧的最佳結合。」速度快。
• Claude Haiku 4.5：「具備接近頂尖智慧的最快模型。」

Haiku 4.5 的限制也會在價格因素之前決定其是否適用。其 context window 為 200K tokens 而非 1M，因此無法容納大型程式碼庫或長篇代理對話紀錄。在 synchronous Messages API 上，其最大輸出為 64K tokens，而其他模型為 128K tokens；此外，其可靠的知識截止日期（knowledge cutoff）為 2025 年 2 月，而其他三個模型則為 2026 年 1 月。

實際工作負載下的成本差異為何？

該系列中的每個模型，其輸出費率皆為輸入費率的 5 倍。Opus 4.8 的費用為輸入每 1 美元，輸出每 5 美元。Haiku 4.5 的費用為輸入每 1 美元，輸出每 5 美元。此比例在整個產品線中皆一致，因此在產生大量輸出的工作任務中，選擇哪種模型至關重要。

Agentic 工作即屬於此類任務，因為思考 token 會被視為輸出 token 計費，且即使文字未傳送給使用者，仍會計入 max_tokens。在 Fable 5、Opus 4.8、Opus 4.7 與 Sonnet 5 中，預設會省略推理摘要，因此 thinking 欄位會回傳空值。計費方式保持不變：「無論如何，該區塊在多輪對話中的計費與回傳方式皆相同。」解析 Claude token 帳單的實際組成 詳細分析了該計費機制。

不同模型之間是否執行 thinking 功能有所不同，若忽略此點會導致成本測試結果錯誤。在 Sonnet 5 與 Fable 5 中，thinking 功能預設開啟，無需配置。在 Opus 4.8 與 Opus 4.7 中，除非在 request 中設定 thinking: {type: "adaptive"}，否則該功能為關閉狀態。在分析數據前，請確保兩端的配置一致。

為什麼最便宜的模型可能最昂貴

假設有一個獨立的程式碼任務。請求包含 60,000 tokens 的 context，模型產生的 output（包含 thinking）為 8,000 tokens。不使用 caching，因此計算方式如下。

在 Opus 4.8 上：0.06 MTok 的 input（單價 $5）為 $0.30，0.008 MTok 的 output（單價 $25）為 $0.20。單次嘗試成本為 $0.50。在 Haiku 4.5 上，同一次嘗試為 $0.06 加上 $0.04，總計 $0.10。

單次嘗試的成本，Haiku 比 Opus 便宜五倍，這看似節省了大量成本，直到你發現失敗嘗試所帶來的影響。讀取錯誤答案會消耗你的時間。在重試時，你會將錯誤答案作為 context 重新傳送，導致每次嘗試的規模都比前一次更大。當第三次嘗試仍失敗時，你最終仍會改用高級模型：Haiku 的 $0.30 加上 Opus 的 $0.50，總計 $0.80，比只執行一次 Opus 多花 60%。

因此，關鍵問題在於你檢查答案的成本有多低。若能在一秒內判斷答案錯誤，小模型非常划算。若判斷錯誤需要仔細閱讀 diff，小模型所消耗的時間將不會反映在帳單上，但卻增加了你的成本。

小模型具備絕對優勢的場景

在以下情況中，Haiku 4.5 是最佳選擇：

• 機械式子代理任務。執行重新命名檔案或收集搜尋結果的子代理不需要前沿推理能力。這是您 使用 Claude 建立 AI agent 並提供輔助工具後的標準模式。
• 日誌篩選。判斷一行內容是雜訊還是需要人工處理，屬於判斷範圍狹窄且失敗模式明確的任務。
• 對照固定標籤集進行分類。輸出內容短小，且準確度可透過樣本進行量化。
• 高量產能的 API 調用。當每日執行量達 100,000 次時，單個 token 的成本差異將不再是微不足道的誤差。這常見於 整合至 n8n 的 AI workflows。
• 任何對使用者回應速度有要求的場景。Haiku 4.5 是該系列中速度最快的模型。

Haiku 有一項特定的限制。其可快取提示詞（cacheable prompt）的最小門檻為 4,096 tokens，而 Opus 4.8 與 Sonnet 5 僅需 1,024 tokens。若低於此最小值，「任何少於此數量的 token 快取請求將在不進行快取的情況下處理，且不會回傳錯誤」。一個在 Sonnet 5 上能靜默快取的 1,500-token 指令區塊，在 Haiku 4.5 上則無法快取。判斷依據是 cache_creation_input_tokens 與 cache_read_input_tokens 皆為 0，這與其他無法快取的原因一樣，是 降低持續運行 agent 成本 時必須考慮的因素。

影響結果的變數

這些變數對帳單金額的影響程度，比模型名稱更顯著。

Effort。 output_config.effort 控制模型在回答前進行的運算量。等級包含 low、medium、high、xhigh 與 max，預設值為 high：「將 effort 設為 high 的行為，與完全省略 effort 參數完全相同。」此參數嵌套於 output_config 之中，而非位於請求的最上層：

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=messages,
)

Effort 會影響回應中的每一個 token：「它會影響包含 tool calls 在內的所有 token 消耗。例如，較低的 effort 會導致 Claude 進行較少的 tool calls。」這會對 agentic loop 產生複利效應。它並非 token 上限：「Effort 是一種行為訊號，而非嚴格的 token 預算。」Anthropic 並未公布各等級的成本倍率，建議自行測試使用情境。因此，您可以在今天下午直接比較在 high 下運行的 Sonnet 5 與在 low 下運行的 Opus 4.8。Haiku 4.5 不在支援 effort 的模型清單中。

Prompt caching。 讀取快取的成本僅為基礎輸入費率的 0.1x，而決定模型選擇的關鍵，在於各層級間的成本差異。Opus 4.8 的快取命中成本為 $0.50 / MTok，而 Haiku 4.5 的非快取輸入成本為 $1 / MTok；因此，針對已良好快取的 Opus 前綴，其單個輸入 token 的成本比未快取的 Haiku prompt 更低。對於需要重複傳送大型穩定前綴的工作負載，維持 Session hygiene 比選擇模型更有效。

Batches。 若不要求即時回應，Message Batches API 會以「輸入與輸出 token 皆享 50% 折扣」的條件執行相同的模型。這會使下方比較表中的每一行數值減半，且適用於所有層級：自 2026 年 9 月 1 日起，以標準價格計算，一個批次處理的 Opus 4.8 任務成本會低於同步執行的 Sonnet 5 任務，這是在相同的預算下，以延遲換取效能。

單次作業成本比較

工作負載：分類 100,000 封支援郵件。每次呼叫包含 2,000 個 input tokens 與 300 個 output tokens。總計為 200 MTok input 與 30 MTok output。

• Haiku 4.5：200 x $1 = $200 (in)，30 x $5 = $150 (out)。總計 $350。
• Sonnet 5 (入門價格)：200 x $2 = $400 (in)，30 x $10 = $300 (out)。總計 $700。
• Sonnet 5 (2026 年 9 月 1 日起)：200 x $3 = $600 (in)，30 x $15 = $450 (out)。總計 $1,050。
• Opus 4.8：200 x $5 = $1,000 (in)，30 x $25 = $750 (out)。總計 $1,750.

若要使用明日的價格重新計算，請更換四個數值。下述調整對結果的影響程度超過模型名稱本身的差異：

• 使用 Batching 可使每行成本減半：分別為 $175、$350、$525 與 $875。由於夜間分類作業無需等待，因此建議使用此功能。
• 快取 (Caching) 共享前綴：假設 2,000 個 input tokens 中有 1,200 個是重複的指令區塊。以入門價格的 Sonnet 5 為例，快取命中 (cache hits) 的成本為 $0.20 / MTok，而非 $2 / MTok；因此 120 MTok 的成本為 $24 而非 $240。加上 80 MTok 的新輸入成本 ($2/MTok = $160) 與 $300 的輸出成本，Sonnet 5 的總成本會從 $700 降至約 $484。此方法對 Haiku 4.5 無效，因為 1,200 tokens 低於其 4,096-token 的最低門檻。
• 重試 (Retries)：假設您拒絕了 8% 的 Haiku 回答，並使用 Opus 4.8 重新執行。在 $350 的基礎上加上 0.08 x $1,750 = $140，總計為 $490。請根據實際的拒絕率進行計算，而非直接套用本例數值。
• 若工作流程包含 Tool definitions：在 Opus 4.8 上，當 tool_choice 設定為 auto 時，產生的 system prompt 為 290 tokens；Sonnet 5 為 354 tokens；Haiku 4.5 為 496 tokens。最便宜的模型反而具有最高的固定開銷。

採用升級路徑 (escalation path) 的 Haiku ($490) 與使用快取的 Sonnet 5 ($484) 成本幾乎相同，且其中一個模型只需單次作業即可完成任務。模型本身並非問題的核心。

在對話中途切換模型可以節省成本嗎？

實際節省的金額通常低於標價所示，因為節省是以 token 為單位計算，而你面臨的風險是整個已快取的前綴 (cached prefix)。

Anthropic 有說明哪些因素會使快取失效。前綴是依序建立 tools、system 與 messages，且「每一層級的變動都會導致該層級及其後續所有層級失效」。清單中還包含兩項請求設定：「thinking configuration 與解析後的 effort 層級會被寫入 prompt 本身，因此變更其中任何一項都會啟動新的快取前綴」。官方文件進一步建議：「應針對不同工作負載調整 effort，而非在依賴快取命中 (cache hits) 的單次對話中進行變更」。

模型並不在該說明清單中，因此請勿預設其結果。請在切換後的第一次請求後查看 cache_read_input_tokens，以數據作為判斷依據。以 150,000-token 的 Opus 4.8 前綴為例，快取讀取成本約為 $0.08，而全新寫入成本約為 $0.94，這遠高於你試圖透過 token 價差所節省的數次對話成本。

因此，請在任務之間變更這些設定，而非在單一任務內部變更。在 Claude Code 中，這代表應先進行 /clear（因為快取本來就會被捨棄），接著再進行 /model 或 /effort。

如何針對您的工作負載測試答案

請勿使用不同模型的計數結果來估算 prompt 大小。token 計數 endpoint 可免費使用，且會根據您指定的模型使用對應的 tokenizer，因此請指定您預計呼叫的模型。Opus 4.7 及之後版本、Fable 5 與 Sonnet 5 使用較新的 tokenizer，對於相同的文本，「產生的 token 數量約增加 30%」，因此在舊模型上測得的預算，在每 token 單價不變的情況下，應用於新模型時會顯得不足。

接著請檢查回傳結果。input_tokens 僅為未快取（uncached）的剩餘部分，因此真正的 prompt 大小為該欄位加上 cache_creation_input_tokens 與 cache_read_input_tokens。在 VPS 上建立第一個 Claude API 應用程式 是進行此項測量最精確的環境，而 哪種 Claude 方案符合您的使用需求 則是關於是否採用按 token 計費的獨立決策。

FAQ

哪款 Claude 模型最適合程式開發？

截至 2026 年 7 月，Claude Opus 4.8 是執行複雜 Agentic 程式開發的基準模型，輸入與輸出成本分別為每百萬 token $5 與 $25。Claude Sonnet 5 在速度與智慧度之間取得了最佳平衡；在 2026 年 8 月 31 日前，其成本僅為 Sonnet 5 的一半以下（$2 / $10）。請在保持 thinking configuration 不變的情況下，對兩者執行相同任務，並從 response.usage 比較總體 token 消耗。

Claude Haiku 4.5 的成本低到足以取代 Sonnet 5 嗎？

以單一 token 而言，答案是肯定的：在優惠價格下，Haiku 4.5 為 $1 / $5，而 Sonnet 5 為 $2 / $10；自 2026 年 9 月 1 日起則為 $3 / $15。決定因素在於限制條件。Haiku 4.5 的 context window 為 200K token 而非 1M；在 synchronous Messages API 上，最大輸出為 64K；其知識截止日期為 2025 年 2 月；不支援 output_config.effort；且最小可快取 prompt 為 4,096 token，這會導致短系統 prompt 無法進行 caching。

在對話中途切換至較便宜的 Claude 模型可以省錢嗎？

效果不如預期。Anthropic 將 cache invalidators 定義為：tools、system 或 messages 前綴的變動、thinking configuration 的變動，以及 output_config.effort 的變動。模型切換對現有 cache 的影響尚未有官方文件說明，因此請將其視為未知狀態，並在隨後的第一次請求時閱讀 cache_read_input_tokens。這點非常重要：對於 150,000-token 的 Opus 4.8 前綴，一次 cache read 成本約為 $0.08，而一次 fresh write 成本約為 $0.94，這會抵銷掉多次單一 token 節省下來的成本。建議在 Claude Code 執行 /clear 之後，於任務切換時進行切換，因為屆時 cache 本來就會被捨棄。

output_config.effort 會如何影響帳單？

它會改變模型在文字、tool calls 與 thinking 消耗的 token 數量。較低的 effort 會減少 tool calls，這會對 agentic loops 產生連鎖反應，因為每個 tool result 都會在後續的 turns 中被重新傳送。等級包含 low、medium、high、xhigh 與 max，預設值為 high。Anthropic 並未公布各等級的成本乘數，而是將 effort 視為行為訊號而非 token 預算，因此請根據自身任務自行測試。

使用 Claude Batches API 可以節省多少費用？

透過改用非同步交付（asynchronous delivery），輸入與輸出 token 均可節省 50%。截至 2026 年 7 月，Opus 4.8 的批次成本為 $2.50 / $12.50，Sonnet 5 在優惠價格下為 $1 / $5，Haiku 4.5 為 $0.50 / $2.50。值得注意的對比是：自 2026 年 9 月 1 日起，一個批次的 Opus 4.8 任務成本會低於標準費率下的同步 Sonnet 5 任務，因此使用 batching 可以用相同的預算換取更強大的模型。