派工 subagent 的節省來自報告壓縮與模型價差，不是派工本身

把工作丟給 subagent 不會自動變便宜。省下來的錢有兩個來源：subagent 跑在更便宜的模型上，以及它把大量中間輸出壓縮成一段摘要回報。兩個都沒有的話，派工反而更貴。

2026 年 10 月的實測（cedars:usage-report §4，orchestrator 全程是 opus）：

agentType	subagent 實際跑的模型	派工數	估計節省
general-purpose	opus	148	-$199.65
general-purpose	sonnet	41	+$674.98
cedars:executor	opus (upgrade)	9	-$11.78
cedars:executor	sonnet	7	+$49.89

同一個 role，只差在跑哪個模型，結果一個虧 $200一個省$675。全月 220 次派工裡有 158 筆是負節省。

原因是派工的成本結構：

dispatch_cost = subagent 自己的花費 + orchestrator 讀回報告的成本
inline_cost   = 同一批 usage 改在 orchestrator 模型上跑（扣掉派工 prompt 與 role 基準開銷）
savings       = inline_cost - dispatch_cost     ← 允許為負

當 subagent 和 orchestrator 同模型時，inline_cost 和 subagent 自己的花費 幾乎相等，省不到價差；但 dispatch_cost 還要多付一筆 orchestrator 讀回報告的錢，所以結果必然是接近零或略負。

另一半來自壓縮比 report_tok / intake_tok：subagent 讀進一大堆東西、只回報一小段摘要，那些中間輸出就不會留在主線 context 裡被反覆重付。壓縮比接近 1（讀多少就回報多少）的派工，基本上就是負節省的候選。

實務結論：派工要搭配降模型。讓讀取密集但不需要高智能的工作跑 sonnet / haiku，orchestrator 留在 opus 做判斷與整合。opus-pinned 的 role 無差別派工是在燒錢。

相關：Agent 的成本主要在每輪重讀 context，不在輸出、我的多 agent 產線：文件是交接介面，agent 之間互相審查、Review 要用沒生成過這段 code 的 agent