官方文件說「大概 1.0 到 1.35 倍」，實測卻是 1.47 倍。同樣的預算、同樣的配額，卻能處理更少的請求。對於重度使用 Claude Code 的開發者來說，這不是小事。
Anthropic 顯然不會白白提升成本。那他們換回了什麼？更關鍵的是：這值得嗎？
實測數據：比官方說的貴
這次測試用的是 Anthropic 提供的免費 API 端點 POST /v1/messages/count_tokens。同一份內容，分別用 4.6 和 4.7 的 tokenizer 數一次，差異純粹來自 tokenizer 本身。
兩組樣本：第一組是七份真實的 Claude Code 使用場景內容（CLAUDE.md、使用者提示、部落格文章、git log、終端機輸出、錯誤堆疊、程式碼 diff），第二組是十二種合成的內容類型（英文散文、代碼、結構化資料、CJK、emoji、數學符號），用來看不同類型的比率差異。
真實場景的結果：
| 內容類型 | 字元數 | 4.6 tokens | 4.7 tokens | 比率 |
|---|---|---|---|---|
| CLAUDE.md（真實檔案） | 5,000 | 1,399 | 2,021 | 1.445 |
| 使用者提示 | 4,405 | 1,122 | 1,541 | 1.373 |
| 部落格文章 | 5,000 | 1,209 | 1,654 | 1.368 |
| Git commit log | 2,853 | 910 | 1,223 | 1.344 |
| 終端機輸出 | 2,210 | 652 | 842 | 1.291 |
| Python 錯誤堆疊 | 5,255 | 1,736 | 2,170 | 1.250 |
| 程式碼 diff | 4,540 | 1,226 | 1,486 | 1.212 |
加權平均：1.325 倍（從 8,254 tokens 變成 10,937 tokens）。
不同內容類型的基準線測試：
| 內容類型 | 字元數 | 4.6 | 4.7 | 比率 |
|---|---|---|---|---|
| 技術文件（英文） | 2,541 | 478 | 704 | 1.47 |
| Shell 腳本 | 2,632 | 1,033 | 1,436 | 1.39 |
| TypeScript 代碼 | 4,418 | 1,208 | 1,640 | 1.36 |
| 西班牙文散文 | 2,529 | 733 | 986 | 1.35 |
| Markdown（含代碼區塊） | 2,378 | 604 | 812 | 1.34 |
| Python 代碼 | 3,182 | 864 | 1,112 | 1.29 |
| 英文散文 | 2,202 | 508 | 611 | 1.20 |
| JSON（稠密） | 48,067 | 13,939 | 15,706 | 1.13 |
| 工具定義（JSON Schema） | 2,521 | 738 | 826 | 1.12 |
| CSV（數值） | 9,546 | 5,044 | 5,414 | 1.07 |
| 日文散文 | 993 | 856 | 866 | 1.01 |
| 中文散文 | 750 | 779 | 789 | 1.01 |
英文和代碼子集的加權比率：1.345 倍。CJK 子集：兩邊都是 1.01 倍。
Tokenizer 到底改了什麼
數據顯示三個明顯模式：
第一，CJK、emoji 和符號內容幾乎沒變（1.005–1.07 倍）。如果是全面重新設計詞彙表，這些部分的變化應該更平均。實際情況不是這樣，這符合非拉丁字母部分的詞彙表變化較少的推測。
第二，英文和代碼在自然內容上增加了 1.20–1.47 倍。這符合 4.7 使用比 4.6 更短或更少的子詞合併來處理常見英文和代碼模式的假設。
第三，代碼比獨特散文受到更大影響（1.29–1.39 倍 vs 1.20 倍）。代碼有更多重複的高頻率字串——關鍵字、import 語句、識別符——這些正是 Byte-Pair Encoding 在代碼訓練時會合併成長字串的模式。
英文的字元每 token 比率從 4.33 降到 3.60。TypeScript 從 3.66 降到 2.69。詞彙表在用更小的片段表示同樣的文本。
這是假設，不是證明。計算 token 數量無法告訴你 Anthropic 的專有詞彙表中哪些具體條目改變了。
為什麼要推出更「貴」的 tokenizer
Anthropic 的遷移指南提到「更字面地遵循指令，特別是在較低的 effort 等級。模型不會將指令從一個項目靜默推廣到另一個。」
更小的 token 強制注意力放在個別字詞上。這是更緊密的指令遵循、字元層級任務和工具呼叫精確度的已知機制。合作夥伴報告（Notion、Warp、Factory）描述在長期執行時有更少的工具錯誤。
Tokenizer 是一個合理的貢獻因素。權重和後訓練也改變了。Token 計數無法區分它們。
4.7 真的更聽話嗎
成本測量完了。現在的問題是：Anthropic 用這些成本換回了什麼？
他們的說法是「更字面地遵循指令」。聽起來合理，但 token 數據無法證明。作者做了一個直接測試。
IFEval（Zhou et al., Google, 2023）是一個包含可驗證約束的提示詞基準測試。「用 N 個字回覆」「包含單詞 X 兩次」「不要用逗號」「全部大寫」。每個約束都有一個 Python 評分器。二元通過/失敗。
IFEval 有 541 個提示詞。作者用固定種子採樣了 20 個，每個提示詞用兩個模型跑一次，用 IFEval 發布的檢查器評分。
結果：
| 指標 | 4.6 | 4.7 | Delta |
|---|---|---|---|
| 嚴格模式，提示詞層級（全部通過） | 17/20 (85%) | 18/20 (90%) | +5pp |
| 嚴格模式，指令層級 | 25/29 (86%) | 26/29 (90%) | +4pp |
| 寬鬆模式，提示詞層級 | 18/20 (90%) | 18/20 (90%) | 0 |
| 寬鬆模式，指令層級 | 26/29 (90%) | 26/29 (90%) | 0 |
在嚴格指令遵循上有小幅但方向一致的改善。寬鬆評估是持平的。兩個模型都遵循高層次指令——嚴格模式的差距來自 4.6 偶爾在精確格式上出錯，而 4.7 不會。
只有一種指令類型有實質移動：change_case:english_capital（0/1 → 1/1）。其他都持平。真正讓兩個模型分開的提示詞是一個四約束鏈，4.6 搞砸了一個，4.7 全對。
幾個需要提出的警告：
- N=20。IFEval 有 541 個提示詞。20 個提示詞的樣本足以看出方向，不足以對大小有信心。N=20 的 +5pp delta 與從「沒有真正差異」到「真正的 +10pp 改善」的任何情況都一致。
- 這測量的是 4.6 → 4.7 的淨效果。Tokenizer、權重和後訓練都改變了。作者無法分離哪一個驅動了 +5pp。「更小的 token」和「更好的指令遵循」之間的因果關聯仍然是假設。
- 每個提示詞單次生成。每個提示詞多次執行會收緊估計。
所以：4.7 在這個子集上比 4.6 多跟隨了幾個百分點的嚴格指令。小效果，小樣本。不是 Anthropic 合作夥伴在發布時引用的「戲劇性改善」框架——至少不是在這個基準上。
額外的 token 買到了可測量的東西。在嚴格指令遵循上 +5pp。小。真實。那麼：每個提示詞多花 1.3–1.45 倍 token 值得嗎？這是每次 session 的成本。
一次 Claude Code session 的數學帳
想像一個長 Claude Code session——80 輪來回修 bug 或重構。
設定（每個輪次你都有什麼在 context 裡）：
- 靜態前綴：2K CLAUDE.md + 4K 工具定義 = 6K tokens，每輪都一樣
- 對話歷史：每輪長大 ~2K（500 token 使用者訊息 + 1,500 token 回覆），到第 80 輪時達到 ~160K
- 使用者輸入：每輪 ~500 新鮮 tokens
- 輸出：每輪 ~1,500 tokens
- Cache 命中率：~95%（在 5 分鐘 TTL 內的典型值）
需要先解釋一件事：80 輪的平均快取前綴約 86K tokens，不是 6K。靜態 6K 很小；所有輪次的平均歷史（第 1 輪 0，第 80 輪 160K，平均約 80K）佔主導。因為大部分快取讀取成本發生在歷史龐大的後期輪次，這 ~86K 平均值才是每輪實際計費的數據。
4.6 session 成本
| 項目 | 算式 | 成本 |
|---|---|---|
| 第 1 輪快取寫入 | 8K × $6.25/MTok | $0.05 |
| 第 2-80 輪快取讀取 | 79 × 86K × $0.50/MTok | $3.40 |
| 新鮮使用者輸入 | 79 × 500 × $5/MTok | $0.20 |
| 輸出 | 80 × 1,500 × $25/MTok | $3.00 |
| 總計 | ~$6.65 |
快取讀取佔輸入成本主導。輸出佔整體主導。
4.7 session 成本
前綴中的每個 token 都按其內容比率縮放：
- CLAUDE.md：1.445x → 2K 變成 2.9K
- 工具定義：1.12x → 4K 變成 4.5K
- 對話歷史（主要是英文和代碼）：1.325x → 160K 到第 80 輪變成 212K，session 平均約 106K
- 使用者輸入：1.325x → 500 變成 ~660
4.7 上平均快取前綴：~115K tokens（從 86K 上升）。輸出 token 是變數——大約和 4.6 一樣，如果 Claude Code 新的 xhigh 預設產生更多思考 token，可能高達 ~30%。
| 項目 | 算式 | 成本 |
|---|---|---|
| 第 1 輪快取寫入 | 10K × $6.25/MTok | $0.06 |
| 第 2-80 輪快取讀取 | 79 × 115K × $0.50/MTok | $4.54 |
| 新鮮使用者輸入 | 79 × 660 × $5/MTok | $0.26 |
| 輸出 | 80 × 1,500–1,950 × $25/MTok | $3.00–$3.90 |
| 總計 | ~$7.86–$8.76 |
差距
~$6.65 → ~$7.86–$8.76。大約每個 session 多花 20–30%。
每 token 價格沒變。每 session 成本變了，因為同樣的 session 包含更多 token。
對於 Max 方案用戶來說，如果限制是次數而不是金額：5 小時視窗大約提早相同比率結束。在 4.6 上跑滿視窗的 session 在 4.7 上大概不行。
這對 prompt cache 意味著什麼
Prompt caching 是 Claude Code 運行的架構。
4.7 tokenizer 變更以三種方式與快取互動：
第一，4.7 session 從頭開始。Anthropic 的 prompt cache 是按模型分區——從 4.6 切換到 4.7 會讓所有快取前綴失效，就像從 Opus 切換到 Sonnet 一樣。Tokenizer 變更不會造成這個，但它讓冷啟動更貴：你寫入新快取的前綴是 4.6 等價物的 1.3–1.45 倍大。
第二，快取容量按 token 比率成長。CLAUDE.md 部分 1.445 倍多 token 意味著 1.445 倍多 token 付一次快取寫入，之後每輪 1.445 倍多付快取讀取。機制仍然有效。只是有更多要付費。
第三，同樣的對話，不同的計數。在 4.7 上重跑 4.6 session，你的日誌顯示不同的數字。如果你依據歷史 token 計數做計費基準或可觀測性，切換模型 ID 的那天會有階梯變化。
幾個反駁意見
「輸入大多是快取讀取。每 token 成本幾乎沒變。」
合理。在 5 分鐘 TTL 內的 session，96% 的輸入是 $0.50/MTok 的快取讀取——已經是標價的 10% off。快取部分的 1.325 倍比率比新鮮輸入的美元影響更小。
但 Max 方案將所有 token 計入次數限制，不是美元。而且幾種模式會碰到非快取區域：TTL 過期後的第一個 session、每個快取破壞事件（CLAUDE.md 編輯、工具列表變更、模型切換）、每個重寫前綴的壓縮事件。在那些輪次你要為快取寫入付完整比率。穩定狀態是亮點。邊緣更吵。
「Anthropic 記錄 1.0–1.35 倍是範圍，不是硬性上限。」
同意。真實世界的加權比率（1.325 倍）落在他們範圍的頂端。個別檔案類型超過它——CLAUDE.md 在 1.445 倍，技術文件在 1.473 倍。這是有用的發現：記錄範圍的頂端是大部分 Claude Code 內容實際所在的位置，不是中間。規劃時考慮上限，不是平均。
那麼：在英文和代碼上 token 多花 1.3–1.45 倍。Anthropic 買給你 +5pp 的嚴格指令遵循。標價沒變。有效每 session 成本變了。
值不值得？這取決於你送什麼。你為了模型多字面地遵循提示詞的小但真實的改善，每 session 多付約 20–30%。
對於台灣的開發者社群來說，如果你的工作內容大量是中文（CJK），影響幾乎可以忽略。但如果你的 workflow 是英文技術文件和程式碼為主，特別是重度使用 Claude Code 的開發者，預算和次數限制都需要重新評估。
這不是說 4.7 不值得用——+5pp 的嚴格指令遵循對某些任務來說可能是關鍵差異。問題是：你的任務是否屬於那一類？
測量一下。用 count_tokens API 數數你常用的檔案類型。如果是 CLAUDE.md、技術文件、程式碼 diff，準備好面對 1.3–1.45 倍的比率。如果是中文內容或簡單英文，影響小得多。
然後問自己：多花 20–30% 的預算，換來模型更字面地聽話，對你的工作流來說是不是划算的投資？
數字會說話。只是沒說你預期的那個故事。