ClaudeHaiku5.5 砍價 90%、Opus5.5運行成本再降40%——小模型翻身了嗎？

三週兩連發。先看清楚它們各自能做什麼，再決定要不要換。

封面：Claude Opus 5.5 與 Claude Haiku 5.5（AI 生成），非產品截圖。

Anthropic 在三週內連發兩個模型：9 月 22 日的 Opus 5.5、10 月 7 日的 Haiku 5.5。降價的消息傳得最廣，但更值得停下來看的是另一組數字——Haiku 5.5 在終端機任務基準上，從上一代的 0.0% 跳到 39.2%。

0.0% 的意思是上一代根本做不了這類任務。這一代開始做得了。

一、先看規格：兩個模型差的只有價格和速度

很多人預設「便宜的模型 = 視窗小、功能少」。這一代不成立了。

資料取自 Anthropic 官方模型文件，2026-10-14 核對。

上一代 Haiku 4.5 是 200K 上下文、64K 輸出。這一代補齊到和旗艦同級，所以選便宜的不再等於犧牲視窗長度或多模態能力，剩下的差異只有價格和速度。

二、Haiku 5.5 的跨代幅度有多大

官方自己給的對照：

OSWorld 那個 72.4% 有個參照值得知道：該評測原始論文報告的人類基線是 72%。

客戶端給出的數字更具體：

• Asana：任務完成延遲降低超過 30%，單次代理輪次推理最快 2.5 倍。
• HubSpot：在 CRM 稽核任務上拿到他們記錄過的最佳成績，三次執行平均 92.8%。
• Box：比 Haiku 4.5 高 11 分，延遲約為其一半。
• AlphaSense：每週約 800 萬次呼叫；400 個查詢上得分 0.84 對 Haiku 4.5 的 0.76。

另外有兩個「第一次」：Haiku 5.5 是第一個支援 effort 檔位調節的 Haiku（Low 到 Max 五檔），Python 與 TypeScript SDK 也首次為 Haiku 檔位加入 computer use 與 browser use 的 beta 支援。

三、Opus 5.5 贏的不是分數，是效率

Opus 5.5 真正值得注意的是：它在幾個關鍵基準上超過了單價貴 2.5 倍的模型。

但更有說服力的是實測：

• 一次 68 萬行程式碼的遷移在一天內完成。
• 一次 20 萬行程式碼稽核 3 小時內完成，Opus 5 需要 20 多小時，還多消耗 2.5 倍 token。
• 18 份研究報告中 16 份通過品質標準——Fable 5.1 和 Opus 5 一份都沒通過。
• 一個頁面載入最佳化任務，40 次嘗試成功 39 次。

客戶端的數字指向同一個規律：

• Deloitte：用低 effort 就抓到 72% 的已知 bug，而 Opus 5 開高 effort 只有 56%。
• Quantium：原本「38 個提示、花 4 天」的任務，變成「11 個提示、3 小時」。
• GitHub：在 VS Code 裡解決的終端機任務比 Opus 5 多，步驟不到一半。
• Clio：跨 6 個儲存庫無人值守連續執行超過 18 小時。

注意這些案例贏的方式：不是「答得更對」，而是用更少的步驟和 token 達到同樣結果。這正是官方說「運行成本低 40%」的來源——單價只降了 20%，剩下的降幅全來自效率。

四、跑分不能只看數字，要看條件

這一節比上面都重要，因為官方自己在幫跑分降溫。

Anthropic 在 Opus 5.5 頁面明確寫道：在目前的能力水準下，基準分差已經不再是真實世界差異的可靠指引。

幾個必須知道的條件：

• 除非註明，結果使用自適應思考的 max effort。Terminal-Bench 上 Opus 5.5 用 xhigh、GPT-6 Astra 用 high，各取最佳。
• 生產防護是開啟的，官方說這「很可能降低了」測得效能。
• Terminal-Bench 4.0 的標準誤是 ±2.6 個百分點。排行榜上 Opus 5 的 51.8% 被復現為 52.3%，官方稱「在雜訊範圍內」。
• OSWorld 的數字是離線子集，不是完整評測。
• Haiku 5.5 換了新的分詞器，同樣任務 token 用量略有增加。

讀這些表的正確方式是：看量級，不看小數點。 39.2% 對 0.0% 是量級差異，有意義；54.4% 對 53.3% 在標準誤範圍內，不構成結論。

