歷史文章：本文保留這一代 Codex 的模型分工方式。模型名稱與現行調度方式後來已有更新，正文只談這套設計本身。
「第一代模型分工」是本文的整理名稱，不是 OpenAI 的正式版本名稱。文中把 GPT-5.4 負責 planning、coordination 與 final judgment 的位置簡稱為 manager，只是為了比較好描述角色。
做一個 authentication refactor，前半段常常根本還沒開始「設計」。先找 session 在哪裡建、permission check 散在哪些檔案、哪些 tests 已經覆蓋到現有行為。這些工作不難下架構決策，卻很吃時間和 context。
資料找齊之後，難題才出現：新的 boundary 放哪裡？舊 API 要不要留？哪一段先改比較安全？
再往後，如果架構早就定了，只剩 UI 邊看邊調，使用者等的又不是更深的 reasoning，而是下一個 edit 什麼時候回來。
三段都叫 coding，但其實在燒不同東西。
Codex App 當時已經能讓多個 agent 在不同 thread 和 worktree 平行工作。[4] GPT-5.4、GPT-5.4 mini 與 GPT-5.3-Codex-Spark 剛好把這種差別照得很清楚。[1][2][3]
Figure 1｜別先問哪顆模型「比較高級」，先看這一步到底卡在判斷、吞吐量，還是人在等。
Mini 很適合做那些做完就能交件的工作
OpenAI 對 GPT-5.4 mini 的定位很直接。較大的 GPT-5.4 留著做 planning、coordination 與 final judgment；mini subagents 則去處理 codebase search、大檔 review、supporting documents 這類比較窄、可以平行完成的工作。[2]
回到 authentication refactor，可以拆成：
- 找出 session 建立與銷毀的位置
- 把 permission checks 出現在哪些檔案列清楚
- 整理現有 tests 覆蓋到哪些路徑
- 把相關 config 和 supporting docs 摘成短報告
我會把這些交給較小 worker 的原因，不是「它們不重要」，而是完成條件很好講。
worker 不需要決定整個 refactor 要怎麼設計。它只要把指定範圍掃完，交回一份可以檢查的結果。
GPT-5.4 mini 當時在 Codex 只使用 GPT-5.4 30% 的 quota；OpenAI 也把它描述成大約三分之一成本的 simpler coding path。[2]
這個 30% 是 Codex included-limit / quota 的說法，不是 API 帳單保證省 70%。API token pricing 是另一套計算。比較實際的影響是：原本開三、四條 supporting work 會覺得太貴，現在有了一個比較便宜的 worker tier。
Spark 是給「我正在看畫面，下一輪快點回來」的地方
同一個 refactor 做到 UI 微調，工作形狀會突然變得很不一樣。
按鈕往右一點、hover 慢一點、某個小 logic 改完直接給我看。這時候使用者人就在畫面前，模型如果每輪都慢半分鐘，體感差很多。
Codex-Spark 就是沿著這個問題設計。OpenAI 把它定位成 real-time coding model，在 ultra-low-latency hardware 上可以超過 1,000 tokens/s。research preview 首發是 128k context、text-only，而且用獨立 rate limits。[1]
它的行為也很符合這種工作。Spark 傾向做 minimal、targeted edits，而且除非你要求，不會每次修改後都自動把 tests 全跑一輪。[1]
所以我會把它放在「人正在盯著結果」的 loop 裡，而不是拿它來證明完整 regression 已經做完。
OpenAI 當時也不只加快模型輸出。官方公開的改善包含 client/server roundtrip overhead 減少 80%、per-token overhead 減少 30%、time-to-first-token 減少 50%，另外還有 persistent WebSocket 等調整。[1]
這也提醒一件很容易忘的事：人真正等的是整條路，不是只有 tokens/s。Prefill、generation、tool execution、network、harness overhead 都會算進體感。
Spark 可以讓 feedback loop 變短，但 edit 回得快，跟 correctness 是兩件事。跨很多檔案的修改、完整 regression、長時間 autonomous work，該跑的 verification 還是要跑。
最難的工作通常在 worker 回來之後
假設三個 mini subagents 都交件了：一份 session map、一份 permission review、一份 test coverage。
這不代表 refactor 已經設計完。
三份結果可能互相衝突，也可能一起指出某個原本沒想到的 compatibility constraint。最後還是有人要判斷哪些 finding 會改變設計、哪一段先做，以及要不要保留舊 path。
OpenAI 在 GPT-5.4 mini 的發布說明裡，明確把 planning、coordination 和 final judgment 留給較大的 GPT-5.4。[2] GPT-5.4 本身也被定位在複雜 professional work、tool use 與較長的 agentic workflow。[3]
Figure 2｜Mini 幫 manager 把 bounded work 做掉；Spark 則留在另一條人類即時互動的 lane。
GPT-5.4 manager
├── Mini subagent: session / auth code search
├── Mini subagent: permission review
├── Mini subagent: test coverage review
└── reconcile findings → choose design → order changes
Human + Spark
└── rapid local UI / logic refinement這張圖最重要的一點是：Spark 不是 Mini hierarchy 裡的下一層 worker。
Spark 是另一條 interactive lane；GPT-5.4 + mini 才是 manager-worker 的分工。把它們硬接成同一條 hierarchy，反而會多講出來源沒有支持的 orchestration 關係。[1][2]
多開幾個 worker，不一定代表真的比較省
Fan-out 最容易騙人的地方，是畫面看起來很忙。
三個 subagents 同時跑當然是平行，但如果三個人都讀了差不多的 context，最後又交回三份內容高度重疊的報告，manager 還是得把它們重新整理成一份能做決定的東西。
平行沒有失敗，只是系統做了更多重複工作。
另一個常見錯誤，是看到 mini 在某些 benchmark 已經很接近大模型，就把 judgment 一起下放。GPT-5.4 mini 在部分 coding evaluations 確實接近 GPT-5.4，但不同 evaluation 的差距不一致，OpenAI 自己仍把 planning、coordination 與 final judgment 放在較大的模型端。[2]
Benchmark 接近，可以支持「這個 bounded task 值得試」。它沒有直接推出「兩個角色可以完全互換」。
RouteLLM 和 FrugalGPT 這類研究處理的其實也是類似問題：不是每個 query 都值得付最高模型成本，而是要看 quality / cost trade-off，甚至用 cascade 處理。[5][6]
放到 agent workflow 之後，routing 的單位可以更小。不是「整個 user request 選哪顆模型」，也可以只是其中一個 subtask。
我會先看這一步到底在花什麼
不需要先做一個 router service 才能開始分工。
如果要做的是搜 repo、讀幾個大檔、整理 supporting docs，而且 done 很清楚，mini 很合理。
如果幾路結果互相打架，要選 implementation，讓較大的模型收斂。
如果人正盯著 UI，每輪只改一點，Spark 的低延遲才真的有價值。
最簡單的防呆反而不是模型規則，而是這一句：subtask 的「done」講不清楚，就先不要 fan-out。
worker 越多，只會更快產生一堆需要重新理解的半成品。
模型名稱會換。比較值得留下來的是這個習慣：先看工作本身卡在哪裡，再決定哪一段需要判斷、哪一段可以平行處理、哪一段只是人不想等。
References
- OpenAI, Introducing GPT-5.3-Codex-Spark, 12 February 2026.
- OpenAI, Introducing GPT-5.4 mini and nano, 17 March 2026.
- OpenAI, Introducing GPT-5.4, 5 March 2026.
- OpenAI, Introducing the Codex app, 2 February 2026.
- Ong et al., RouteLLM: Learning to Route LLMs with Preference Data, 2024.
- Chen, Zaharia & Zou, FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, 2023.