AIDive開場:沒人叫來用的便宜工人
Claude Code 的 subagent 不會用 Haiku 5.5,除非有兩個檔案另外指定。這就是全部的發現,本文其餘部分都是它背後的量測:在一個真實的專案上做七個日常任務,讓 Haiku 5.5、Sonnet 5.5 和 Opus 5.5 各自擔任工人,每跑完一個區塊就讀一次方案用量表。
Haiku 5.5 在 2026 年 10 月 7 日發布,Anthropic 把它定位成 subagent 模型,每個 token 的價格是舊版 Haiku 的十分之一。一個帳號一個月的紀錄則說明了另一半:2,631 次 subagent 執行,只有 42 次用 Haiku,因為每個 subagent 都繼承主模型。把所有 subagent 都改成 Haiku,會引出一個明顯的問題:方案用量表到底會還給你多少?兩個檔案可以讓 Explore agent 改用 Haiku,而大多數人第一個想到的設定,單獨使用時什麼也不會改變。大家都信任的用量明細面板,則是用寫死在執行檔裡的四個數字算出來的。
一個任務在各模型上要花多少
Haiku 5.5 的價格是每百萬個輸入 token $0.10、每百萬個輸出 token $0.50,Haiku 4.5 則是 $1 和 $5。這個價格適用於 100,000 token 以內的 prompt;超過這條線,整個請求的價格會變成五倍。Anthropic 所說的「90%」不是折扣:它指的是前一代 Haiku 的請求中,沒有超過這條線的比例。
| 模型 | 每百萬 token 輸入 | 每百萬 token 輸出 |
|---|---|---|
| Haiku 5.5(prompt 100k 以內) | $0.10 | $0.50 |
| Haiku 5.5(prompt 超過 100k) | $0.50 | $2.50 |
| Haiku 4.5 | $1.00 | $5.00 |
| Sonnet 5.5 | $2.00 | $10.00 |
| Opus 5.5 | $4.00 | $20.00 |
實際使用中還有兩個陷阱。新的 tokenizer 把同樣的文字算成比 Haiku 4.5 多約 30% 的 token。而在 max effort 下,一次獨立的測試量到每個任務約 162,000 個輸出 token,大約是一個競爭對手模型的三倍。Anthropic 自己的說法很謹慎:複雜的 agentic coding 仍然是 Sonnet 和 Opus 比較好的選擇。在 Terminal-Bench 4.0 上,Haiku 5.5 得分 39.2%,Sonnet 5.5 是 70.6%。
這次測試涵蓋 subagent 實際會拿到的任務。一個真實的專案 tinydb,測試套件有 226 個測試。七種任務:探索程式碼、修正失敗的測試、清掉 lint 錯誤、寫 commit 訊息、加一個小功能、審查 diff、總結架構。四個工人:中等 effort 的 Haiku 5.5、低 effort 的 Haiku 5.5、Sonnet 5.5、Opus 5.5。總共 182 次執行,每一次都由隱藏測試或固定規則檢查,而不是靠肉眼。
| 設定 | 執行次數 | 通過 | 小功能的牌價 | 小功能的牆上時間 |
|---|---|---|---|---|
| Haiku 5.5,低 effort | 70 | 70 | $0.0052 | 17.1 s |
| Haiku 5.5,中等 effort | 70 | 70 | $0.0078 | 26.3 s |
| Sonnet 5.5 | 21 | 21 | $0.1050 | 30.3 s |
| Opus 5.5 | 21 | 21 | $0.1675 | 30.3 s |
探索程式碼在低 effort 的 Haiku 上花 $0.0035,在 Opus 上花 $0.1454,差了大約四十倍。Haiku 從來沒有比較慢:七個任務全部通過,價格只是零頭,速度一樣快甚至更快。
為什麼預設沒有任何東西跑在 Haiku 上
預設沒有任何東西會送到 Haiku,這是刻意的設計。從 2.1.198 版開始,內建的 Explore agent 會繼承主 session 的模型,上限是 Opus;在那個版本之前,它跑在 Haiku 上。每個自訂 subagent 也一樣。文件給出了解析順序:啟動時指定的模型,然後是 agent 檔裡的模型,接著是 CLAUDE_CODE_SUBAGENT_MODEL 變數,最後才是主模型。
這份清單裡有個陷阱,文件也講得很明白:單獨設定 subagent 模型變數,並不會改變內建 Explore 和 Plan agent 所用的模型。兩次 headless 執行證實了這兩點。主 session 用 Fable 模型,問一個問題(用 Explore agent 找出查詢快取在哪裡被清除),工具結果會說出實際執行的模型:Opus 5.5。同樣的執行,只把 subagent 模型變數設成 Haiku 5.5、其他什麼都不改:還是 Opus 5.5。
這就是為什麼一個月的紀錄會是那個樣子。在 2,631 次 subagent 執行中,有 42 次用了 Haiku。subagent 佔了帳號全部 token 的 48.1%,而 Haiku 在加權成本中的佔比是 0.27%。這個預設是站得住腳的選擇:跑在主模型上的探索者,讀程式碼的能力和主模型一樣好。沒有人公布的,是它要花多少錢。
那兩個檔案
兩個檔案就能解決,你可以只用其中一個,也可以兩個都用。小的那個是專案裡的一個 agent 檔:建立 .claude/agents/Explore.md,名稱取為 Explore,加上描述,把模型設成完整 ID 的 claude-haiku-5-5,把 effort 設成 low,並把工具限制為 Read、Glob、Grep 和 Bash。從此 Claude Code 就把你的檔案當成 Explore agent,文件也明白寫了:定義一個名為 Explore 的專案 subagent,並指定 Haiku 模型。同樣的 headless 執行這時會回報 resolvedModel: claude-haiku-5-5。
第二個檔案是你的 settings。在 .claude/settings.json 裡加一個 env 區塊,放兩個變數:CLAUDE_CODE_SUBAGENT_MODEL 設為 claude-haiku-5-5,以及 CLAUDE_CODE_SUBAGENT_MODEL_FORCE 設為 1。大家最常漏掉的就是 force。從 2.1.257 版開始,這個旗標會把 subagent 模型套用到每一個 subagent,忽略啟動時或 agent 檔裡設定的覆寫。在環境裡有這兩個變數、沒有 agent 檔的同一次執行,又讀到 Haiku 5.5。
| 你想要的 | 使用 | 副作用 |
|---|---|---|
| 每個 subagent 都便宜 | 帶有 force 旗標的 settings env 區塊 | 你刻意指定 Opus 的 agent 也會降到 Haiku |
| 只讓探索者便宜 | Explore agent 檔 | 其他 agent 保留各自的模型 |
請固定使用完整的模型 ID。haiku 這個別名只在 Anthropic API 上代表 Haiku 5.5;在 Bedrock、Vertex 和 Foundry 上,它仍然代表 Haiku 4.5。Claude Code 儲存庫上有一個公開的 issue,回報 1,371 個 subagent 中有 1,149 個跑在父層的 Opus 模型上,而檔案寫的是別的模型,在十幾個版本間(2.1.277 到 2.1.290)時有時無,Anthropic 沒有回覆。在目前的 2.1.293 版上,182 次執行每一次都用了設定的模型。即便如此,還是要檢查:/tasks 指令會顯示每個 subagent 實際用的模型,headless 執行的工具結果也帶有這個資訊。剩下的槓桿是 effort,因為這些模型的思考無法關閉;Explore 檔裡設成低 effort 是刻意的選擇,它能換到什麼,後面有量測。
真正的用量表看到了什麼
每一次帶串流輸出的 headless 執行都會送出一個 rate_limit_event。裡面有兩個比例,五小時視窗和七天視窗,各有兩位小數。它們直接來自 Anthropic 隨每次回覆送出的回應標頭,解析度是一個百分點,沒有更細。四個工人分成四個區塊依序執行,期間沒有任何其他東西動到這個帳號。
| 區塊 | 執行次數 | 五小時視窗(之前) | 五小時視窗(之後) | 每週視窗 |
|---|---|---|---|---|
| Haiku 5.5,低 effort | 70 | 21% | 21% | 67% |
| Haiku 5.5,中等 effort | 70 | 21% | 21% | 67% |
| Sonnet 5.5 | 21 | 21% | 22% | 67% |
| Opus 5.5 | 21 | 22% | 23% | 67% |
以牌價計算,整個矩陣花了 $4.09。在用量表上,它花了五小時視窗的兩個百分點,以及每週的零個百分點。Haiku 那一半花了 $0.54,卻什麼也沒動:這個帳號視窗的一個百分點,比 140 個這樣的 Haiku 任務還貴。
Anthropic 對模型的權重只公布了一句話:Opus 每一輪比 Sonnet 貴好幾倍,Sonnet 又比 Haiku 貴。好幾倍。哪裡都沒有給出數字。這些視窗是所有模型共用的一個池,所以在 session 中途換模型,不會還給你任何額度。每個區塊都有最多一個百分點的四捨五入誤差,這表示 Sonnet 的一個百分點和 Opus 的一個百分點無法區分。用量表能確定證明的是:這些模型上的一個有範圍的任務,在這個解析度下是看不見的。每個模型的權重,得從別的地方去讀。
/usage 明細只是估算
打開 /usage 面板,你會看到一份明細:歸因到 skill、subagent、外掛和 MCP 伺服器的百分比。它看起來像伺服器資料,但不是。文件說這些數字是近似值,是根據這台機器上的本地 session 紀錄計算的,所以公式就在執行檔裡。對執行檔跑 strings,就會掉出兩個函式。
| 因素 | 權重 |
|---|---|
| 模型層級:Fable | 10 |
| 模型層級:Opus | 5 |
| 模型層級:Haiku | 1 |
| 模型層級:其他 | 3 |
| 快取 token | 1 |
| 新的輸入 token | 10 |
| 快取寫入 | 12.5 |
| 輸出 token | 50 |
每筆紀錄的權重是 token 總和乘以模型層級。這些是客戶端的歸因權重,不能證明伺服器如何計算你的額度,而落差也確實存在。把公式套在上面的區塊:70 次 Haiku 中等 effort 的執行得 29.5 單位,21 次 Opus 執行得 27.3。面板會把 Haiku 區塊排在 Opus 區塊前面;真正的用量表則是零個百分點對一個百分點。
底下還有第二個缺陷。一個公開的 issue 回報,subagent 的 transcript 記錄的是第一個串流片段的用量:一次執行記下 461 個輸出 token,同一次執行以 headless 方式記下的是 15,575。這台機器上的一份 transcript,每一筆 assistant 紀錄都只顯示 16 個輸出 token。公式把這個被低估的數字乘以 50,所以寫很多內容的 subagent 會從面板上消失。請把它當成它本來的用途:看哪個 skill 或 agent 在吃你的本地紀錄,並附有日和週的鍵。至於模型在你真實額度裡的權重,它只是猜測。
一天的額度到底花在哪
用量表能看見的尺度是一天。Andrea Grandi 在 Haiku 5.5 發布當天公布了他的數字,用的是 Pro 方案。他的主 session 以中等 effort 跑 Opus 5.5;一個 Sonnet 5.5 的 implementer agent 負責寫程式碼;其餘由兩個 Haiku 5.5 agent 處理,一個是 plan 模式、沒有編輯工具、最多十二輪的 scoper,另一個是低 effort 的 shipper,負責 commit、push 和開 PR。
| 指標 | 數值 |
|---|---|
| Pull request 數量與 session 數量 | 13 個,10 個 session |
| 每個 PR 佔五小時視窗 | 約 6% |
| 單一 PR session 佔每週計數器 | 約 1% |
| 使用 subagent 時每個 PR 的估計成本 | $2.31 |
| 只用 Opus 時每個 PR 的估計成本 | $3.59 |
| 每個 session 的請求數(之前與之後) | 75 到 54 |
| 每個請求的 token 數(之前與之後) | 119,000 到 107,000 |
他自己的那句話才是重點:如果把 subagent 的 token 按 Opus 的價格計算,這十個 session 只會貴 5%。省下來的部分來自主 context 保持很小。一個月的紀錄從另一邊說了同樣的事:subagent 用掉 48.1% 的 token,而所有 token 的 96% 是快取讀取。每個 subagent 一開始都有一個啟動 prompt;在這個帳號上,中位數是 47,000 token,不管工人是 Opus、Sonnet 還是 Haiku,都是同一疊內容。換模型並不會讓它變小。
effort 確實會改變食量。以小功能來說,中等 effort 的 Haiku 在 14 輪中讀了 233,000 token;低 effort 的 Haiku 在 8 輪中讀了 140,000 token,得到同樣被接受的結果;Opus 只需要 88,000。一次獨立的測試在更高的位置量到同樣的曲線:high effort 下每個任務 55,000 個輸出 token,max 下是 162,000。每個 token 便宜,每個任務卻更能吃,而這個旋鈕在你手上。兩點保留:Grandi 的金額是 Pro 方案上的估計,這裡的矩陣只用了一個小專案。兩者都不等於在 Max 方案上跑一個星期。
路由表、限制與資源包
路由表:探索程式碼、修正失敗的測試、清掉 lint、寫 commit 訊息、加一個小功能、審查 diff、總結架構。這七個全部交給低 effort 的 Haiku 5.5,在低與中等 effort 下各有 70 次執行中的 70 次被接受。每個任務的牌價落在五分之一美分到半美分之間,而 Opus 是六到十七美分。留在 Sonnet 或 Opus 的,是複雜的 agentic coding,這是 Anthropic 自己的話,Terminal-Bench 給 Haiku 的分數是 39.2 對 70.6;發布當時唯一被測試過的評論也以同一句話收尾:困難的程式碼工作請留在 Sonnet。
兩個檔案就放在這張表旁邊:帶有完整 Haiku 模型 ID 和低 effort 的 Explore agent 檔,以及帶有 subagent 模型和 force 旗標的 settings env 區塊。檢查方式是 /tasks 指令,它會顯示每個 subagent 實際用的模型。請相信那一行,而不是檔案。
回到一開始的問題。把每個 subagent 都改成 Haiku,用量表會還給你什麼?對一個有範圍的任務來說,在任何模型上都不到一個百分點。整個 182 次執行的矩陣,讓五小時視窗動了兩個百分點,每週視窗動了零。真正的一週額度,是從主 context 和每個 subagent 帶著的啟動 prompt 裡回來的。換模型只是便宜的那一部分,而且可以免費拿。
| 限制 | 說明 |
|---|---|
| 專案 | 一個小專案,tinydb,226 個測試 |
| 任務大小 | 七個有範圍的任務,每個不到一分鐘,不是一整天的 agentic coding |
| 用量表 | 解析度一個百分點,每個區塊正負一個百分點 |
| 倍率 | Anthropic 沒有公布各模型的倍率 |
| 版本 | 2026 年 10 月 8 日的 Claude Code 2.1.293;更早的版本會忽略 agent 檔裡的模型(公開的 issue) |
免費資源包裡有路由表、兩個檔案,以及量出這些結果的測試工具:七個 prompt、檢查程式和執行器。