五、價格：有一道必須知道的懸崖

官方價格（2026-10-14 核對，美元／百萬 token）：

Haiku 5.5 是目前價目表上唯一按提示長度分檔計價的 Claude 模型。 分界線是 10 萬輸入 token，超過之後輸入、輸出、快取全部跳 5 倍，按單次請求判定。

官方的省錢口徑也由此而來：10 萬以內比 Haiku 4.5 低 90%，超過則低 50%；因為 Haiku 4.5 約 90% 的請求在 10 萬以內，所以平均約省 75%。

這條對編碼代理特別危險——代理會不斷累積上下文，每一輪都要重送對話、檔案內容和工具結果，很容易越線。實務做法是把材料切到 10 萬以下再送。

其他幾條：批次處理五折；Opus 5.5 的 fast mode 是 $8／$40、速度最高 2.5 倍；三個模型的快取折扣比例都不同（Opus 5.5 是基礎輸入價的 5%、Haiku 5.5 是 10%、Fable 5.1 是 2.5%），算長期成本別套同一個係數。

要對照第三方通道報價，可以看 Crazyrouter 的 Haiku 5.5 價格頁——該頁 2026-10-13 的快照顯示與官方同價，並同樣標出 10 萬 token 的分檔規則。第三方報價與官方是兩套數字，別混在一起算。

六、怎麼開始試

模型標識都是無日期的固定快照。先確認標識在你的通道上存在：

curl https://api.crazyrouter.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

2026-10-14 實測，claude-opus-5-5、claude-haiku-5-5、claude-haiku-4-5 三個標識都在列。確認後跑一個最小呼叫：

curl https://api.crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-haiku-5-5",
    "messages": [{"role": "user", "content": "只回覆兩個字：已連通"}]
  }'

從舊版遷移過來的話，有一個坑一定會踩到：手動的 extended thinking 已經不被接受。 過去 thinking.type: "enabled" 加 budget_tokens 的寫法，在 Opus 4.6 和 Sonnet 4.6 上已標為棄用，在更新的模型上直接報錯。現在統一用自適應思考，透過 effort 參數調節。

另外兩點：兩者預設 effort 都是 medium，要改就顯式傳；模型 ID 從 4.6 這代起即使不帶日期也是釘死的快照，升級必須改程式。

七、最該記住的一條：分層架構第一次成立了

如果整篇只記一個數據，建議記這個。

Cognition 在 Devin Fusion 裡讓 Haiku 5.5 當執行側、Opus 5.5 當主規劃者，FrontierCode 拿到 66.2 分——高於兩個模型單獨執行的成績（Haiku 5.5 單獨 46.4%、Sonnet 5.5 單獨 52.1%），同時降低了每任務成本和延遲。

組合分數高於任一單跑，說明兩個模型承擔的不是同一類工作：規劃側需要在多個候選方案間判斷，執行側需要把明確的步驟做對。各自待在自己的強項區間裡。

過去這個架構卡在執行層——便宜模型執行不了複雜步驟。現在 Haiku 5.5 的 Terminal-Bench 從 0% 到 39.2%，剛好補上這塊。

八、所以該怎麼分工

官方自己劃的線是：Sonnet 5.5 和 Opus 5.5 仍然是複雜 Agent 編碼任務的更好選擇，Haiku 5.5 適合「範圍更窄的任務」。Terminal-Bench 上 39.2% 對 70.6%（Sonnet 5.5）的差距說明了這點。

落地順序建議反著做：先用 Opus 5.5 把流程跑通、把驗收條件定下來，再把能被程式驗收的環節逐個下沉到 Haiku 5.5。先用便宜的、不行再升級的問題在於——你還沒有驗收標準，根本判斷不出「不行」。

回到標題那個問題：小模型翻身了嗎？ 在有邊界的執行類工作上，是的；在長鏈路的 Agent 編碼上，還沒有。但它的位置已經從「只能做簡單活」變成「分層架構裡不可或缺的那一層」。

最後提一句：Haiku 4.5 現已列為 legacy，價格 $1／$5 是 Haiku 5.5 短提示檔的 10 倍，Terminal-Bench 成績 0.0% 對 39.2%。還在用 4.5 的話，這次升級值得專門評估一次。