Apr 25, 2026

自動切換模型聽起來很聰明，直到你看到 cache 帳單

中文 EN

朋友丟給我 opencode.ai/zen 的連結，問了一句：「他這個會自動換模型嗎？」

答案是不會。OpenCode Zen 只是一個精選模型的 gateway，你在 TUI 用 /models 自己挑。然後話題就跑到下一個問題：「那有沒有產品真的會自動切？理論上應該更智能、更省錢吧？」

直覺上是對的：簡單問題丟 Haiku，難的丟 Opus，平均下來省個 60–80%，誰不要。但 2026 年的現實沒這麼浪漫。auto routing 是一個 2023 年的好想法，撞上 2026 年的 prompt caching 經濟學，整個算盤要重算。

先把名詞釐清：本文說的「auto router」指的是根據 prompt 內容、用 ML 分類器判斷送哪個模型的服務（OpenRouter Auto、Martian、NotDiamond、RouteLLM 那一類）。這跟 Portkey、Helicone、Kong 這種「按規則 fallback / load balance」的 conditional router 不是同一件事——後者第三節會專門講。

下面分七個段落講：算給你看的成本、市場上誰真的在做、coding agent 採用了什麼模式、什麼情境下這件事真的划算、swyx 的吐槽、實務 cheatsheet。

一、路由派的口號，和它沒講的那一段

路由服務的銷售話術差不多都長這樣：

"20–97% 成本下降，品質持平甚至提升。把簡單的 prompt 路到 Haiku/Mixtral，把難的留給 Opus/GPT-5，平均下來大幅省錢。"

Martian 講「20–97%」，NotDiamond 講「30–90%」，Adaptive 講「60–80%」。這些數字不是亂掰的，在特定 benchmark 組合下打得出來。問題是這些 benchmark 大多是 stateless 的單次推理：MT-Bench、MMLU、GSM8K，每個 prompt 互相獨立，沒有重複的 system prompt，沒有累積的對話脈絡。

這跟 2026 年絕大多數人實際在用 LLM 的情境，差非常遠。

你打開 Claude Code、Cursor、Cline，每一個 turn 的 input 大概長這樣：

30k+ tokens 的 system prompt + tool definitions + 專案 context
1k tokens 的使用者 input
2k tokens 的模型 output

那 30k 的 prefix 在 turn 與 turn 之間是不變的。所有主流 provider 都意識到這件事，從 2024 開始陸續推出 prompt caching：

下表所有費率都是相對於 base input 價的倍數：

Provider	Cache 寫入	Cache 讀取	TTL
Anthropic Opus 4.7 / Sonnet 4.6	1.25× input (5m) / 2× input (1h)	0.1× input（省 90%）	5m / 1h
OpenAI GPT-5 系列	input	0.1× input（省 90%）	~5–10m
Gemini 2.5 Pro	input	0.1× input（省 90%）	implicit
DeepSeek V3.2/V4	input	0.1× input（省 90%）	disk-based

四家收費結構基本一樣，cached read 都是 base 價的 10%。意思是：如果你的工作流程有大量重複 prefix，cache 一打進去，input cost 直接砍九成。

關鍵的兩個字：per-model。Anthropic 的 cache 不會共享給 OpenAI；連 Anthropic 自己內部，Opus 跟 Sonnet 的 cache 也是獨立的。你只要切模型，cache 就作廢，下一個 turn 從零重新寫入。

這就是路由派的銷售話術沒講的那一段。

二、算給你看：20 個 turn 的 coding session

設定：30k tokens 的 prefix，每個 turn 1k input + 2k output，跑 20 個 turn。用 2026 年 4 月的價格。

情境 A — 一直用 Opus 4.7（input $5/M、output$ 25/M、cache write 5m $6.25/M、cache read$ 0.50/M）

Turn 1（cache 寫入）：30k × $6.25/M + 1k ×$ 5/M + 2k × $25/M =$ 0.243
Turn 2–20（cache 命中）：19 × (30k × $0.50/M + 1k ×$ 5/M + 2k × $25/M) = 19 ×$ 0.070 = $1.33
總計：$1.57

情境 B — 一直用 Sonnet 4.6（input $3/M、output$ 15/M、cache write $3.75/M、cache read$ 0.30/M）

