前言
平常我都沒多想，直接用 Opus 跑 Claude Code，但切換到期間限定可用的 Fable 5 之後，token 的消耗比想像中還要兇猛。
因此，我改成只在設計、審查等重要度較高的部分使用 Fable，其餘部分則交給 Opus。
重點是「不要在 skill 裡寫模型名稱」。
只要這樣做，即使 Fable 的使用期間結束，也能很容易切換，維護性也會提升。
這次就來整理一下這個設定方法。
考量方式
這次我打算把 subagent 分成 judge（審查／驗證）/ builder（實作）/ worker（調查／擷取）三種角色 + 主 session，並依照角色分配不同的模型。
| 層級 | 負責模型 | 主要工作 |
|---|---|---|
主體 + judge |
Fable | 設計、規劃、審查、驗證（誤判會導致事故的部分） |
builder / worker |
Opus | 實作、調查、全面擷取（大量處理是瓶頸的部分） |
大部分 token 都會消耗在平行展開的調查類管線與實作上，所以只要把那一側交給 Opus，就能讓 Fable 的消耗集中在「思考、判斷」的部分。
設定方法
1. 在 .claude/agents/ 定義角色
每個角色只要放一個 md 檔案即可。frontmatter 裡的 model: 就是模型設定的來源。
<!-- .claude/agents/worker.md -->
---
name: worker
description: 負責調查與全面擷取的執行角色
model: opus
---
忠實遵循收到的指示，並為事實附上根據（file:line）後回傳。builder.md（實作角色，model: opus）也用相同格式建立。
這次只有 judge.md 沒有寫 model:。
未指定模型的 agent 會繼承主 session 的模型，因此我讓它能在切換 /model 時，judge 也自動跟著變更。
2. skill 端只寫角色名稱
並列 dispatch 各觀點（subagent_type: worker）
並列啟動 3 個審查者（subagent_type: judge）
啟動實作 agent（subagent_type: builder）skill 裡完全不需要知道模型名稱。
3. 切換模型
只要修改各個 md 的 model: 就能切換模型。
另外，主體 + judge 也會透過 /model 指令切換。
優點
- 維護性：模型名稱不會散落在 skill 裡，所以不管增加多少條 skill，模型變更都只要 1～3 個地方就能完成
- 通用性：因為是「判斷管線與大量處理管線之間拉開一級差距」這種相對規則，所以無論是 fable+opus+sonnet，還是下一代模型+opus+sonnet，都能沿用同樣的設計。
總結
這次是為了更有效率地運用 Fable 而做的設定，但我也覺得，依角色來分配模型的機制本身，在未來持續運用 AI 的過程中，先設好絕對不吃虧。
如果你想用 AI 大量進行多工處理，或正在為 Fable 的 token 消耗而煩惱，不妨試試看。
參考
在株式會社 Cynthia，我們會招募沒有實務經驗的工程師，以及學生工程師實習生，並一起工作。
※ 關於 Cynthia 的工作方式，可以參考這裡：
在 Cynthia，每年大約有 100 位沒有實務經驗的人提出申請並參加技術面試。透過這些經驗，這裡會介紹希望實務未經驗者務必掌握的技術力（語法）。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
