作者： Claude 輸入與輸出 token 成本差 5 倍
Claude 的輸出 token 價格是輸入的 5 倍。了解 prefill 與 decoding 的硬體差異，以及這種不對稱如何影響每月 agent 帳單。
為何輸出 token 的成本高於輸入 token
在目前目錄中的每個 Claude model 上，輸出 token 的成本都是輸入 token 的 5 倍。原因在於計算方式不同。讀取 prompt 只需對 model 執行一次處理。產生回覆則必須每個 token 處理一次，而且每次處理都要等待前一次完成。
價格表中的每一列都採用相同比率，因此選擇哪個 model，不會改變帳單中輸出的占比。這取決於工作負載的結構。某個 agent step 讀取 60,000 個 token，並以 800 個 token 回覆時，輸出成本幾乎可忽略。某個 drafting 工作讀取 2,000 個 token，並產生 12,000 個 token 時，輸入成本幾乎可忽略。以下將以 Anthropic 公布的 August 2026 費率，分別計算這兩種情況。
Prefill 執行一次，decoding 每個 token 執行一次
推論伺服器會分兩個階段處理請求，兩者的成本差異很大。Prefill 讀取提示。Decoding 產生回覆。
Prefill 一次處理完整提示。每個提示 token 都會在同一次 forward pass 中進入網路，因此 attention 與 feed-forward 的運算會轉換成少量大型矩陣乘法，每次涵蓋數千個 token。從記憶體讀取一次模型權重，就能處理完整提示。加速器的矩陣運算單元會持續忙碌，因此 prefill 受運算能力限制：瓶頸在於晶片執行矩陣乘法的速度。
Decoding 無法採用相同方式，因為 token 2 取決於 token 1。模型剛產生的 token 會成為下一個步驟的輸入，因此這些步驟無法同時執行。每個輸出 token 都需要獨立的 forward pass，而每次 pass 都會從高頻寬記憶體讀取完整模型權重，只產生一個 token。因此 decoding 受記憶體頻寬限制：瓶頸在於搬移權重的速度，而不是矩陣乘法的速度。Prefill 處理完整提示所需的相同權重流量，在 decoding 階段只能產生一個 token。
服務系統會透過 batching 來降低影響。多個請求會一起進行 decoding，因此讀取一次權重，就能為批次中的每個請求各產生一個 token。這也是 decoding 仍具備可接受成本的原因。瓶頸再次回到記憶體。每個處理中的請求都會保留 KV cache（key/value cache，儲存截至目前每個 token 的 attention 狀態）；該快取會隨產生的 token 增加而成長，當它填滿加速器後，批次就無法再擴大。
上述內容無法提供精確數字，也不應將 5x 解讀為實測的硬體比例。這是由 Anthropic 設定的價格，依據的是上述不對稱性。你可以自行確認的是方向，而且大約只需 1 分鐘。
自行測量輸入與輸出的差距
在任何 Ubuntu 主機上安裝工具：
sudo apt update && sudo apt install -y curl jq moreutils現在串流一個要求長篇回答的簡短提示，並為每一行加上抵達時間。
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s 會在每一行前加上自命令開始後經過的秒數。這段輸出有兩項資訊值得注意。第一個 content_block_delta 行代表第一個 token 的到達時間，所有 prefill 都在這一行內完成。之後的每一行都是一次小幅度的解碼，時間戳會持續增加，直到 message_stop 出現。
現在反轉這個形狀。在提示中放入長篇文件，並將回答限制為少量 token。
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'第一個時間差比使用簡短提示時更長，因為 prefill 必須讀取多得多的文字。第一個時間差出現後，回答幾乎立即結束，因為只剩少量 token 需要解碼。輸入了數萬個 token，但時鐘幾乎沒有變化。輸出了幾百個 token，時鐘卻持續運作。
每個非串流回應結尾都會列出計費依據的數值。
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}記錄每次請求的全部 4 個欄位。output_tokens 包含 extended thinking，因此模型在回答前進行思考時，這些思考內容會按照輸出速率計費。若要在傳送提示前估算費用，POST /v1/messages/count_tokens 可接受相同的請求本文，並在不執行模型的情況下回傳 {"input_tokens": N}，而且不收費。這不是 API 中唯一免費的部分；在編列第一個專案的預算前，值得確認 Claude API 中哪些部分不會向你收費。
Claude 截至 2026 年 8 月每 1 百萬個 token 的收費
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5 (to 31 Aug)",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Sonnet 5 (from 1 Sep)",
"input_usd": 3,
"output_usd": 15,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]最後一欄是輸出除以輸入，每一列都顯示 5。Haiku 4.5 的輸入費用為 $1，輸出費用為 $5。Opus 5 的輸入費用為 $5，輸出費用為 $25。最昂貴的 Fable 5，輸入費用為 $10，輸出費用為 $50；在否定最上方那一列前，值得先閱讀Fable 5 的這些費率能帶來什麼。沿著費率範圍往上移動時，輸入與輸出費用會以相同倍數增加。因此總費用會改變，但輸入與輸出的比例維持不變。
Sonnet 5 出現兩次，因為其優惠費率會到期。到 2026 年 8 月 31 日為止，輸入費用為 $2，輸出費用為 $10。自 2026 年 9 月 1 日起，適用輸入費用 $3 與輸出費用 $15 的標準費率，兩者都高出 50%。以下所有計算範例都使用 8 月費率。
費率會變動，因此不應在本頁查詢最新價格。claude.com/pricing 才是最準確的來源。價格變動後仍然適用的是計算方法。
價格表不會顯示一項注意事項。Anthropic 的文件指出，Claude 4.7 及更新版本的模型使用較新的 tokenizer。與 Sonnet 4.6 及更早版本使用的 tokenizer 相比，處理相同文字時，產生的 token 約多 30%。單看每 1 百萬個 token 的價格，會讓較新的模型看起來更划算，因為同一份文件在該模型上會產生更多 token。請比較完成實際工作所需的成本，並以實際打算使用的模型計算真實提示。不同服務提供者之間也有相同問題，而且它們的 tokenizer 差異甚至大於上述幅度。因此，在 Claude 和 ChatGPT 上分別計算實際工作的成本，比把兩張費率表並列比較更有參考價值。1 百萬個 Claude token 在實際文字中代表多少內容說明了這個數量在實務上的規模。
何時輸出會開始主導費用？
當輸出的計價是輸入的 5 倍時，很容易在心中算出損益平衡點。將輸入 token 設為 I，輸出 token 設為 O。輸入成本是 I。輸出成本是 5 倍的 O。當 5 倍的 O 大於 I 時，輸出成本會超過總支出的一半，token 比例就是輸入 5、輸出 1。
因此，如果提示的長度超過回覆的 5 倍，輸入就是較大的費用項目。低於這個比例時，則是輸出。
The data behind this chart
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]在 100 比 1 時，輸出占支出的 4.8%，此時只有縮短提示值得投入。在 5 比 1 時，兩者費用相同。在 1 比 6 時，輸出占 96.8%，提示成本則可視為四捨五入誤差。多數人都會錯估自己的比例，因此在進行任何最佳化之前，先從日誌中取得實際數據。
代理程式工作負載：輸入長內容，輸出短答案
執行一次檢索代理程式步驟：輸入 60,000 個檢索文件與對話記錄 token，輸出 800 個 token 的答案。這是 75 比 1。對於任何先讀取再寫入的工作負載，這都很常見。
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]在所有模型中，輸出量都占該次呼叫的 6.25%，因為整份價格表的比例固定。依序計算，該次呼叫在 Opus 5 的費用為 $0.32，在 8 月費率下使用 Sonnet 5 的費用為 $0.128，使用 Haiku 4.5 的費用為 $0.064。每天在 Opus 5 上執行 200 次這類步驟，每天的費用為 $64。
了解輸入與輸出的比例後，節省成本的著力點就很明顯。將答案從 800 個 token 縮短至 400 個，只能節省約 3% 的呼叫費用。從提示中移除 20,000 個過時的上下文 token，則可節省約三分之一。對於讀取量高的代理程式，限制輸出長度幾乎是白費力氣。深入了解程式撰寫代理程式的 token 實際用在何處說明了提示內容的主要來源。
生成工作負載：短提示、長草稿
現在反過來看。2,000 個 token 的簡述、12,000 個 token 的草稿，比例為 1 比 6。
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]輸出內容占這筆費用的 96.8%。Opus 5 每份草稿的費用為 $0.31，Haiku 4.5 則為 $0.062。這個 5 倍差距幾乎完全來自輸出端，而這正是較便宜的模型最能節省費用的地方。
最後一欄是透過 Batch API 執行相同工作，輸入與輸出費用都可減少 50%。Opus 5 每份草稿的費用降至 $0.155。Batch 會在 24 小時內回傳結果，而不是立即回傳，因此適合夜間報告產生與大量分類。不適合需要人員等待結果的工作。
模型路由在這裡很有價值，但在代理步驟中不會有同樣效果。如果工作的冗長部分是機械性處理，例如重新格式化文字或擴充已核准的大綱，較便宜的模型可用五分之一的價格產生這些 token。選擇 Opus、Sonnet 與 Haiku 說明品質界線實際位於何處。
快取只折抵輸入，且僅限輸入
Prompt caching 會將 prompt 的前綴儲存在伺服器上，之後再次讀取時，輸入費率只收取其中一部分。截至 August 2026，費率倍數為：寫入 5 minute 快取時收取基本輸入費率的 1.25x，寫入 1 hour 快取時收取 2x，命中快取並讀取時收取 0.1x。
輸出不包含在這項優惠中。不存在快取輸出。模型每次產生的每個 token 都會按照完整輸出費率計費，無論 prompt 有多少內容命中快取，規則都相同。
以 Opus 5 執行相同的 agent 步驟，其中 60,000 個輸入 token 有 55,000 個由 warm cache 提供。
The data behind this chart
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]這次呼叫的費用從 $0.32 降至 $0.0725。輸出費用沒有變動：原本為 $0.02，現在仍為 $0.02。快取會降低帳單金額，也會改變費用結構。輸出原本占這次呼叫的 6.25%。現在已超過四分之一，因此下一步應優先調整的項目也會不同。
第一次呼叫需要支付寫入費用。寫入 5 minute 快取的費用是基本輸入費率的 1.25x，因此命中一次後即可回本。寫入 1 hour 快取的費用是 2x，因此需要命中兩次。寫入與讀取倍數，以及快取何時不再划算會詳細說明這項計算。
你能控制的 4 個槓桿
- 將
max_tokens設定為輸出長度的 p95，而不是模型上限。 - 將冗長步驟路由至較便宜的模型。
- 將沒有人等待的工作批次處理。
- 刪除會讓回覆變長的指示。
max_tokens 是硬性上限。單獨提高這項設定不會增加費用，因為計費依產生的 token 計算，不會依上限計費。寬鬆的上限只會移除對異常回覆的限制。從日誌中取出 output_tokens 分布，將上限設在第 95 百分位稍上方，並在程式碼中處理 stop_reason: "max_tokens"，例如繼續產生回覆或重試。你偵測到的截斷，成本低於支付後丟棄一段 4,000 token 的冗長內容。Extended thinking 也會計入 output_tokens，因此應根據相同的資料設定該預算。
當步驟的昂貴部分是內容量而非判斷時，路由才有效。讓強大的模型負責決策，再把文字產生交給較便宜的模型。先在自己的評估資料集上測量路由版本，因為需要嘗試兩次的便宜模型，成本可能高於一次昂貴的嘗試。
批次處理是唯一能折抵輸出費用的槓桿。雙方費用均可折抵 50%，結果會在 24 小時內提供，任何有排程的工作都符合條件。
最後一個槓桿常被忽略。「be thorough」和「explain your reasoning」這類片語，會增加你往後每次呼叫的輸出長度。改成直接指定所需格式，例如「Answer in at most three sentences」，或「Return only the JSON object, with no preamble」。每次回覆增加 300 token 的 system prompt，其成本是相同 300 token 輸出成本的 5 倍。將持續執行的 agent 成本控制在範圍內涵蓋監控部分；在你花一週調整每個 token 的支出前，也值得先確認依你的使用模式判斷 API 或固定訂閱哪個較便宜，因為訂閱可能已涵蓋這些費用。對單一開發者而言，這主要取決於Claude Pro 每月 $20 的費用及其使用量限制是否足以支應原本需要按量計費的工作。如果你已在工作階段中途達到這些限制，應先確認你正在等待哪個使用量視窗；接著的解決方式可能是改用較小的模型、減少 context、購買額外使用量額度，或將工作移至按量計費的 API。如果按量計費的 API 最終成為較適合該工作的方案，降級至較小的方案或取消訂閱不會影響已支付的當月期間，因此切換時不會產生額外損失。如果你拿來與 Pro 比較的是 ChatGPT 方案，而不是按量計費的 API，將兩種訂閱層級並列比較價格可顯示哪一種對程式開發工作較便宜。如果這個問題是為團隊而非單一開發者提出，請注意Claude Enterprise 將每席位費用與依相同 API 費率計算的 token 費用結合；因此，本頁的每個槓桿仍適用於該帳單中按量計費的部分。
FAQ
為什麼輸出 token 的費用高於輸入 token？
因為每個 token 的生成需要更多加速器處理時間。提示會在一次前向傳播中完整處理，因此單次讀取模型權重就能涵蓋數千個 token，硬體瓶頸在乘法運算吞吐量。回覆則一次生成一個 token，每個 token 都需要重新執行一次前向傳播，並再次讀取完整模型權重，因此硬體瓶頸改為記憶體頻寬。Anthropic 目前整個產品目錄的輸出價格都是輸入價格的 5 倍，涵蓋 Haiku 4.5 到 Fable 5。
提示快取會讓輸出 token 變便宜嗎？
不會。提示快取只套用於輸入。截至 August 2026，快取讀取費用是基本輸入費率的 0.1 倍；快取寫入費用在 5 minute 期間是 1.25 倍，在 1 hour 期間是 2 倍。無論快取的狀態為何，每次呼叫都會按完整費率計算輸出費用。因此，快取不只會改變帳單金額，也會改變費用結構：當輸入端的費用大幅降低後，輸出就會成為最值得優化的部分。
如果回覆很短，較高的 max_tokens 會增加費用嗎？
不會。系統會依模型實際產生的 token 計費，因此 max_tokens 是上限，不是預先保留的額度。它仍然重要，因為這是限制失控回覆的唯一硬性上限。請將它設定在觀察到的 output_tokens 第 95 百分位數略高的位置，並在程式碼中處理 stop_reason: "max_tokens"，不要直接送出遭到無聲截斷的答案。
如何找出自己的輸入與輸出 token 比率？
請從每個回應的 usage 物件記錄 input_tokens、output_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，然後計算一週內的總和比率。若輸入與輸出的比率高於 5 比 1，主要費用來自提示，因此應快取穩定部分並精簡其餘內容。若低於此比率，主要費用來自回覆，因此應限制回覆長度，並將產生最多輸出的步驟移至較便宜的模型或 Batch API。