Turn 1：30k × $3.75/M + 1k ×$ 3/M + 2k × $15/M =$ 0.146
Turn 2–20：19 × (30k × $0.30/M + 1k ×$ 3/M + 2k × $15/M) = 19 ×$ 0.042 = $0.798
總計：$0.94

情境 C — auto-route（假設一個常見配比 60% Sonnet、30% Opus、10% Haiku 4.5，並且 router 沒做 cache 黏滯處理）

獨立抽樣下，相鄰兩個 turn 落在「不同模型」的機率約 1 − Σpᵢ² = 1 − (0.36 + 0.09 + 0.01) = 0.54。19 個 follow-up turn 估個 ~10 個切換是合理的，文中為了說明用 12 取個保守值，每次切換等於要在新模型上重寫一次 prefix。

切換 turn 的均成本：30k × 加權平均 cache write rate（0.6 × $3.75 + 0.3 ×$ 6.25 + 0.1 × $1.25 =$ 4.25/M）= $0.128 prefix 重寫，加 ~$ 0.04 I/O（按各模型配比加權的 1k input + 2k output 平均）≈ $0.168
12 個切換 turn：12 × $0.168 =$ 2.02
8 個非切換 turn：8 × $0.05 =$ 0.40
加 turn 1 冷啟動 ~$0.15
總計：~$2.57

整理一下：

策略	20 turn 成本	相對 Sonnet baseline
一直用 Sonnet 4.6	$0.94	1.0×
一直用 Opus 4.7	$1.57	1.7×
天真 auto-route	$2.57	2.7×

auto-route 不只沒省錢，還比一直開 Opus 更貴。為什麼？因為「Sonnet 取代 Opus」省下的那 $0.04 / turn，被「prefix 重寫一次」付的$ 0.13 / turn 吃乾抹淨。

這個算術只在兩種情況下會翻轉：

Prefix 很短（<5k tokens），cache 重寫沒什麼成本
Router 做了 cache stickiness（同一段對話盡量黏在同一個模型上），但這樣它的「智能切換」價值就削弱了

順便附帶一個冷知識：Anthropic 在 2026 年 3 月初把 Claude Code 預設的 cache TTL 從 1 小時縮回 5 分鐘，社群為此寫了個 claude-code-cache-fix 來反制，README 記載某些 long resumed session 的成本被顯著拉高（一個量級以上）。Cache 是現在 LLM 成本最大的單一槓桿。

三、誰真的在做 auto-routing？市場現況

TL;DR：12 個被獨立 benchmark 過的路由器裡，最佳實際結果是 ~35% 省、<2% 準確率下降，遠低於行銷話術的 60–97%。商業路由全面輸給開源路由。

掃完一輪 2026 年 4 月還活著的玩家：

OpenRouter openrouter/auto — 真路由，路由引擎是 NotDiamond。0% 路由費，你只付目的地模型的價錢。但 OpenRouter 從來沒承諾「省錢」——它的定位是 quality routing，不是 cost optimizer。當前流量分布大致是 Gemini 2.5 Flash Lite 32%、Opus 4.6 21%、GPT-5 Nano 17%。

Martian — 真的 task-aware 路由，用一套叫「Model Mapping」的可解釋性技術預測模型表現。 $9M 融資、Accenture 投資，2026 年 4 月有 Medium 文章傳估值接近$ 1.3B（單一二手來源，未經官方證實）。價格：每 5,000 次 $20，外加模型本身的費用。

NotDiamond — 不是 gateway，而是回傳一個「應該用哪個模型」的 API recommendation，由你 client-side 執行。決策延遲 10–100ms，SOC-2/ISO 27001。但獨立 benchmark RouterArena（arXiv:2510.00202，2025 年 10 月）把它排在 12 個路由器的最後一兩名（paper 文字寫 #12，表格落在 #11），原因是它「frequently selects expensive models」——引擎偏向品質，幾乎不省錢。

RouteLLM（LMSys 開源） — 學術界的標準 baseline。原 paper 號稱在 MT-Bench 上省 85%、MMLU 省 45%，前提是 router 用 Chatbot Arena 偏好資料訓過。實際部署很少，多停留在研究與業餘專案。

Unify AI — 從 LLM router 轉型成房產業 AI 同事，原本的 router 產品線實質終止。原團隊在 2025 年轉型，但很多列表還會列他們。

