ByteScope

Claude Opus 5

Opus 5 的五條費率,以及對上 Sonnet 的 agent 迴圈。

價目表在這個分頁裡讀。不會上傳,也不會呼叫模型的 API。

最後更新 2026-09-22 來源

價目表

每百萬 token

Input,USD / 1M tokens
5 USD
Output,USD / 1M tokens
25 USD
Cache read,USD / 1M tokens
0.5 USD
Cache write,5 分鐘,USD / 1M tokens
6.25 USD
Cache write,1 小時,USD / 1M tokens
10 USD
Context 長度,tokens
1,000,000 tokens
Max output,tokens
128,000 tokens
Batch 係數
×0.5

算例

  • 0%$13.88 USD
  • 50%$8.13 USD
  • 90%$3.52 USD

和 Claude Sonnet 5 的差: 比 Claude Sonnet 5 多 $4.88. Claude Sonnet 5

其他模型

關於這個工具

Claude Opus 5

Opus 5 就是大家說「貴的那個 Claude」時指的卡。這站放在旁邊的是 Sonnet 5。有用的問題不是 input 那一條單獨看。50 輪的迴圈會一直重寫或重讀同一個 prefix,命中率一高,動到合計的是 cache read 和兩條 write,不是標題上的 input。沒有 long context 分段要記:整段 context 都是同一張表。batch 係數留在卡片上,不折進合計。batch 工作和一邊聊一邊跑的 session 不該看起來像同一筆採買。

這張卡怎麼計

這頁上的金額不是寫死在句子裡的。確認過的價目表只有一份,畫面上的數字要嘛從那份表讀出來,要嘛是全站同一支計價函式算出來的。情境是 agent-loop-50:50 輪、每輪都帶回來的可 cache context、每輪一點不會進 cache 的新 input,再加上每輪的 output。下面三個合計把 cache 命中率放在 0、一半、九成。命中率是那段重複 context 有多少是從 cache 讀回來,而不是再寫一次。它不是事後打折,也不是 batch 係數。價目上有 batch 係數的模型,這裡的合計故意不算進去,因為 batch 工作跟一輪一輪的互動是兩種買法。價目沒有某條 cache 的單價、情境卻還是要送那些 token 時,它們會按新的 input 計,結果上也會標出來。那是價目的性質,不是這頁漏做。有 long context 分段的卡片,只有單一次請求的 prompt 超過門檻才改走那段費率。這個 50 輪都很短,所以停在基本費率。因此就算模型有分段,迴圈合計仍然只有一組。對過價目的日子寫在下面的算例裡,對照的是旁邊連結的那個廠商價目頁。要換別的迴圈,母頁上還有另外三個情境和一根拉桿。

算例

這頁的單價是 2026-09-22 拿廠商的價目頁對過的。

cache 命中 0%:$13.88 cache 命中 50%:$8.13 cache 命中 90%:$3.52

和 Claude Sonnet 5 的差: 比 Claude Sonnet 5 多 $4.88.

常見問題

Claude Opus 5 這頁上的日期是什麼?

是跟價目頁對過的日子。不是模型發布的日子,也不是保證廠商之後沒有改數字。卡片一改,日期就跟著改。

Claude Opus 5 的價目上有哪些 cache 條?

這張卡有 cache read、5 分鐘 cache write、1 小時 cache write,還有 batch 係數。沒有 long context 分段,所以把 context 塞滿,跟短 prompt 走的是同樣五條。1 小時的 write 是另一個產品,不是把 5 分鐘那條拉長。

為什麼拿 Claude Sonnet 5 來比?

長迴圈會搬過去的是 Sonnet。五條一樣,兩邊都沒有 long context 分段。命中率高的時候那個差比較有意思,因為那時 write 不再主導合計。