小模型最常被問的問題不是「夠不夠聰明」，而是「在哪個用量級距下還划算」。Anthropic 在 2026 年 10 月 7 日發表的 Claude Haiku 5.5 產品頁給了一個少見的答案：計價直接按 prompt 長度分兩級，100K tokens 以下每百萬輸入 tokens 收 $0.10、輸出 $0.50；超過 100K 之後跳到輸入 $0.50、輸出 $2.50。也就是說，同一個模型在長 context 下貴了五倍。這對把 Haiku 塞進 agent pipeline 的團隊是個明確的設計訊號：把 context 壓短不只是為了延遲，而是為了單價。
第一個有 effort controls 的 Haiku
產品頁另一個值得注意的點：Haiku 5.5 是這個系列第一次提供 effort controls，讓團隊可以按任務調整成本與能力的取捨。過去這類旋鈕多半出現在旗艦或中階模型，現在往下放到小模型，代表 Anthropic 把「按任務調節」當成整條產品線的基本假設。如果你之前讀過這篇 Sonnet 5.5 的成本數學，會發現同一個邏輯正在往整個 Claude 家族蔓延：分數不是重點，每個任務的帳單才是。
另外兩個省錢機制照舊存在：prompt caching 最多省 90%，batch processing 省 50%。配合分級計價，一個做摘要或分類的高頻功能，實際成本可能比定價表看起來低得多——前提是你的呼叫模式吃得滿 cache。
它被設計來做什麼
Anthropic 在產品頁列的 use cases 很具體，而且彼此互補：高流量文字任務（分類、摘要、生成）、延遲敏感的即時場景（chat、voice agent、in-app assistant）、coding 與定義明確任務的 subagent、表單填寫之類的 computer use，以及跨多檔案的小幅直接編輯。最值得記的是 subagent 這個定位：讓 Fable 或 Opus 負責規劃，把子任務交給 Haiku 平行跑。這幾乎就是把「大模型當 orchestrator、小模型當執行層」的架構直接寫進產品敘事裡。
客戶數字怎麼講
產品頁引了幾家客戶的說法。一家提到其 Document 問答功能每週約 800 萬次呼叫，在 400 個查詢的測試中 Haiku 5.5 對比 4.5 有統計顯著的提升（0.84 對 0.76）。Box 說早期測試分數高出 11 分、延遲約減半；另一家回報任務完成延遲降逾 30%、每個 agent turn 的推論最快快 2.5 倍。HubSpot 用模擬 portal 測 CRM 任務，拿到該評測套件迄今最高分 92.8%。這些是廠商引用的客戶證言，不是獨立評測，但方向一致：同一個工作負載換模型，速度和成本同時改善。
builder 該做的事
如果你已經有跑量的分類、摘要或 subagent 流程，具體動作有三個。第一，檢查送到 Haiku 的 prompt 長度，特別是被自動帶入的歷史訊息和工具輸出——超過 100K 就是五倍單價。第二，確認哪些呼叫能進 batch 或吃得到 cache。第三，把 effort controls 當成新的調校維度，而不是沿用固定設定。
要留的限制：產品頁沒有提供完整的 benchmark 對照表或系統卡內容細節，effort controls 的具體參數行為也沒有在頁面上展開。實際的品質與成本取捨，還是得用自己的 eval 先量一輪再上線。