Claude Opus 4.7 API 成本試算：長文件、長對話同批量任務點預算

Claude Opus 4.7 API 預算，最易計錯嘅位唔係單次 request 幾多錢，而係你會唔會每一輪都將同一份長文件、同一大段對話歷史重新送入模型。短 prompt 可能幾毫子都唔使；但一去到幾十萬 tokens 嘅文件、客服長對話、agent 工作流，成本可以好快放大。

Anthropic 表示開發者可以經 Claude API 使用 claude-opus-4-7；以下試算只採用 Claude API 公開定價，不包括企業合約、雲端平台端點、第三方 routing、稅項或匯率差異。 所有金額均以美元計。

先搞清楚：MTok 即係每百萬 tokens

Claude API 定價文件以每百萬 tokens，即 MTok，列出 Claude Opus 4.7 嘅 base input、output 同 prompt caching 價格。

唔用 cache 時，基本公式好直接：

成本 = input_tokens / 1,000,000 × 5
     + output_tokens / 1,000,000 × 25

如果用 prompt caching，就唔可以再將所有 input 混埋一齊計。你要將可重用上下文拆出嚟：第一次寫入 5 分鐘 cache 嘅部分按 $6.25/MTok；第一次寫入 1 小時 cache 嘅部分按 $10/MTok；之後 cache hit / refresh 按 $0.50/MTok。未被快取嘅新問題、新訊息仍然按一般 input 價格計，模型輸出仍然按 output 價格計。

一次過長文件分析：直接用 input + output

如果一份文件只分析一次，例如上載一份報告叫模型摘要，之後冇追問，預算可以好簡單：文件、system prompt 同問題都算 input tokens；模型答案算 output tokens。以下全部用 Claude API 公開價試算。

以 300k input + 8k output 為例：

300,000 / 1,000,000 × 5  = 1.50
8,000 / 1,000,000 × 25   = 0.20
合計                       = 1.70 美元

不過，如果你係由舊模型遷移去 Opus 4.7，唔好照抄舊 token 估算。Anthropic 定價文件註明 Opus 4.7 使用新 tokenizer，同一段固定文字嘅 token 數最多可能增加 35%。

例如原本估 300k input，保守啲可以先當 405k input；再配 8k output：

405,000 / 1,000,000 × 5  = 2.025
8,000 / 1,000,000 × 25   = 0.20
合計                       ≈ 2.23 美元

同一份長文件反覆問答：cache 先係分水嶺

長文件產品最常低估嘅成本，往往唔係模型回覆，而係同一份大文件喺每輪對話都被當成 input 重新計費。只要同一份文件會被查問多次，就應該一開始將 prompt caching 放入預算模型。

假設：

• 文件：300k tokens
• 每次新問題：2k tokens
• 每次回答：2k output tokens
• 使用 5 分鐘 prompt cache

呢個例子入面，第一輪建立 cache 其實比唔用 cache 貴少少；但只要同一份文件去到第二輪，總成本已經低過每次重送全文：

唔用 cache，兩輪：約 1.56 × 2 = 3.12 美元
用 5 分鐘 cache，兩輪：約 1.935 + 0.21 = 2.145 美元

所以長文件問答真正要睇嘅係 cache hit rate：用戶會唔會真係反覆問同一份文件？追問係咪喺 cache 有效期內？每一輪會唔會又帶入大量未快取嘅新內容？呢幾樣，往往比單次 output 長短更影響帳單。

長對話預算：歷史訊息唔好輪輪全價重計

長對話同長文件邏輯一樣。如果應用每輪都將大量歷史訊息塞返入模型，input 成本會一路疊。穩定、可重用嘅歷史上下文，應該優先評估 prompt caching。

假設：

• 歷史對話：200k tokens
• 每輪新訊息：1k tokens
• 每輪輸出：2k tokens

揀 5 分鐘定 1 小時 cache，唔應該只睇寫入單價，而要睇用戶行為：

• 用戶通常會喺 5 分鐘內連續追問：可以先估 5 分鐘 cache。
• 用戶成日隔超過 5 分鐘先返嚟，但多數 1 小時內繼續：1 小時 cache 第一次寫入較貴，但可能減少失效後重建。
• 回覆間隔好飄忽：先用真實流量抽樣，量 cache hit rate，再調整架構。

批量任務：未確認折扣前，先用同步公開價保守估

批量任務常見於離線分析、資料標註、批量摘要或者大量分類。不過，喺你未確認自己帳戶、合約或者平台端點實際適用嘅 batch pricing 前，正式預算唔應該先寫入未核實折扣。保守做法係先按同步 API 公開價估，再用已確認嘅批量價格下修。

同步公開價公式仍然係：

總成本 = 總 input tokens / 1,000,000 × 5
       + 總 output tokens / 1,000,000 × 25

例：10,000 筆任務，每筆 2k input + 500 output。

總 input  = 10,000 × 2,000 = 20,000,000 tokens
總 output = 10,000 × 500   = 5,000,000 tokens

input 成本  = 20 × 5  = 100 美元
output 成本 = 5 × 25  = 125 美元
合計         = 225 美元

即係話，$225 係未計任何 batch discount 嘅保守同步價估算。之後如果確認有適用批量價，只要將單價換成實際價格再計一次。

另外，如果你唔係直連 Anthropic Claude API，而係經雲端平台或者第三方模型路由商，實際帳單可能唔同。第三方資料 CloudPrice 列出 Opus 4.7 喺 Anthropic / global 類型為 $5 input / $25 output per MTok，亦列出部分 AWS Bedrock 區域型代碼為 $5.50 input / $27.50 output per MTok；呢類資料適合做採購前提示，正式落單仍應以你自己平台帳務頁、合約同官方文件為準。

實務 buffer：唔好只拎理論數字去簽 budget

如果你未有真實 token 分布，只用理論值通常會偏樂觀。至少要加三個安全墊：

1. Tokenizer 遷移風險：Opus 4.7 新 tokenizer 可能令固定文字 token 數最多增加 35%。
2. Cache hit rate 不確定：cache 只有喺上下文真係被重複使用、而且仍然喺有效期內，先會明顯慳錢。
3. 真實用戶行為：用戶可能要求更長輸出、反覆重試、上載更大文件，或者令對話歷史超出你原本假設。

可用嘅非官方預算安全墊如下：

以上係預算管理上嘅保守抓法，唔係 Anthropic 官方報價。正式上線後，應該用實際 token 日誌、cache hit rate 同發票資料回填模型，唔好長期靠估。

可直接拎去用嘅月費模板

冇 cache 時，可以先用月成本公式：

月成本 ≈ 每日請求數 × 30
       × (平均 input tokens / 1,000,000 × 5
          + 平均 output tokens / 1,000,000 × 25)

有 cache 時，務必要拆開計：

月成本 ≈ 一般 input 成本
       + cache write 成本
       + cache hit / refresh 成本
       + output 成本

實作前，最少填入以下變數：

結論：實際應該點落預算

一次性長文件分析，可以直接用 $5/MTok input + $25/MTok output 估算。

同一份長文件反覆問答，或者長對話每輪都帶大量歷史，就要先試算 prompt caching。在 300k 文件、2k 問題、2k 輸出嘅例子中，5 分鐘 cache 第二輪命中約 $0.21；如果每次重送全文，則約 $1.56。

批量任務就先用同步 API 公開價抓保守預算，等你確認實際 batch pricing、雲端平台價或者合約單價後再下修。若然係由舊模型遷移到 Opus 4.7，建議先將 input token 預估乘上最高 1.35，再加營運 buffer；咁會比只睇標價更接近真實帳單。