Portkey、Helicone Gateway、Kong AI Gateway、Requesty — 全部是 conditional routing 而不是 ML routing。意思是「if model=fastest → gpt-4o-mini」這種 rule-based 規則路由，搭配 fallback、load balancing、retry。它們不會根據 prompt 難度自動換更強或更弱的模型。這跟「真路由」是兩件事，但常被混淆。

OpenCode Zen — 確認沒有 auto。是策展型 marketplace。

那 RouterArena 的真相是什麼？這是迄今最誠實的獨立 benchmark：12 個路由器、跨領域、分難度級別。結論：

最佳實際結果：~35% 成本節省，<2% 準確率下降（vLLM-SR、CARROT 並列）
跟行銷話術裡的 60–97% 差很遠
商業路由全面輸給開源路由
所有路由器都低估了便宜模型的能力——也就是 production router 都偏保守

學術 paper 也指出，最強的 ensemble router 對 oracle 的相對誤差大概是 19%——每 5 個 routing 決定大概有 1 個會被選錯。錯一次在 stateless 場景裡只是「重 prompt 一次」；錯一次在 coding agent 裡是「弱模型答錯 → retry → cache 又作廢一次」，雙倍付。

四、Coding agent 採用的真正模式：顯式角色分工

那 coding agent 到底怎麼處理多模型的問題？答案不是「自動」，是 explicit role-based pinning——把不同角色綁死在不同模型上。

Claude Code 的 subagent + opusplan

Anthropic 把「每個 subagent 綁不同模型」做成一級公民。每個 subagent markdown 檔可以在 frontmatter 寫 model: opus|sonnet|haiku|inherit|<model-id>。內建的 Explore subagent（read-only、只能 Read/Glob/Grep）預設跑 Haiku，「optimized for speed and cost」。這是 2026 年最普及的真實世界模型路由模式：讀取類雜活丟 Haiku，編輯類重活丟 Sonnet/Opus，由 Opus parent 統籌。

另一個 Anthropic 預先打包的模式叫 opusplan：plan mode 用 Opus、execution 用 Sonnet，自動切換不需要手動 /model。Claude Code v2.0.0 一度移除，社群在 GitHub 上開了 issue #8358 抗議。這是目前唯一被 Anthropic 官方 endorse 的 per-turn auto switch 模式，但範圍非常窄——只切 plan vs execute 兩種狀態。

Aider 的 architect / editor pattern

Paul Gauthier 的這個 pattern 是整個成本論證最漂亮的範例。架構師模型負責推理改動，編輯器模型負責輸出 diff 格式。當前在 Aider polyglot benchmark 上的 SOTA 是 **R1（架構師）+ Sonnet（編輯器），分數 64.0%、跑完整套 benchmark 要 $13.29**。對照組：o1 單跑 61.7%、要$ 186.50。14 倍便宜，分數還更高。

為什麼有效？編輯是機械活——套 diff、follow format。一個指令遵循能力強的便宜模型，會贏過一個被迫在 token 上付推理稅、卻沒地方用上推理力的前沿模型。架構工作則完全相反。

Cursor Auto — 唯一真在做 per-turn auto-routing 的主流 coding agent

Cursor 2.0 內建自家的 MoE 模型 Composer 2 當 Auto 預設（CursorBench 61.3、輸出 200 tok/s——CursorBench 是 Cursor 自家 benchmark，跨 SWE-Bench 對照下沒這麼亮眼），其他候選是 Sonnet 4.5、Opus、GPT-5.4、Gemini 3。Auto mode 從 2025 年 6 月起在所有付費 plan 都不限量，手動選模型才會吃額度——意思是 Cursor 自己在做成本套利，而不是把省下來的錢給你。

但 2026 Q1 的 Cursor 論壇被 Auto 模式吐槽淹沒。

"Auto mode 變得糟糕到實際上沒辦法用了"——3 月，forum thread

"一個 Auto 模式 prompt 燒掉了我 Ultra plan 70% 的額度——因為 verification loop 把 Opus 重複叫了兩次"——另一篇

第二個 thread 抓到的就是 routing 失敗的典型形狀：弱模型接到難 task → 重試 → escalate 到 Opus → 你雙倍付錢。

其他 coding agent 的選擇

Aider：沒有 aider --auto。--main-model 跟 --editor-model 是顯式 flag。
Cline / Roo Code / Kilo Code：用 named modes（Architect / Code / Debug / Orchestrator），每個 mode 綁一個模型。
Continue.dev：用 roles（chat / autocomplete / edit / apply / embed / rerank / summarize），每個 role 配一個模型。
Cody / Continue：手動，per-task 選。

