Claude 輸出 token 為何比輸入貴 5 倍？

為何輸出 token 的成本高於輸入 token

在目前型錄中的所有 Claude 模型上，輸出 token 的費用都是輸入 token 的 5 倍。原因在於計算方式不同。讀取 prompt 只需對模型執行一次運算。產生回覆則必須每個 token 執行一次運算，而且每次運算都必須等待前一次完成。

這個比例適用於價目表的每一列，因此選擇哪個模型，不會改變帳單中輸出的占比。真正決定這項比例的是工作負載的形態。某個 agent 步驟讀取 60,000 個 token，並以 800 個 token 回覆，輸出成本幾乎為零。某項草稿工作讀取 2,000 個 token，並寫入 12,000 個 token，輸入成本幾乎為零。以下將根據 Anthropic 公布的 August 2026 費率，分別計算這兩種情況。

Prefill 只執行一次，decoding 每個 token 執行一次

推論伺服器會分兩個階段處理請求，而這兩個階段的成本差異很大。Prefill 讀取 prompt。Decoding 產生回覆。

Prefill 一次處理整個 prompt。所有 prompt token 都在同一個 forward pass 中進入網路，因此 attention 與 feed-forward 的運算會變成少量的大型矩陣乘法，每次涵蓋數千個 token。模型權重只需從記憶體讀取一次，就能處理整個 prompt。加速器的矩陣運算單元會持續忙碌，因此 prefill 受計算能力限制：瓶頸在於晶片執行矩陣乘法的速度。

Decoding 無法採用相同方式，因為 token 2 取決於 token 1。模型剛產生的 token 會成為下一個步驟的輸入，因此這些步驟無法同時執行。每個輸出 token 都需要獨立的 forward pass，而每次 pass 都會從高頻寬記憶體讀取完整的模型權重，只產生單一 token。因此 decoding 受記憶體頻寬限制：瓶頸在於搬移權重的速度，而不是矩陣乘法的速度。Prefill 處理完整 prompt 所需的相同權重流量，在 decoding 階段只能換取 1 個 token。

服務系統會透過 batching 降低這項成本。多個請求會同時進行 decoding，因此讀取一次權重，就能為 batch 中的每個請求各產生 1 個 token。這就是 decoding 仍具備可接受成本的原因。瓶頸再次回到記憶體。每個處理中的請求都會保留 KV cache（key/value cache，也就是目前每個 token 的 attention 狀態），而且這個 cache 會隨著產生的 token 增加。當 cache 填滿加速器後，batch 就無法再擴大。

上述內容無法提供精確數字，也不應將 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 月每 100 萬個 token 的費用

