Claude Opus 4.7 的標價看似簡單，但如果把所有 token 當成同一種收費，成本很快會計錯。Anthropic 表示開發者可用 model ID claude-opus-4-7 經 Claude API 使用 Opus 4.7；以下收費以 Anthropic API pricing 為準，第三方 pricing index 亦列出相同的 $5 input / $25 output per million tokens 起點，但如果經其他平台接入，仍應查該平台的最終帳單。^{[7][9][19][21]}

價格速覽：不只係 $5 同 $25

本文用 MTok 表示 1,000,000 tokens。Anthropic pricing 文件將 Base Input Tokens、Cache Writes、Cache Hits 同 Output Tokens 分開列示，所以實務上亦應分開入帳。^[19]

收費項目	單價	點理解
Base input tokens	$5 / MTok	一般送入模型、未按 cache write/read 計的輸入 token。[19]
Output tokens	$25 / MTok	Claude 生成回覆時產生的輸出 token。[19]
Prompt cache write，5 分鐘 TTL	$6.25 / MTok	第一次寫入可重用 prompt cache，使用 5 分鐘 TTL 時適用。[19]
Prompt cache write，1 小時 TTL	$10 / MTok	使用 1 小時 TTL 寫入 prompt cache 時適用。[19]
Cache read / hit	$0.50 / MTok	命中已快取內容並讀取 cache 時適用。[19]

重點係：不要只用「總 tokens」乘一個平均價。Opus 4.7 的 input、output、cache write 同 cache read 單價不同；只要你的 app 有 prompt caching，成本模型就要把幾類 token 拆開。^[19]

成本公式：先分清有無 prompt caching

無 prompt caching

最基本公式係：

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

例如一次 request 有 200,000 input tokens 同 20,000 output tokens，未計 cache 時就是

$1.00 + $0.50 = $1.50

[19]

有 prompt caching

有 prompt caching 時，成本應改為逐項相加：

成本 = base_input_tokens ÷ 1,000,000 × 5 + output_tokens ÷ 1,000,000 × 25 + cache_write_5m_tokens ÷ 1,000,000 × 6.25 + cache_write_1h_tokens ÷ 1,000,000 × 10 + cache_read_input_tokens ÷ 1,000,000 × 0.50

如果你只使用一種 cache TTL，就只保留對應的 cache write 項。Anthropic streaming 文件的 usage example 顯示 usage 可包含 input_tokens、output_tokens、cache_creation_input_tokens 同 cache_read_input_tokens 等欄位；pricing 文件亦將 cache write 同 cache hit 分開收費。^[15][19]

Token 點計最清楚：送出前用 count_tokens

不要用中文字數、英文字數或大概 character count 去估 API 成本。Anthropic 的 /v1/messages/count_tokens endpoint 是用來在送出 message 前計算 token；文件指它接受與建立 message 類似的結構化輸入，包括 system prompts、tools、images 同 PDFs，並回傳 total input tokens；所有 active models 都支援 token counting。^[18]

最穩陣流程是：把實際會送入 Messages API 的 payload 直接送去 count_tokens，包括 system prompt、messages、tools、圖片或 PDF。這樣可以在真正呼叫模型前先估 input token 成本，亦方便你在產品內設定預算上限或預警。^[18]

送出後：用 response usage 做真實入帳

Request 完成後，應記錄 API response 入面的 usage，而不是再用輸出文字長度倒推。Anthropic 的 Messages API examples 顯示 response usage 可包含 input_tokens、output_tokens 等欄位；streaming 文件亦顯示 cache 相關欄位如 cache_creation_input_tokens 同 cache_read_input_tokens。^[15][17]

如果你用 streaming，要特別小心 dashboard 計法。Anthropic streaming docs 指出，message_delta 入面的 usage token counts 是累積值，不是每個 event 的新增量；如果逐個 delta 直接相加，就會把同一批 token 重複計入。^[15]

月結同團隊對帳：用 Usage & Cost Admin API

單次 response log 適合做即時監控，但團隊月結、workspace 分帳或長期成本分析，應再用 Anthropic 的 Usage & Cost Admin API。官方文件指這個 API 提供 programmatic、granular access to historical API usage and cost data，並可按 model、workspace、service tier 等維度拆分 usage report。^[16]

換句話講，app 端可以記錄每次 request 的 usage 做產品內成本控制；正式對帳時，仍應以 Usage & Cost Admin API 的歷史 usage/cost 資料作準。^[16]

升級到 Opus 4.7 前，要重跑 token budget

Opus 4.7 引入新 tokenizer。Anthropic 文件指出，新 tokenizer 處理文字時，可能使用約 1x 至 1.35x 於 previous models 的 token 數，最高約多 35%，而實際幅度會因內容而異；同一段 input 用 /v1/messages/count_tokens 在 Opus 4.7 同 Opus 4.6 會回傳不同 token number。^[20]

所以，「input $5/MTok、output $25/MTok」不等於升級後帳單一定不變。如果你由 Opus 4.6 或更早模型升級，應抽取高流量 prompt、長 context prompt、含 tool definitions 的 payload，以及最貴的 workflow，重新跑一次 /v1/messages/count_tokens，再更新 alert、rate limit 同成本上限。^[18][20]

實務核對清單

• 確認 API model ID 使用 claude-opus-4-7。^[9]
• 重要 release 前，用 /v1/messages/count_tokens 對代表性 payload 做預估。^[18]
• 把 input_tokens、output_tokens、cache write 同 cache read 分開入帳，不要只存一個 total token 數。^[15][19]
• 使用 streaming 時，記住 message_delta.usage 是累積值，不要逐個 event 重複相加。^[15]
• 團隊月結、workspace 分帳或歷史趨勢分析，使用 Usage & Cost Admin API。^[16]
• 由舊版 Claude model 升級到 Opus 4.7 前，重新測試 tokenizer 對實際 prompt 的影響。^[20]

總結：Claude Opus 4.7 的 API 基礎價不難記，input $5/MTok、output $25/MTok；真正要計準，就要在送出前用 count_tokens，送出後記錄 usage，並把 prompt caching 同新 tokenizer 的影響納入成本模型。^[18][19][20]