Claude Opus 4.7 API 收費指南：$5/$25、Prompt Caching 同 Token 點計

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

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

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

成本公式：先分清有無 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。這只是按 Anthropic API input/output 單價做算術，不包括其他平台費用或供應商差異。

有 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 分開收費。

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。

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

送出後：用 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。

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

月結同團隊對帳：用 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。

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

升級到 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。

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

實務核對清單

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

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