[
  {
    "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；對相同文字，其產生的 token 數量約比 Sonnet 4.6 及更早版本所用的 tokenizer 多 30%。如果只比較每 100 萬個 token 的價格，會讓較新的模型看起來比較划算，因為相同文件在該模型上會產生更多 token。請比較完成單項工作的實際成本，並以實際計畫使用的模型計算真實提示詞。Claude 的 100 萬個 token 在實際文字中代表多少會說明這個數量在實務上的規模。

何時輸出會開始主導費用？

當輸出的定價是輸入的 5 倍時，損益平衡點很容易記住。將輸入 token 數稱為 I，輸出 token 數稱為 O。輸入成本為 I。輸出成本為 5 乘以 O。當 5 乘以 O 大於 I 時，輸出會占總支出的一半以上；對應的 token 比例是輸入 5、輸出 1。

因此，如果提示詞長度超過回覆的 5 倍，輸入就是較大的費用項目。低於這個比例時，則是輸出占比較高。

[
  {
    "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；對於先讀取再寫入的工作，這是正常情況。

[
  {
    "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，依 August 的費率計算，在 Sonnet 5 上為 $0.128，在 Haiku 4.5 上為 $0.064。每天在 Opus 5 上執行 200 次這類步驟，成本為每天 $64。

看出輸入與輸出的比例後，最有效的調整方向很明顯。將答案從 800 token 縮短至 400 token，只能節省約 3% 的呼叫成本。從提示中移除 20,000 token 的過時上下文，則可節省約三分之一。對於以讀取為主的代理，嚴格限制輸出長度幾乎沒有實質效益。程式設計代理的 token 實際用在哪裡會拆解提示內容的主要來源。

生成工作負載：提示詞短、草稿長

現在反過來看這種結構。簡要說明有 2,000 個 token，草稿有 12,000 個 token，比例為 1 比 6。

[
  {
    "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 小時內傳回結果，而不是立即傳回，因此適合夜間報告產生與大量分類。不適合有人必須坐等結果的工作。

在這裡，模型路由能帶來 agent 步驟無法帶來的效益。如果工作中較冗長的部分屬於機械性操作，例如重新格式化文字，或擴充已核准的大綱，低成本模型可以用五分之一的價格產生這些 token。選擇 Opus、Sonnet 與 Haiku 說明了品質界線實際位於何處。

快取折扣只適用於輸入，不適用於輸出

Prompt caching 會將 prompt 的前綴儲存在伺服器上，之後再次讀取時，按照輸入費率的一小部分計費。截至 2026 年 8 月，費率倍數如下：寫入 5 分鐘快取為基本輸入費率的 1.25x，寫入 1 小時快取為 2x，讀取命中快取則為 0.1x。

輸出不包含在這項計費安排中。不存在快取輸出。模型每次產生的每個 token 都會按照完整輸出費率計費，不論 prompt 有多少內容命中快取。

以 Opus 5 執行相同的 agent 步驟，其中 60,000 個輸入 token 有 55,000 個由有效快取提供。

[
  {
    "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 分鐘快取的寫入費用是基本輸入費率的 1.25x，因此命中一次後即可回本。1 小時快取的寫入費用為 2x，因此需要命中兩次才能回本。寫入與讀取倍數，以及快取何時不再划算會詳細說明這項計算。

你可以控制的4個槓桿

1. 將 max_tokens 設在輸出長度的 p95，而不是模型上限。
2. 將冗長步驟轉送給較便宜的模型。
3. 將沒有人等待的工作批次處理。
4. 刪除會讓回覆變長的指示。

max_tokens 是硬性上限。單獨提高這項設定不會增加費用，因為計費依據是實際產生的 token，不會對上限計費。較寬鬆的上限只會移除回覆失控時的限制。從日誌中取出 output_tokens 分布，將上限設在第95百分位稍上方，並在程式碼中處理 stop_reason: "max_tokens"，例如繼續產生回覆或重試。偵測到的截斷成本，低於支付並丟棄一段4,000 token 的冗長回覆。Extended thinking 也會計入 output_tokens，因此應根據相同的資料設定該預算。

當步驟的高成本主要來自處理量，而不是判斷品質時，路由才有效。讓能力較強的模型負責決策，再將文字輸入交給較便宜的模型。先在自己的評估資料集上測量路由後的版本，因為需要嘗試兩次的便宜模型，成本可能高於一次昂貴的嘗試。

批次處理是唯一能降低輸出費用的槓桿。雙方都可享有50%折扣，結果會在24小時內提供；任何依排程執行的工作都符合資格。

最後一個槓桿最容易被忽略。「務必詳盡」和「解釋你的推理」等句子，會增加你今後每次呼叫的輸出長度。改用明確指定格式的指示，例如「最多以三個句子回答」，或「只回傳 JSON 物件，不要加前言」。如果 system prompt 讓每次回覆增加300個 token，其成本會是相同300個 token 輸入成本的5倍。持續控管執行中 agent 的成本涵蓋監控部分；在你花一週調整每 token 費用前，也值得先確定對你的使用模式而言 API 或固定訂閱哪個較便宜，因為訂閱可能已涵蓋這些費用。對單一開發者而言，關鍵通常在於Claude Pro 每月 $20 以及隨附的使用量限制是否足以涵蓋原本需要按量計費的工作。如果你已在工作階段中途達到這些限制，應先釐清你正在等待哪個使用量視窗，因為接下來的解決方式可能是改用較小的模型、減少上下文、增加使用量額度，或將工作移至按量計費的 API。如果按量計費的 API 最終成為這項工作的較便宜選擇，降級至較小的方案或取消方案不會影響你已支付的當月期間，因此切換時不會產生額外損失。如果你拿來與 Pro 比較的方案是 ChatGPT 的方案，而不是按量計費的 API，並列比較兩條訂閱方案的價格可顯示哪一個對程式開發工作較便宜。如果這個問題是針對團隊而不是單一開發者，請注意Claude Enterprise 將每個席位的費用與依相同 API 費率計算的 token 費用結合，因此本頁的每個槓桿仍適用於該帳單中按量計費的部分。

FAQ

為什麼 output tokens 比 input tokens 昂貴？

生成 output tokens 每個 token 需要更多 accelerator 處理時間。處理 prompt 時，模型會在一次 forward pass 中讀取完整內容，因此單次讀取 model weights 就能涵蓋數千個 tokens，硬體瓶頸在 multiply throughput。生成 reply 時，模型一次產生一個 token，每個 token 都需要重新執行一次 forward pass，並再次讀取完整的 model weights，因此硬體瓶頸會轉為 memory bandwidth。Anthropic 目前整個產品目錄的 output 定價都是 input 的 5 倍，涵蓋 Haiku 4.5 至 Fable 5。

Prompt caching 會讓 output tokens 變便宜嗎？

不會。Prompt caching 只適用於 input。截至 August 2026，cache read 的費用是 base input rate 的 0.1x；cache write 在 5 minute duration 下為 1.25x，在 1 hour duration 下為 2x。無論 cache 的處理結果為何，每次呼叫都會以完整費率計算 output。這就是為什麼 caching 不只會改變帳單金額，也會改變帳單結構：當 input 端的費用大幅下降後，output 就會成為最值得降低成本的部分。

如果 reply 很短，較高的 max_tokens 會增加費用嗎？

不會。系統會依模型實際產生的 tokens 計費，因此 max_tokens 是上限，不是預先保留的額度。它仍然很重要，因為這是限制 reply 無限制延長的唯一硬性上限。將它設定為略高於實際觀測到的 output_tokens 第 95 百分位，然後在程式碼中處理 stop_reason: "max_tokens"，不要直接傳送遭到無提示截斷的答案。

如何找出自己的 input to output token ratio？

從每個 response 的 usage object 記錄 input_tokens、output_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，再計算一週內的總和比例。若 input 與 output 的比例高於 5 比 1，成本主要來自 prompt，因此應快取穩定部分並刪減其餘內容。若比例低於 5 比 1，成本主要來自 reply，因此應限制其長度，並將最耗用 tokens 的生成步驟移至較便宜的 model 或 Batch API。