模型升級時，不能只看「每百萬 token 單價有沒有變」。在大型語言模型 API 裡，tokenizer（分詞器）會先把文字切成模型可處理的 token；而 token 數，正是多家 LLM API 定價文件中的核心計費單位之一。^{[20][12][32][2]}

Claude Opus 4.7 是一個很具代表性的例子。Anthropic 文件明確寫道，Claude Opus 4.7 的新 tokenizer 在處理文字時，可能比先前模型使用約 1x 至 1.35x 的 tokens，也就是最高約多 35%，且增幅會因內容而異；同一份輸入如果用 /v1/messages/count_tokens 比較 Opus 4.7 與 Opus 4.6，會得到不同的 token 數。^[34]

先講結論：可能變貴，但不是每個 prompt 都加 35%

最準確的說法是：新 tokenizer 可能讓同一份 prompt 的 input tokens 增加；在 input-token 單價不變的情況下，input 成本就可能被推高。

但這不應被簡化成「Opus 4.7 讓所有 prompt 一律貴 35%」。Anthropic 說的是約 1x–1.35x，而且明確指出會依內容變動；有些內容可能接近不變，有些內容才可能接近上限。^[34]

也不能把 token 增幅直接等同於整張帳單的漲幅。Anthropic pricing 文件把

Base Input Tokens

Cache Writes

Cache Hits

Output Tokens

[12]

[32]

[2]

[12]

為什麼同一段文字會變成不同 token 數？

token 不是字數，也不等於中文字數或英文字數。OpenAI 的 tiktoken 教程示範，必須使用指定 encoding，才能計算一段文字會被拆成多少 tokens；Gemini 文件也寫明，Gemini API 的 input 與 output 都會被 tokenized，包含文字、圖像等輸入。^[20][1]

因此，只用字數、字元數或固定比例估算成本，最多只能做粗略預算。真正該比較的是「目標模型實際回傳的 token count」。Claude Opus 4.7 與 Opus 4.6 在 count_tokens 上會回傳不同數字，正好說明 tokenizer 改動會改變同一內容的計數結果。^[34]

「最高約 35%」應該怎麼解讀？

常見說法	較準確的解讀
Opus 4.7 讓 prompt 一律貴 35%	過度簡化。官方範圍是約 1x–1.35x tokens，而且依內容而異。[34]
同一段文字可能被計成更多 tokens	準確。Anthropic 明確表示 Opus 4.7 的新 tokenizer 可能使用更多 tokens，且會與 Opus 4.6 的 token count 不同。[34]
Tokenizer 改動只影響 context limit，不影響成本	不完整。API pricing 會依 input、output、cache 等 token 用量欄位收費，token count 變動可能影響成本計算。[12][32][2]
最好用官方 counter 實測	準確。OpenAI 有 input token counting 與 tiktoken 指引，Gemini 有 count_tokens 文件，Anthropic 文件也指向 /v1/messages/count_tokens。[33][20][1][34]

成本可以怎麼估？

如果只看 input tokens，而且 input-token 單價不變，可以先用一條簡化公式估算：

額外 input 成本 ≈（新 tokenizer input tokens − 舊 tokenizer input tokens）× input-token 單價

但這只估算輸入部分。實際帳單還可能包含 output tokens、cache writes、cache hits 或其他產品收費欄位；Anthropic pricing 文件已把這些欄位分開，OpenAI 與 Gemini 也有各自的 pricing 文件可供對照。^[12][32][2]

升級模型前，建議這樣實測

1. 抽完整 payload，不要只看 user message

產品實際送進模型的內容，可能包括 system 指示、長 context、工具資料、檔案、圖像或其他輸入。Gemini 文件寫明所有 input 與 output 都會被 tokenized，OpenAI 的 token counting guide 也示範了包含文字與圖片的 input token counting。^[1][33]

2. 使用目標模型的官方 token counter

OpenAI 提供 responses.input_tokens.count 文件，也有 tiktoken 計算指引；Gemini 文件提供 count_tokens；Anthropic 在 Opus 4.7 文件中提到 /v1/messages/count_tokens，並指出 Opus 4.7 會與 Opus 4.6 回傳不同 token 數。^{[33][20][1][34]}

3. 依內容類型抽樣

不要只測一條短 prompt。Anthropic 對 Opus 4.7 的描述是 token 增幅會因內容而異，所以應抽樣高流量、長 context、成本最高或最常見的 payload 類型來比較。^[34]

4. 把 token 差額套入官方 pricing

先比較新舊 input token count，再用對應模型的官方 pricing 換算 input 成本差額；之後再把 output、cache 等欄位加回總成本模型。Anthropic、OpenAI、Gemini 都有官方 pricing 文件可供核對。^[12][32][2]

5. 再決定是否需要優化

如果 token 差額很小，可能只需要更新預算與監控；如果高流量 payload 明顯變貴，就該考慮壓縮 prompt、縮短 context、改善 cache 策略，或重新估算單次 request 成本。

重點不是看到「35%」就先恐慌，而是用官方 counter 與官方 pricing，把實際影響量化。^[12][34]

底線

新 tokenizer 的確可能讓同一份 prompt 使用更多 tokens。Claude Opus 4.7 的官方文件已確認，處理文字時可能比先前模型使用約 1x–1.35x tokens，最高約多 35%，但增幅會因內容而異。^[34]

真正該問的不是標題裡的 35%，而是：你的實際 payload 在新模型下多了多少 input tokens？output 行為有沒有改變？cache 欄位怎麼收費？供應商 pricing 是否一樣適用？

升級前先跑官方 token counter，再套官方 pricing，才是判斷 prompt 會不會變貴的可靠方法。^{[33][1][34][12][32][2]}