整個 ecosystem 講得很一致：顯式角色綁定贏，學習式 routing 沒進到主流 coding agent。

五、那 auto-routing 在哪裡真的有用？

不是沒有。它的最佳場景非常明確：無狀態、高量、prefix 沒有重用價值的 traffic。

清楚會贏的場景：

Stateless API traffic：分類、moderation、單次摘要、FAQ bot。一個 e-commerce 站點每天跑 50k 次「請判斷這段評論是 positive/neutral/negative」，95% 用 Haiku 就夠、5% 諷刺型語句送 Sonnet——沒有 cache state 可以失去，prompt 又短，路由器報的 30–65% 省錢會乾淨地實現。
大量客服 / 半結構化問答：使用者問題多樣、prefix 共用比例不高。搭配 semantic dedup cache，混合策略確實有人跑出 50–65% 節省。
異質性極高的 multi-tenant API：你做一個 LLM API for 開發者，客戶 A 在做翻譯、客戶 B 在做 code review、客戶 C 在做摘要——每個 call 的 prefix 本來就不一樣，cache 從來就不會命中，那 router 拿來分配模型就是純贏。

清楚會輸的場景：

長 context coding agent（Cursor、Claude Code、Cline、Aider）：20–100k tokens 的 prefix 必須 cache 黏住。任何 routing 動作都會打掉最大的成本槓桿。
大 RAG 檢索：每個 turn 都會把同一批 retrieved chunks 灌進 context，跨 turn 高度重複——一旦切模型整批重新算 embedding 跟 cache。
Multi-turn 結構化輸出 agent：tool definitions + system prompt 動輒 10k+ tokens 的場景，每個 turn 都共用同一個外殼。

六、swyx 的吐槽，和 Greenspun 第十法則

最尖銳的反對意見來自 swyx，2024 年 11 月的這條 tweet 之後一直被引用：

"stop adding these to your codebase!! 大家都喜歡『先簡單做』然後讓這些 model maps 慢慢演化。每一步都很好走。但隱藏的成本會找上門——你會獨立重新發明前面 200 個人都走過的同樣 200 步。

Inside every non-trivial AI App is an ad hoc, informally-specified, bug-ridden, unreliable implementation of a proper model router."

這是 Greenspun 第十法則的延伸（「每個夠複雜的 C 程式裡都包了一個半成的 Lisp」）。兩層意思：不要自己 roll，但也不要假裝一行 if complex: use_opus 是工程。

Paul Gauthier 的立場更務實：「開發者自己知道這個 task 是 reasoning-heavy 還是 edit-heavy，router 不該是個 classifier，它應該是你的 make target。」

Simon Willison 走中道——他的 Agentic Engineering Patterns 裡很支持積極使用 coding agent，但他自己的所有 writeup 都是一個 session 用一個 model，要換就手動換。

七、實務上你可以做什麼

如果你今天在挑工具或設計 agent 系統，這是我整理出來的 cheatsheet：

Coding agent：選一個模型、貼住它、把 cache 養好。除非你的工作流真的是混合的，不然不要追求 auto。
想要省 coding 成本：用 architect/editor pattern。Aider 的數據在那裡——14× 便宜還更好。Claude Code 用 subagent + Haiku Explore 也是同一個道理。
Stateless 高量場景才考慮 auto router。OpenRouter Auto 是免費入口，沒理由不試；Martian / NotDiamond 是付費更深入的方案。
Conditional routing（Portkey、Helicone）跟 ML routing 不是同一件事。前者是企業 gateway 的標配，做 fallback 跟 multi-tenant 政策；後者才是你以為的「智能切換」。別搞混。
不要相信「省 60–90%」的數字。RouterArena 的 35% 才是貼地氣的 ceiling。商業 router 還輸給開源，這件事很諷刺但很真實。

回到最初那個問題——「OpenCode Zen 會自動切模型嗎？」不會。它的設計選擇恰好是對的。在 2026 年的快取經濟學下，一個策展型 marketplace + /models 手動切，比一個假裝聰明的 auto router 更尊重你的錢包。

自動切換模型不是免費午餐。它是一個工作負載形狀的 optimization——對的場景下乾淨地省錢，錯的場景下默默把你的 cache 燒掉。Coding agent 屬於後者。