Claude Opus 5.5 發布隔天，CyberQ 以自建腳本 opus55_test.py 直接呼叫 Claude API 實測。環境為 Python SDK anthropic 0.85.0，全部請求皆為非串流，整輪測試共約 70 次請求。
模型規格
Models API 回傳 max_input_tokens 為 1,000,000，max_tokens 為 128,000，與 Opus 5 相同。
破壞性變更驗證
九項全數與官方文件相符。
| 請求 | 預期 | 實測 |
|---|---|---|
thinking: {"type": "disabled"} | 400 | 400 |
thinking: disabled 搭配 effort: low | 400 | 400 |
thinking: {"type": "enabled", "budget_tokens": 2048} | 400 | 400 |
tool_choice: {"type": "any"} | 400 | 400 |
tool_choice: {"type": "tool"} | 400 | 400 |
computer_20251124 工具 | 400 | 400 |
thinking: {"type": "adaptive"} | 成功 | 成功 |
tool_choice: {"type": "auto"} | 成功 | 成功 |
computer_toolset_20260801 | 成功 | 成功 |
值得注意的是，Opus 5 允許在 high 以下關閉 thinking，Opus 5.5 則連 effort: low 搭配 disabled 也一律拒絕。既有程式若沿用「低 effort 加關 thinking」的省錢組合，升級後會直接失敗，必須改成只設 effort。
Effort 掃描
三題各跑五個 effort 等級，數字為輸出 token、延遲與估算費用。
| effort | 程式除錯 | 資安短答 (限 200 字) | 結構化擷取 |
|---|---|---|---|
| low | 958 / 11.7 秒 / $0.020 | 425 / 6.2 秒 / $0.009 | 247 / 4.4 秒 / $0.005 |
| medium | 1,187 / 13.0 秒 / $0.024 | 756 / 8.4 秒 / $0.015 | 379 / 5.5 秒 / $0.008 |
| high | 1,836 / 16.9 秒 / $0.037 | 1,089 / 12.3 秒 / $0.022 | 371 / 5.3 秒 / $0.008 |
| xhigh | 1,972 / 18.3 秒 / $0.040 | 1,756 / 18.0 秒 / $0.035 | 435 / 6.3 秒 / $0.009 |
| max | 9,624 / 81.1 秒 / $0.193 | 15,855 / 134.5 秒 / $0.317 | 1,679 / 17.0 秒 / $0.034 |
low 到 xhigh 的成本大致呈平緩上升，max 則是斷崖。資安短答在 max 下第一次以 16,000 的 max_tokens 執行時直接被截斷，放寬到 20,000 重跑才完成，最後交出的答案只有 216 個字，卻用了 15,855 個輸出 token，幾乎全是看不見的思考。官方文件提醒 max 要在 max_tokens 預留空間，實測證實這不是客套話。對於短答類的工作，max 的成本約是 medium 的 20 倍，換不到可見的差異。
CyberQ 實測發現，max 下的 token/s 反而更高 (9,624 ÷ 81.1 = 119，15,855 ÷ 134.5 = 118)，因為思考 token 串流速度快於可見輸出。這解釋了為何 max 延遲增加的倍數小於 token 增加的倍數。
五個等級的程式除錯答案都正確指出 bug (比方說日期與時間比較時，最後一天只涵蓋到零點)。這是以關鍵字核對，並非盲評。
預設 effort 是否為 medium
同一題分別以「不指定 effort」與「指定 medium」各跑三次。
| 設定 | 輸出 token | 平均 | 平均延遲 |
|---|---|---|---|
| 不指定 | 1,398、1,565、1,132 | 1,365 | 13.2 秒 |
| medium | 1,558、1,535、1,379 | 1,491 | 14.4 秒 |
兩組分布重疊，且都明顯低於同題 high 的 1,836 token，與「預設為 medium」一致。回應中沒有回報實際使用的 effort，三次樣本只能說明兩者分不出差異。對既有 Opus 5 程式的意義是，不指定 effort 就等於從 high 降到 medium，要維持原本深度必須明寫 effort: "high"。
與 Opus 5 對照
同樣三題，Opus 5.5 使用預設 (medium)，Opus 5 使用預設 (high)。
| 題目 | Opus 5.5 | Opus 5 | 費用差 |
|---|---|---|---|
| 程式除錯 | 1,187 token / 13.0 秒 / $0.024 | 1,660 token / 24.2 秒 / $0.042 | 低 42% |
| 資安短答 | 756 token / 8.4 秒 / $0.015 | 855 token / 17.5 秒 / $0.022 | 低 29% |
| 結構化擷取 | 379 token / 5.5 秒 / $0.008 | 523 token / 7.2 秒 / $0.014 | 低 41% |
把 Opus 5 也設成 medium，三題的輸出 token 為 1,648、805、348，費用與延遲幾乎不變，可見 Opus 5 在這類短題上 high 與 medium 差別不大。在「各自預設」的比法下，實測省下 29% 到 42%，與官方「接近四成」的說法吻合。輸出速度方面，程式除錯與資安短答兩題，Opus 5.5 為每秒 91 與 90 token，Opus 5 為 69 與 49 token，快 30% 以上的說法在這兩題成立。但結構化擷取這種不到 400 token 的短回應，Opus 5.5 為 68 token，Opus 5 為 72 token，兩者相當，固定開銷在短回應中佔比較高。兩者的程式除錯答案都正確。
反例：CodeRabbit 的程式碼審查評測
CodeRabbit 於 9 月 22 日公布的評測得到相反方向的結果。在其兩組測試集上，Opus 5.5 標準設定的 token 用量比其生產基線多 49.2% 與 40.6%，max 設定多 57.6% 與 60.1%。抓到的已知 bug 則較多，80 題中 51 題對 49 題，13 題困難案例中 10 題對 5 題，留言數也較多。
這與官方「token 更少」的說法不一致，但兩者比的對象不同。官方比較的是 Opus 5，CodeRabbit 的基線則是未具名的「生產模型組合」，數字也未區分輸入與輸出，CodeRabbit 自己註明這些數字不能換算成金額或延遲。CyberQ 的對照只有三題短題，也無法推論到長篇的程式碼審查工作。比較穩妥的解讀是，Opus 5.5 相對 Opus 5 省 token，但不保證比既有的生產配置省，導入前仍應以自己的工作負載量測。
資安任務分流
CyberQ 以四題 MSP 與資安團隊日常會問的防禦型題目測試，分別是修補 SQL injection、說明 Log4Shell 成因與修補、撰寫偵測 certutil 下載行為的 Sigma 規則，以及設計 AI agent 稽核日誌。四題全部正常完成 (stop_reason: end_turn)，沒有觸發 refusal，也沒有 stop_details。
這表示日常的弱點修補與偵測規則撰寫，在這個樣本中沒有被誤判分流。不過四題只能說明「常見防禦題不會被擋」，無法畫出分流邊界的位置。
這四題都屬於「解說與偵測」型，社群回報的誤判則集中在另一類工作。claude-code 專案的 issue #93821 (2026-09-12 提出，截至本文仍未關閉) 中，一位 Max 方案使用者在 Claude Code 使用 Fable 5.1 處理自家閉源產品的發布工程，包括剝除自家二進位檔的除錯資訊、改名內部識別字，以及用 Terser 壓縮。這些工作被資安防護判定後靜默改由 Opus 4.8 處理，連讀取自己本機 markdown 檔的工具輸出也曾觸發。以 /model 切回 Fable 5.1 後，下一則訊息又再被分流，回報者認為一次觸發就會影響整個 session。關閉自動換模型的選項後，被標記的訊息則會直接中止對話。
CyberQ 在準備補測這一類題目時也遇到同樣的情況。實測使用的 Claude Code session 本身跑的是 Opus 5.5，在撰寫發布工程類測試題目的過程中，回應被安全分類器中途攔下，已送出的檔案修改沒有寫入，session 也被要求不得再產生同類內容。這是在 Claude Code 環境中發生，並非透過 API 對 Opus 5.5 送出測試題，因此只能說明這類工作在 Claude Code 內確實可能觸發分類器，不能直接推論 API 上的分流行為。發布工程類題目的 API 補測，將改由使用者依實際工作提供題目後再進行。另一個觀察是，這四題在預設 effort 下的輸出達 1,892 到 6,643 token，Log4Shell 一題花費 $0.13，資安解說類題目的篇幅明顯比一般題長。
工具呼叫之間的文字
以一個四個檔案的假專案跑工具迴圈，比較預設顯示與 display: "updates"，並用兩種提示詞。
要求「每次呼叫工具前用一句話說明」時，兩種顯示設定下，中途說明都以一般 text block 回傳，每則 23 到 58 字。
不要求說明、只給稽核任務時，模型在工具呼叫之間完全不輸出文字，直接連續呼叫工具，最後一次給出完整報告。
四組都有出現 thinking block，但內容皆為空字串，updates 模式下也沒有拿到進度摘要。
官方文件說明模型可略過進度更新，這次任務太短，可能正是被略過的情況。能確認的是，自建介面若只渲染 text block，在不要求說明的情況下，工具呼叫期間本來就會是一片沉默。若需要進度訊息，在提示詞中明確要求逐步說明是目前實測有效的做法。
Fast mode
這次未能測試測試到，三次 fast 請求皆回傳 429，可能是因為 fast mode 仍屬研究預覽，需另外開通額度，一般 API 帳戶預設無法使用。
測試限制說明
每個條件多半只跑一次，預設 effort 驗證為三次，數字只能呈現趨勢，不具統計顯著性。答案品質僅以關鍵字核對是否抓到重點，未做盲評。費用為依牌價估算，未計入 429 等失敗請求。
CyberQ 觀點
整體而言，Claude Opus 5.5 在預設設定下確實兌現了官方承諾，輸出速度加快三成、花費降低近四成，且常見的資安防禦任務全數順利過關未遭誤擋。然而這份成本紅利很大一部分來自預設 effort 從 high 降至 medium，若既有系統需要維持過往的推論深度，實際的費用差距並不如表面顯著。
若把 Opus 5.5 設回 high 與 Opus 5 high 比較，程式除錯 $0.037 對 $0.042 省 12%，資安短答 $0.022 對 $0.022 持平，結構化擷取 $0.008 對 $0.014 省 43%，這其實是更有力的論證囉。
更關鍵的升級考驗在於相容性與推論控制，包含 thinking 參數不再允許關閉、既有的省錢組合直接報錯，以及 max 等級可能暴增二十倍隱形思考 token 的成本斷崖。對於準備採用的團隊而言，Opus 5.5 的綜合表現與性價比相當出色，但切忌直接無痛換版，上線前務必重構請求參數並依工作型態重新校準 effort 等級，才不會在省下牌價的同時踩進非預期的開銷地雷。
延伸閱讀
Claude Platform Docs, Refusals and fallback. https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback
Claude Platform Docs, Preserved thinking. https://platform.claude.com/docs/en/build-with-claude/preserved-thinking
