Claude Opus 4.7 的標價看起來很直覺：input 每百萬 tokens $5、output 每百萬 tokens $25。但如果你的應用有長 system prompt、工具定義、PDF、圖片，或啟用了 prompt caching，只用「總 token 數 × 單一價格」很容易算錯。

Anthropic 表示，開發者可透過 Claude API 使用 model ID claude-opus-4-7；以下以 Anthropic API pricing 為準。第三方 pricing index 也列出 Claude Opus 4.7 的起始價格為每百萬 input tokens $5、output tokens $25，但若你是透過其他雲端或平台接入，仍應以該平台的實際帳單為準。^{[7][9][19][21]}

價格速覽：每百萬 token 不只一種價格

以下用 MTok 表示 1,000,000 tokens。Anthropic pricing 文件把 Base Input Tokens、Cache Writes、Cache Hits 與 Output Tokens 分開列示，因此實務上也應分項入帳。^[19]

收費項目	單價	怎麼理解
Base input tokens	$5 / MTok	一般送入模型、未按 cache write 或 cache 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]

重點是：不要把所有 token 混成同一包。Opus 4.7 的 input、output、cache write、cache read 單價不同；只要你的產品有使用 prompt caching，成本模型就應該拆開計算。^[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 成本，也方便在產品內設定預算上限、用量警示或拒絕過大的 request。^[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]