我怎麼讓Claude Code接多個模型，而不用每次都改config

一開始用Claude Code的時候，我的做法其實很單純：選一個順手的模型，設定好之後就一路用下去。

如果你的工作內容很固定，這樣其實沒什麼問題。
但只要開始把Claude Code放進比較真實的開發流程裡，問題很快就會跑出來。

有些task只需要模型出得快，像是boilerplate、README草稿、簡單script、重複性修改。
有些task則比較需要穩定和細緻，像是 refactor、review、命名、結構整理。
還有一些情況只是想快速測prompt，或者先用成本比較低的模型把流程跑一遍。

這時候，真正麻煩的通常不是「要不要換模型」，而是：

• 換模型要不要改config
• 要不要換endpoint
• API key要不要跟著動
• 不同tool的接法是不是又不一樣
• 同一套workflow能不能維持不動

如果每次換task就要跟著重整理一次設定，那很快就不是在寫code，而是在管理設定。

真正卡住的通常不是Claude Code本體，而是周邊設定

Claude Code本身沒有那麼難用。
只要你的本機環境是正常的，像是：

• Git可以正常用
• Node.js / npm 沒有壞掉
• shell / terminal 環境沒有亂掉

大多數情況下，它本體不會是最麻煩的部分。

比較容易失控的，反而是它外面那一圈：

• 想換模型時要改config
• 某個tool走這個endpoint，另一個tool又是另一種設定
• project一多，base URL和API key開始分散
• 明明只是想比較不同模型的輸出，結果設定比比較本身還花時間
• 有些輕量task根本不需要高成本模型，但因為切換很麻煩，最後還是全部混著用

這種問題不一定會讓workflow直接壞掉。
它比較像是一種持續累積的摩擦：每次只多花一點時間，但久了之後，整個流程會越來越不順。

多模型工作流真正該先處理的，不是選模型，而是降低切換成本

很多人在談多模型時，第一個問題都是：

哪個模型最好？

這個問題當然重要。
但如果是放到真實工作流裡，我反而覺得更該先問的是：

• 切換模型要花多少成本？
• 切換一次會不會讓workflow斷掉？
• 想加新的tool時，原本設定能不能重用？
• 想做輸出比較時，整個過程夠不夠輕？

原因很簡單。

如果切換成本太高，就算理論上你可以用很多模型，實際上也很容易變成只用一個。
不是因為其他模型沒價值，而是因為每次切來切去都太麻煩。

這時候，多模型的價值就被設定成本吃掉了。

我後來比較偏好的做法：把config入口盡量統一

我後來比較傾向的做法，是把支援OpenAI-compatible的tool，盡量收斂到同一個入口。

概念其實不複雜：

• 盡量共用同一個OPENAI_BASE_URL
• 盡量共用同一個OPENAI_API_KEY
• 模型切換盡量在gateway那一層處理
• 不要讓每個tool都有自己一套完全不同的接法

像環境變數通常可以整理成這樣：

export OPENAI_BASE_URL="https://crazyrouter.com/v1"
export OPENAI_API_KEY="your_key_here"



這樣做的重點不是看起來比較整齊而已。真正的好處是：你知道要動哪裡，才會真的切換生效。當workflow慢慢變複雜時，這件事其實很重要。這樣整理之後，實際上的差異在哪裡？我自己覺得比較明顯的是這幾點：

1. 換模型時不用到處找設定

如果入口夠集中，切換模型不需要每次都翻一輪config。
這會直接降低很多小摩擦。

2. 加新tool時比較容易重用

只要新的工具也能吃OpenAI-compatible的接法，原本的設定方式通常可以沿用。這比每接一個tool就重新學一次設定方式省事很多。

3. 做模型比較比較像真的能執行的事

很多人都說想比較不同模型的輸出。但如果每次比較前都要重設一輪，其實大部分時候根本不會真的去做。只有當切換成本夠低，輸出比較才會變成workflow的一部分，而不是停留在想法上。

4. 輕量task才真的有機會用便宜模型處理

不是每件事都值得用高成本模型。像整理文字、簡單生成、反覆修正這類工作，很多時候用比較輕的模型就夠了。但前提是切換不能太痛苦。不然最後通常還是全部丟給同一個模型處理。哪些情境特別適合這種做法？我覺得下面幾種情況會特別明顯。下草稿和做review想分開，有些task重點是快，有些task重點是穩。如果能低成本切換模型，就比較容易把這兩件事拆開來做。想在自己的workflow裡比較模型，公開 benchmark 當然可以參考，但真正有用的還是：

• 你的prompt
• 你的code
• 你的project
• 你的工作方式

所以如果真的想知道哪個模型適合自己，還是得在自己的workflow裡比。而這件事只有在設定夠順的時候才做得起來。
想控制成本，但又不想犧牲整體流程，多模型不一定是為了追求最強輸出，有時候只是為了讓不同類型的task用不同成本去跑。如果config沒整理好，這件事會非常難持續。最不值得的狀況，就是workflow慢慢變成在管理配線，這是我後來感覺最明顯的一件事。AI workflow 一開始看起來像是在選模型，但做久了之後，真正耗時間的常常變成：

• 哪個tool接哪個endpoint
• 哪個project用哪組key
• 哪份config才是現在在用的版本
• 每次切模型到底要改幾個地方

當事情走到這一步，開發流程就很容易變成在管理配線。表面上什麼都還能跑，但實際上你會越來越不想試新模型、不想比較輸出，也不想再多接新工具。所以如果一開始就知道自己不會只用單一模型，我反而會建議先把config結構整理好。不一定要做得很重，但至少要讓「模型可以換，workflow不用跟著重建」這件事成立。並不是每個人都需要這樣做

如果你現在的情況是：
• 幾乎只用一個模型
• task類型很固定
• tool很少
• 沒有特別想做模型比較
• 現在的workflow已經夠順

那其實沒必要為了多模型而多做一層。但如果你開始出現下面這些情況：

• 常常想換不同模型試試看
• 同一個task會想比較輸出差異
• tool越來越多
• config越來越散
• 每次換設定都覺得有點煩

那就代表你可能已經到該整理config的階段了。

結論：Claude Code接多模型這件事，真正麻煩的通常不是模型數量不夠，而是設定太分散。

只要每次切換還要跟著改endpoint、改key、改tool設定，workflow就很容易被這些小摩擦拖慢。
久了之後，多模型本來應該帶來的彈性，反而會被設定成本吃掉。

所以如果真的想把多模型用好，我會更建議先整理config的入口，讓切換成本降下來。
這比一直找「最好的單一模型」更接近真實工作流會遇到的問題。

我自己現在比較偏向用OpenAI-compatible的方式，把入口集中起來。
像Crazyrouter這種能把多個模型收進同一層接口的做法，對我來說真正有價值的，不只是模型變多，而是切換的時候不用把整個workflow一起拆掉重來。