這支影片在講：模型路由不是找「最便宜」的模型
Agent 的任務會變形：從讀 codebase、寫功能到線上除錯。一次性選定模型很脆弱；更可靠的設計是讓強模型規劃、把可拆的工作委派出去，並用上下文、快取與失敗訊號持續調整。
靜態分流會失靈
某模型在 benchmark 表現好，不代表它能承受整段 agent session。任務一旦跨出訓練分布，工具迴圈與重試可能讓小模型更貴。
便宜不是 token 單價
對談舉例：Opus 的 terminal bench 成績約為 Haiku 的三倍、成本卻約十分之一；關鍵是避免低能力模型無止盡地摸索。
把路由放進工作流
以 frontier model 規劃與委派、維持熱快取、在能力不足時升級或改路徑；模型選擇成為執行中的控制迴路。
四個改寫成本模型的訊號
路由系統常犯的三個錯
把 benchmark 勝率當成執行策略
「這類任務用 A、那類任務用 B」在單輪問題或許成立；但 agent 的工作會改變性質。開始時是詢問 codebase，稍後可能是修改、測試與 production debugging，起始選擇未必還適用。
只看每 token 價格，忽略失敗迴圈
小模型被推到能力邊界時，可能反覆叫工具、走錯分支，再把更多 token 花在修正。路由評估要納入完成任務所需的重試、工具呼叫與人工介入。
為省錢過早壓縮上下文
壓縮會造成 cache miss，並可能讓品質在理論上的百萬 token 窗口前就明顯下滑。影片主張，compaction 應優先為保持推理品質而做，而非只為縮短帳單。
影片提供的可行架構
規劃模型先界定目標、風險與可委派工作；實作者可平行探索，讓較低成本的推理換取更多搜尋廣度。
不是每件事都適合拆成子 agent。連續上下文可保留 KV cache，避免每次切換都重新支付理解 codebase 的成本。
把不確定性、重試模式、工具失敗與品質訊號當成升級或改路由的觸發器，而非等到整個任務失敗。
OpenRouter 的案例顯示，同一 app 也可能同時有低成本 heartbeat 與高 intelligence 請求；產品層的使用模式決定路由真正要解的問題。