pacing-guard Agent-spawn advisory：dispatch model 建議應為 opus>sonnet>haiku 階梯（依剩餘 budget 與 task 難度），非一律 sonnet/haiku

[kiki830621]

Problem

Original text（使用者於 Fable 5 session 開 Explore subagent、看到 advisory 後的即時回饋，2026-07-21）:
「應賅opus>sonnet>haiku， 可能要看剩餘的token和多少，還有task容易的程度，因為haiku可能太爛，除非是很簡單的事情」
— Source: 使用者直接貼上（含觸發畫面）

觸發畫面（使用者貼上的實況，即 v1.13.0 #21 F5 的 fable-aware Agent-spawn advisory）：

⏺ Explore(盤點文獻工具現況)
PreToolUse:Agent says: [claude-hot-limit] ℹ️ Fable 5 session 開 Agent。沒 pin model 的 subagent 會繼承 fable5（頂階/貴），且跑起來的 main-loop 消耗連本 guard 都看不見（#24）。建議把 Agent 的 model 參數 pin 到便宜 model（sonnet/haiku）。多個並行 Agent 的爆量由 burst guard 擋。

解讀：現行 advisory（plugins/claude-hot-limit/hooks/pacing-guard.py:920-921）把「sonnet/haiku」並列成無差別的「便宜 model」選項。使用者指出這不該是二元的「fable vs 便宜」，而是一個 capability 階梯 opus > sonnet > haiku，實際建議哪一階應考慮兩個輸入：

1. 剩餘 token budget：quota 還很多時，pin opus 是合理選擇（比 fable 便宜一階、能力仍高）；quota 吃緊才往 sonnet / haiku 降。
2. task 難度：haiku 能力可能不足（「可能太爛」），只適合很簡單的任務；把難 task 派給 haiku 會產出品質不足 → 重跑反而更耗 token。

Type

feature（advisory 內容 / 邏輯強化）

Expected

Advisory 呈現「階梯 + 決策準則」而非單一固定建議：

• 建議文案改為 capability 階梯（opus > sonnet > haiku）＋ 兩個挑選準則（剩餘 budget、task 難度）。
• 有 rate-state 官方水位資料時（Phase 1 觀測：rate-limit header 在 production 完全沒抓到（0/1134 筆），疑 streaming 路徑擷取缺口 — 卡死 #7 gating #12 翻案後 proxy 已擷取 anthropic-ratelimit-unified-* utilization；burn-rate 事前警示：token/請求消耗速率過快的 leading indicator（撞牆是 lagging） #25 的 rate_state_heat() 水位語意），advisory 可依 5h utilization 動態調整預設階：utilization 低 → 「可考慮 opus」；utilization 高 → 「建議 sonnet，非常簡單的任務才 haiku」。
• task 難度是 LLM-side 判斷（hook 靜態只看得到 Agent prompt 文字，無法可靠分類難度）→ hook 提示決策準則即可，挑階的決定留給 main-loop model 與使用者（同 pacing-guard 顯示 Workflow fan-out agent 數 + 依數量建議 opus/sonnet dispatch（sibling of #18） #19 doctrine「hook 只能顯示，決定在 doctrine + 使用者手上」的分工）。

Actual

• 一律建議「pin 到便宜 model（sonnet/haiku）」：兩者並列、無階梯概念，不看剩餘 budget、不看 task 難度。
• 對非簡單 task 照建議 pin haiku 會太弱；對 budget 充裕的 session，建議裡完全沒有 opus 這個選項，過於保守。

Impact

• Advisory 建議不夠可信 → 使用者要嘛忽略它（advisory 失效），要嘛照做選了過弱的 model（subagent 產出品質不足 → 重跑，總 token 消耗反而更高，與 pacing 目標背道而馳）。
• 同一準則也影響 doctrine 層（user CLAUDE.md「Workflow fan-out — 依寬度選 dispatch model」與 pacing-guard 應擋「Fable 5 session 開 Workflow」（fable5 + 寬 fan-out = 必炸；hook 機制已備、缺 fable 辨識 + deny 分支） #18 Workflow deny 訊息的建議文案）——本 issue 以 hook advisory 文案 / 邏輯為主，doctrine 同步屬 follow-up。

Refs

• fable×Workflow gate — F5/F7/F8/F10 (6-AI verify follow-up of #18) #21 — F5：fable-aware Agent-spawn advisory 誕生處（F7 / F8 / F10 residue 仍 open）
• pacing-guard 覆蓋面缺口：main-loop coordinator burn — PreToolUse hook 結構上看不到 fable 消耗 #24 — main-loop 消耗不可見的脈絡；(b) SessionStart nudge
• roadmap: per-model 門檻（各 model 桶設不同 MAX / MIN_GAP / FANOUT_WIDE_MIN） #23 — per-bucket 門檻 roadmap：若 advisory 要吃 utilization 門檻，設定單位依 .claude/rules/per-bucket-settings.md 以桶為 key
• burn-rate 事前警示：token/請求消耗速率過快的 leading indicator（撞牆是 lagging） #25 — 已結案；官方水位訊號（rate_state_heat() 語意）＝「剩餘 budget」的現成資料來源

---

Priority: P3（推定 — 使用者未指定；enhancement、無立即壞損，且動態水位部分 gated on 設計討論。如需提前請調整。）

Clarity Surface(idd-clarify run 2026-07-21T05:40:19Z)

Type	Source	Suggested canonical	Status
ambiguity	"可能要看剩餘的token和多少"	「剩餘 budget」未指明 rate-limit 窗：unified 有 5h / 7d / 7d_oi 三個 scope（本 body Expected 段暫以 5h utilization 為詮釋，實作前需確認；per-bucket 單位依 #23）	surfaced
missing-context	"還有task容易的程度，因為haiku可能太爛"	task 難度的判準／分級方式與判斷者未指定（hook 靜態無法可靠分類；body 暫定 delegation 給 main-loop model 與使用者，屬 AI 詮釋、需 user 確認）	surfaced