CCR + LiteLLM：讓 Claude Code 換腦不換介面

發布於 2026年5月22日 · 28 分鐘閱讀 · 522 次閱讀

LiteLLM Claude Code claude-code-router AI Agent agent orchestration multi-model

多 model 工作流

CCR + LiteLLM

讓 Claude Code 換腦不換介面

Claude Code 20x 配額大概四天就見底。把規劃留給 Claude Code、批次小任務丟給 LiteLLM 上的便宜 worker、再用 Codex 雙重驗收——這套「換掉模型、留下介面」的工作流，順便看看其他家模型真正拿來幹活的水準。

觸發點

今早那條 Codex 命令

今天早上 Codex 驗收任務卡在連線階段——問了同事才知道是公司 OpenAI workspace 的負責人帳號被停權，整個 workspace（包括我們團隊在用的 Codex）跟著停掉。這個插曲是我動筆的理由，但不是這篇的主題。

那條 Codex 命令重試幾次都不行，接上 log 才看到 CLI 自己被鎖住；申訴信已經寄出去，OpenAI 說至少三個工作天才會回覆，還不保證救得回來。驗收這層暫時只剩 Claude Code 自己跑——LiteLLM 上的小模型雖然在，但我沒打算讓它們接這層，後面「三層分工」那節會說為什麼。

這篇真正要講的，是這陣子怎麼從「Claude Code 20x 配額用著用著還是不夠」，一路試到「LiteLLM 接五家官網、Claude Code 規劃、小模型跑 worker、雙 model 驗收」這套工作流，順便回頭看 DeepSeek、Kimi、GLM、Grok、Qwen 這些模型真正拿來幹活是什麼水準。

起因

20x 為什麼還是不夠用

Claude Code 20x 訂閱配額，我規劃、寫、debug、驗收全部丟給它跑，大概四天就見底。直覺反應是「該再升一階」，但 20x 已經是訂閱方案的上限，再上去只能改打 API。

回頭翻 ccusage 紀錄才發現，問題不只是「用得多」這麼簡單——而是「不該用 Opus 跑的任務也在用 Opus 跑」：改 N 個檔案的同一個 import path、把 N 段 markdown 翻英文、跑 N 個 grep 整理結果，這類批次 + 機械活用 DeepSeek V3 或 Qwen Flash 跑能省九成成本，效果差距可以忽略。

順著這條線往下拆，自然分成三層：

規劃層

leverage 最高，留給最聰明的 model。任務拆分、跨檔案 reasoning、決定要不要做某個 refactor——這層用便宜的，下游全部歪掉。

worker 層

體力活，越便宜越好。批次跑、可平行、機械式重複的工作丟這層。

驗收層

需要「換一個視角」的價值，所以兩個 model 各看一遍比同 model 跑兩次有用。

LiteLLM 就是這時候開始研究的。一方面想找便宜的 worker model 把第二層接起來，另一方面也好奇 DeepSeek / Kimi / GLM / Grok / Qwen 這些常被討論的模型，拿來實際跑會是什麼感覺。

架構

三層分工：規劃 / Worker / 雙重驗收

規劃留給 Claude Code、worker 丟給 LiteLLM 上的小模型、驗收讓 Claude Code 跟 Codex 交叉看一遍。這套三層分工是慢慢試出來的：

Claude Code規劃 / 制定計畫 / 拆任務 / dispatch

本來就跑得順，繼續留著它。整套架構決策、任務拆分、跨檔案 reasoning 都在這層完成。

LiteLLM 上的小模型worker：批次跑拆分後的小任務

後來補的。任務一旦被拆成「改 N 個檔案的同一個 import path」「把 N 段 markdown 翻成英文」「跑 N 個 grep 整理結果」，用 DeepSeek V3 / Qwen Flash / GLM 4.5-air 這類 $0.2/$0.5 等級的 model 跑 batch，速度跟配額壓力都好處理太多。

Claude Code + Codex雙重驗收

Claude Code 按「測試六鐵律」逐條打分、Codex 針對 worktree 的 git diff 跑程式碼本身的審查。

驗收交叉用兩個 model：Claude Code 跑一遍，要求按「測試六鐵律」逐條打分，挑出違規處（下一節展開規則本身與來源）；Codex 跑另一遍，直接餵 worktree 的 git diff，要它從程式碼本身的角度找 bug、找命名不一致、找邊界條件漏處理。

兩個 model 各有盲區。Claude Code 對「我家規矩」熟，但對純語法 / 邊界錯誤的敏感度沒有 Codex 高；Codex 看 diff 仔細，但不知道我的 rules。兩者疊起來，盲區互補。

驗收這層之所以不丟給 LiteLLM 上的小模型，是因為實際試過——小模型對「找出 worker 自己沒看到的問題」這種需要審慎 reasoning 的工作，命中率明顯不夠，常常給出看起來像在審查、實際上漏掉關鍵 bug 的 review。worker 可以放心交給小模型批次跑，驗收這層的標準我目前還只信得過 Claude Code 跟 Codex。今天早上 Codex 那條斷掉之後，驗收就退化成 Claude Code 單腿撐——自己當 worker 又自己驗收這件事有它的限制，但短期沒更好的選項。

方法論

測試六鐵律

這六條不是一次生成的，是逐輪踩坑疊出來的，現在是 Claude Code 驗收 worker 產出時逐條打分的依據：

mutation thinking

測試要先想「這段 code 哪一行被改錯，這個 test 會不會炸」。如果不會炸，這 test 就是裝飾。

寫測分離

寫 code 的 agent 不能自己寫對應 test，要另開一個 agent 寫。同一個腦袋自我驗證盲區放最大。

不變量優先

優先測「跟舊行為對照不能變」的不變量，而不是「我預期會發生什麼」。預期可以錯，不變量比較硬。

runtime → 回歸

測試一定要實際跑起來，不是 import check、不是 type check。能跑出 stack trace 的才算數。

mock 只限外部 I/O 邊界

database、network、檔案系統可以 mock；內部模組之間禁止 mock。內部 mock 是 bug 的避風港。

草稿不是成品

AI 第一輪寫出來的測試是草稿，commit 前要再過一遍，問「這 test 真的會抓到 regression 嗎」。

來源與演進

最初的種子是兩篇文章：

來源	給了什麼
How to Test AI-Generated Code the Right Way in 2026 （Katerina Tomislav, 2026-02）	講 AI 寫的測試最大病灶是「100% 行覆蓋率、4% mutation score」，覆蓋率好看但漏掉 96% 的 bug。引用 HumanEval-Java 的研究數據。
Salesforce VIBEPASS	一個 benchmark，發現前沿 LLM 在沒被預先告知有 bug 時，從程式碼裡找出並修復隱性 bug 的成功率不到 50%。換句話說，AI 自己寫的測試大機率抓不到自己代碼的問題。

原文（Katerina）原本提出的是 4 條方向：mutation testing、AI-aware code review、CI pipeline validation、prompt engineering。我看完之後從第一條 mutation testing 開始套用，自己又從踩坑經驗加了幾條：

第一輪加上「寫測分離」——實測過自己寫的 27 個測試全過、改派獨立 sub-agent（不給它看實作）寫，立刻發現 2 個真實 bug。
第二輪加上「不變量優先」——固定 I/O pair 是同義反覆，只有 invariant 才獨立於實作。
第三輪加上「runtime → 回歸」「mock 只限外部 I/O」——這兩條都是 bug 被 mock 包成「測試過」之後在 production 爆掉踩出來的。
最後加上「草稿不是成品」——因為 Salesforce VIBEPASS 那條結論：AI 自己寫的測試不可盲信，commit 前必須過一遍。

到這就六條了。驗收提示詞會把這六條塞進 system prompt，要求 Claude Code 對 worker 交出來的 diff + tests 逐條檢查，違反哪條、為什麼違反、怎麼修，全部列出來。Codex 那邊不認這六條，所以 Codex 跑的是「純程式碼的 bug 與規範」這個正交的視角——這也是為什麼兩個 model 配在一起比一個 model 跑兩次有用。

選型

為什麼是五家官網，不是 OpenRouter

找誰當 worker 這題，我最後挑了五家直接帳號，放棄 OpenRouter 這類一個 SDK、一條金流就能接完所有 model 的 aggregator。

看過 koc.com.tw 那篇供應商比較，中間商方案一度覺得方向對，但實際算下來有四個扣分：

加價層吃掉官方 promo。中間商加價 5%-20% 看起來不多，但每家原廠的活動、新戶額度、限時折扣全部拿不到。
官網限定額度拿不到。DeepSeek、Qwen、Moonshot 都發過新戶或活動贈送 token，必須是直接帳號才領得到。
金流黑盒、debug 難。出錯分不清是中間商 routing 還是 upstream provider 故障。
prompt / response 加工的不確定性。中間商有沒有改 system prompt、tool schema、stream chunking？這對「評估每家原生表現」是噪音——我原本的好奇心之一就是想直接看每家原生水準，這條讓我直接放棄中間商方案。

最後挑的五家直接帳號：

Provider	定位
Moonshot（Kimi）	Agent 任務、深度推理（Kimi K2-Thinking 在 BrowseComp / AIME 領先）
Z.AI（GLM）	中文長文（Arena Chinese 排名最高）
DeepSeek	CP 值最高的 worker 主力（$0.28/$0.42 預設背景任務）
xAI（Grok）	寫程式 + 2M context 旗艦（SWE-Bench 領先）
阿里（Qwen via DashScope）	極速低成本（`qwen3.5-flash` $0.10/$0.40 是全場最低 input 價）

後來又補了 MiniMax 跟 Google Gemini，主要是想讓 fallback chain 更深。

Google Developer Program 抵免額

我加入 Google Developer Program 之後，Premium tier 每個月會發 $10 monthly Gen AI & Cloud credits 抵免額（一次性抵免、有效期一年），可以直接抵掉 AI Studio 跟 Vertex AI 的 Gemini API 用量。

Google Developer Program 福利頁——每月固定發 $10 Gen AI & Cloud 抵免額

Google Developer Program 的抵免額在 Google Cloud Billing 後台看得到核發紀錄，每張面額 $315-$320 不等，加總月度有 $300+ 可以打 Gemini API：

Google Cloud Billing 抵免額紀錄 — Google Cloud Billing 後台核發的抵免額紀錄

換句話說，把 Gemini 接進 LiteLLM 之後，這個閘道上「免費 model」那一欄就自動有了——配額爆的時候用 gemini-2.5-flash 接 worker 不用心疼成本。這是「直接買官網」這條路額外送的福利，走 OpenRouter 拿不到。

架構

為什麼介面選 CCR：因為還是想用 Claude Code

這陣子把 Claude Code、Codex、Gemini CLI、Copilot CLI 這些主流 CLI agent 都試了一輪，結論是 Claude Code 還是最順手——tool use 的設計、subagent 機制、skill / slash command 體系、與 git worktree 的搭配、context 管理、permission flow 整體都領先一截。試過的清單：

Claude Code Codex Gemini CLI Copilot CLI opencode qwen-code Aider cursor-agent

如果其他 model 我也想跑，最理想是「換掉模型、留下介面」。

最初我其實只想「LiteLLM + 一段 zsh function」就解決——把 Claude Code 的 ANTHROPIC_BASE_URL 指到 LiteLLM :4000，自己改改 request body 就好。實際開始寫才發現每家協議的細節差很多：Anthropic 的 messages API 跟 OpenAI chat/completions 在 system message、tool definition、stream chunking、reasoning content block 上的格式都不一樣，每一處不對齊都會 400 或 silent 丟訊息。我大概寫了半天 transformer，意識到這事不該自己做——就是這時候找到 claude-code-router（簡稱 CCR）這個現成的 transformer。

CCR 在本機跑一個 :3456 的 server，對 Claude Code 表現得像 Anthropic API，對下游則把請求 transform 成 OpenAI 協議丟給 LiteLLM。從 Claude Code 角度看，它「以為」自己在跟 Anthropic 講話，實際上請求被路由到 DeepSeek、Kimi、Grok。換句話說，CCR 讓我可以用 Claude Code 介面，去跑任何 LiteLLM 上的 model。介面不用換、肌肉記憶不用重練、subagent / skill 體系全部繼承過去。

為什麼不用 cc-switch

中間也試過 cc-switch 這個社群工具——一鍵切 Claude Code provider，看起來剛好對我的需求。實裝後發現它的切換機制是直接改 ~/.claude/settings.json：

~/.claude/settings.json 是 Claude Code 全域單一檔。切一次，整台機器上所有 Claude Code session 都跟著變。
我的工作流大量靠 tmux 多 pane 並行——一個 pane 跑 Kimi 規劃、一個 pane 跑 DeepSeek worker、一個 pane 跑 Grok 處理長 context。cc-switch 切第一次三個 pane 都變成同一家，切第二次又全變成另一家，根本沒辦法「並行不同 model」。

CCR + ENV var 路線恰好相反——ANTHROPIC_BASE_URL 跟 ANTHROPIC_MODEL 是 per-process 環境變數，每個 tmux pane 是各自獨立的 shell，互不干擾。下一節的 cc-llm 就是吃這個機制：

Pane A: cc-llm kimi-k2-thinking  → 該 pane shell 設 ANTHROPIC_MODEL=litellm,kimi-k2-thinking
Pane B: cc-llm glm-5             → 該 pane shell 設 ANTHROPIC_MODEL=litellm,glm-5
Pane C: claude（不用 wrapper）     → 該 pane 沒設 ENV，走 CCR 預設 routing

實際長這樣——一個 tmux window 垂直四欄，每欄一個 Claude Code，各打不同 model：

tmux 四欄並行四個 model — tmux 四欄並行——deepseek-r1 / kimi-k2-turbo / minimax-m2.5 / qwen3.5-flash 同時跑

statusline 看得到每個 pane 各自的綁定：litellm,deepseek-r1、litellm,kimi-k2-turbo、litellm,minimax-m2.5、litellm,qwen3.5-flash。四個 pane 同時跑、各打不同 model，CCR :3456 只是個 proxy 看請求路由，不在乎是哪個 pane 發來的。~/.claude/settings.json 也完全沒被動過——所有切換留在 shell session 裡。對「同一台機器同時跑多個 model」這個場景，CCR 是現有方案裡唯一做得到的。

實作

技術骨架：LiteLLM + CCR + 自製 zsh function

路由分兩條線：Claude Code 講 Anthropic protocol，先過 CCR 的 :3456 轉成 OpenAI 協議、再進 LiteLLM 的 :4000；Codex、Gemini、OpenCode 這幾支 CLI 本來就吃 OpenAI 協議，直接打 LiteLLM 的 :4000，不用繞 CCR。畫成圖是這樣：

Claude Code (Anthropic protocol)  ─→ CCR :3456 ─→ LiteLLM :4000 ─→ providers
Codex / Gemini / OpenCode         ─────────────→ LiteLLM :4000 ─→ providers

LiteLLM 是唯一閘道。所有 model_list、API key、fallback、cost telemetry 集中在一份 config.yaml，每家 provider 一個 entry，API key 全用 env var 引用。長相像這樣（節錄一條 entry 意思到即可）：

model_list:
  - model_name: deepseek-v3              # 預設 worker
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY
  # ...kimi / grok / glm / qwen 結構類似，差在 api_base 與前綴

litellm_settings:
  drop_params: true        # 某家不支援的 param 自動 drop，免 400
  modify_params: true      # max_tokens 自動對齊 model 上限
  spend_tracking_enabled: true

router_settings:
  fallbacks:
    - grok-4.20: [deepseek-v3, kimi-k2-thinking]
    - glm-5: [kimi-k2.5, qwen3.5-122b]

drop_params + modify_params 是踩坑後加上去的「免 400」雙保險，省去手動對齊每家 param schema 的工。fallbacks 設好之後，A model 收 429/5xx 自動切 B。

CCR 那邊 config.json 結構更簡單，最關鍵的是 Router 區塊把任務型態對應到具體 model：

"Router": {
  "default":     "litellm,deepseek-v3",       // 背景任務最便宜
  "think":       "litellm,kimi-k2-thinking",   // 需要 reasoning
  "longContext": "litellm,grok-4.20",          // > 60K token 轉 2M window
  "longContextThreshold": 60000,
  "webSearch":   "litellm,qwen3.6-plus"
}

最後是讓一切變一行指令的自製 zsh function cc-llm（脫敏骨架）：

cc-llm() {
  local model="" flags=()
  # 解析 [model] [flags...]
  while [ $# -gt 0 ]; do
    case "$1" in
      -*) flags+=("$1"); shift ;;
      *)  [[ -z "$model" ]] && model="$1"; shift ;;
    esac
  done

  # headless 模式需要這個（CCR 會頻繁問權限）
  flags+=(--dangerously-skip-permissions)

  # 沒指定 model 就 fzf 開選單
  if [[ -z "$model" ]] && command -v fzf >/dev/null; then
    model=$(_list_models | fzf --prompt="cc-llm › " | cut -f1)
  fi

  # 切 endpoint + 鎖定 LiteLLM 上的 model
  ANTHROPIC_BASE_URL=http://127.0.0.1:3456 \
  ANTHROPIC_AUTH_TOKEN=any-string-is-ok \
  ANTHROPIC_MODEL="litellm,$model" \
  claude "${flags[@]}"
}

實際用起來，cc-llm 直接呼叫會開 fzf 選單，自動撈 LiteLLM 上目前所有可用 model，按 provider 分群顯示：

cc-llm fzf 選單 — cc-llm 的 fzf 選單——23 個 model 按 provider 分群

選了某個 model 後，Claude Code 啟動進 TUI，statusline 會明確標出走的是哪條路、用的是哪個 model、effort 設多少：

cc-llm 啟動後 statusline — 啟動後的 statusline——「Claude × grok-4.1-fast · CCR → LiteLLM」

例如上面這張，標題列「Claude × grok-4.1-fast · CCR → LiteLLM」就是 zsh function 印出來的訊息，狀態列下方「litellm,grok-4.1-fast」是 Claude Code 自己讀 ANTHROPIC_MODEL 顯示的，effort 鎖在 xhigh、bypass permissions on——確認這些跟預期一致，就可以放心開工。

其他用法：

cc-llm deepseek-v3              # 跳過選單，鎖定 deepseek-v3 跑 worker batch
cc-llm grok-4.20 --effort high  # 鎖 Grok + 高 reasoning

同類還寫了 cx-llm（Codex）、gm-llm（Gemini CLI）、oc-llm（OpenCode），這三個協議跟 CCR 不相容，所以直連 LiteLLM。所有 CLI 都用一份 LiteLLM config.yaml，要加新 model 改一處。

省配額

連 subagent 也設次等模型

我把 explorer、researcher、browser、media 這四個跑簡單任務的 subagent，model 從預設 sonnet 改成 haiku——subagent 定義檔（~/.claude/agents/*.md）的 model: 欄位就是控制這件事的開關，主對話委派任務給 subagent、subagent 跑完回傳結果、主對話再接著跑。

Agent	用途	改後 model
`explorer`	codebase 搜尋、找檔案	haiku
`researcher`	web 搜尋、資料整理	haiku
`browser`	Playwright CLI browser automation	haiku
`media`	影音 / 圖像 / OCR 處理	haiku

這四種任務的共通點：tool call 多、reasoning 淺、需要的 model 智力不高，但會吃大量 turn 跟 context。原本全用 sonnet 跑，配額消耗驚人；換成 haiku 之後成本砍掉九成，品質沒明顯掉。

更聰明一點的是動態調整——我寫了個 model-policy daemon 每 5 分鐘看一次 Claude 配額剩多少，分四階：normal / boost-1 / boost-2 / boost-3。配額充裕時 haiku 就是 haiku；配額快爆（5h < 25% 或 7d < 40%）時自動把 haiku 升 sonnet、sonnet 升 opus，讓「能用大 model」的時候用滿、「該省的時候」自動降階。

這層分工是「Claude Code 內部」的：主對話還是 sonnet/opus 規劃，但分派出去的 subagent 跑簡單任務時走 haiku。和 LiteLLM 的「外部 worker」是兩條獨立的省配額路徑，可以疊加。

監控

知道每個 model 現在用了多少

工作流接好了，剩下一個小問題——五家加上 Big-3 共八個 dashboard，每家網站排版都不一樣。隨手翻幾張各家後台給你看：

DeepSeek 後台 — DeepSeek——prepaid 模式，給的是充值餘額 + 每日消費長條圖

Moonshot 後台 — Moonshot（Kimi）——Balance + Voucher + 每月 Product Consumption 折線

Z.AI 後台 — Z.AI（GLM）——Cash balance + Credits balance 兩個獨立帳戶

MiniMax 後台 — MiniMax——Current balance / Voucher / Overdraft / Outstanding 分四欄自己算

xAI Grok 後台 — xAI——Spend credits + Auto top-ups + Latest invoices 三段

阿里 DashScope 後台 — 阿里 DashScope——每個 model 各自有免費額度，82 個 model 各看各的剩餘 token

每家設計邏輯都不一樣——「我下一個任務該丟誰」這個問題沒辦法在任何一家後台回答，要嘛開六個分頁手動比，要嘛自己整合。

於是自己拼了個小監控頁，每天定時爬一次餘額。三個 view：

配額 view——把訂閱型額度（Claude 5h/7d/EX、Codex 5h/7d、Gemini Pro/Flash 24h）跟 reset 時間擺一起：

自製 dashboard 配額 view — 配額 view——訂閱型額度 + reset 時間一頁看完

我看一眼就知道：Claude 5h 才吃 7%（馬上要 reset）、7d 已經吃掉 60%（距下次 reset 還有約兩天）、EX 月上限 $100 才用 11%。要繼續拼還是先換 worker model，配額 view 就能決定。

用量 view——LiteLLM 預付額度、每家 provider 儲值 / 剩餘 / 已用 / 使用率攤平：

自製 dashboard 用量 view — 用量 view——LiteLLM 預付額度 + 各 provider 使用率攤平

用量 view 我看得最頻繁。DeepSeek 已用 50%、Moonshot 才 17%、MiniMax 才 3%——這意味著 DeepSeek 接太多 batch task 了，下次可以把一部分分散到 Moonshot 或 MiniMax，避免單一 provider 先燒完。Google Cloud 抵免額也納入這頁（免費的，但「快用完」要追）。

模型圖鑑 view——各家旗艦 / Fast / Value 模型一覽，加上 Arena / SWE-Bench / Speed 場景推薦：

自製 dashboard 模型圖鑑 view — 模型圖鑑 view——場景推薦 + 各家 Smart / Fast / Value 一覽

模型圖鑑每隔幾天更新一次（Consensus ranking from 4 sources），用來決定「現在哪個 model 該路由到什麼任務」。2026-05-20 那天，數學推理首選從 DeepSeek R1 換成 Kimi K2.6 Thinking——換完 LiteLLM config.yaml 跟 CCR Router 同步更新。

比對 provider model list 偵測「設定過時」

爬蟲還順帶做第四件事——抓每家 provider 官網的 /v1/models endpoint，跟 LiteLLM config.yaml 裡寫的 model_name 對照。這條是踩過坑才補的。

過去發生過好幾次：早上開 Claude Code 跑工作，CCR :3456 回 404 model not found；查半天才發現某家供應商把 xxx-preview 改成 xxx-stable、或者把舊版本 v3.1 直接退役換成 v3.2——LiteLLM config.yaml 還寫著舊名字，於是整條路徑斷掉。前沿模型替換速度比想像中快，DeepSeek、Moonshot、Qwen 一兩週就可能換一輪 model code，新舊命名常常沒回溯相容。

對照邏輯很單純：

# 每天定時跑
for provider in providers:
    upstream_models = fetch(provider.list_endpoint)   # e.g. https://api.moonshot.cn/v1/models
    configured = read_litellm_config()[provider.name]  # 我寫進 config.yaml 的 model 名
    stale = configured - upstream_models  # 在我 config 但 upstream 沒了 → 已退役
    new   = upstream_models - configured  # upstream 新出但我沒接 → 候選

dashboard 把 stale 標紅、new 標綠，一眼就知道「config 哪幾條已經失效該砍 / 哪幾條新出可以評估」。這條 check 從事後 debug 變成事前預警之後，「啟動才發現 model 404」這個情境就消失了。

後端就是每天一輪爬蟲，前端是個自己拼的小單頁。寫它的動機不是技術秀，是因為這資訊現有工具沒人整合，自己想看只能自己刻。

Trade-off

誰適合、誰不適合

好處集中在三件事：三層分工把配額燒在刀口上、順便摸清了其他家模型的真實水準、單一 provider 斷供不會讓整套工作流停擺。

三層分工 ROI 對齊——規劃這層留最聰明的 model、worker 用 $0.2/$0.5 級別的批次跑、驗收用兩個 model 交叉。同樣的配額能多撐幾天，結果品質還比一個 model 從頭打到底穩。
「順便了解其他模型」是 bonus——試了一陣子，對哪家在哪類任務上比較強有了一手感覺，不用只看別人的 benchmark 圖。模型圖鑑那頁就是這套手感累積出來的。
單一 provider 斷供不會整套停——像今早 Codex 那樣被鎖住，工作流會降級成單腿驗收，但 Claude Code + LiteLLM 兩條線繼續跑得動。

代價同樣三件：多養兩個 daemon 要維護、每家 provider 的脾氣得自己摸、哪個任務該配哪個 model 沒人替你決定。

多了 CCR 跟 LiteLLM 兩個 daemon 要維護。CCR 升版改過 transformer schema、LiteLLM 1.55+ 改過 spend tracking 欄位，每次都得回去 debug 半天。
每家 provider 的個性要自己摸——Moonshot 偶爾延遲飆高、DashScope 偶爾 5xx、xAI 有過幾次回應格式漂移。fallback chain 沒設好就會踩到。
「哪個 task 該跑哪個 model」沒人替你決定——多了一層心智負擔，要嘛靠經驗、要嘛靠模型圖鑑這種輔助工具。

所以這套適合的是：20x 訂閱真的不夠用、又願意花一個週末把架構鋪好的人。如果 20x 用著很舒服、或者不想多養兩個本機 daemon，就維持原樣最省心——這套的代價超過它的好處。

我自己留下來的理由就一句：對「同樣的任務換不同的 model 跑會發生什麼」這件事的好奇還沒退，分工跑下來也確實對配額更友善。配額用完不會逼自己升訂閱、會逼自己想清楚哪一層在燒——這種「被資源限制推著思考」的感覺，反而是我最喜歡的部分。

工具

這個任務該丟哪一層

上面那份 CCR Router 只有四格，真實任務不只四種。勾一下手邊那個任務長什麼樣，這裡照本文「規劃 / worker / 驗收」的定義判一次層別，並把本文對該層的原句印出來。層別跟 Router 四格是兩根軸：對得到本文 config.json 哪一格就印那格的 model，對不到就寫查不到——本文把規劃跟驗收都留在 Claude Code 這邊，Router 四格沒有給它們的位置。全部在瀏覽器裡跑，不用填 API key，沒有任何資料送出去。

這個任務長什麼樣？要餵進去的 context 大約多少 token？（不確定就留白）這批要跑幾次？（幾個檔案／幾段）

產出會直接進 commit

常數出處都在本文：三層定義逐字取自「三層分工」那節的三張卡片，Router 四格與 longContextThreshold: 60000 取自本文貼出的 CCR config.json，指令格式取自本文的 cc-llm zsh function。「批次數 ≥ 2 才顯示省成本那條」是我設的顯示門檻，不是本文的數字——本文除了 60000 之外沒有第二個數值門檻。model 名稱是本文 2026-05 的寫法，不是這裡給的建議值。

帶走這段

先算清楚哪一層在燒配額

三層分工的價值不在「省」，在「對齊」——讓最貴的 model 只做最該它做的事。導入前先讓 AI 幫你算一遍：你的配額到底燒在哪一層。

把你的工作流和配額狀況貼給 AI，讓它幫你判斷值不值得拆三層、以及怎麼漸進過渡：

我在看一篇文章〈CCR + LiteLLM：讓 Claude Code 換腦不換介面〉（https://blog.joneshong.com/zh/blog/claude-code-route-litellm），作者把工作流拆成「規劃 / worker / 驗收」三層、用 LiteLLM 把便宜 model 接進來。我目前的 AI 寫程式工作流主要靠 [Claude Code / Codex / Cursor / …]，訂閱配額一週見底 N 次。請對照本文幫我判斷值不值得拆三層： 1. 從我過去 30 天的 token 用量找出「不該用旗艦 model 跑」的任務類型（批次改檔、翻譯、grep 整理、boilerplate 生成、機械式重複）。 2. 估算這些任務搬到 LiteLLM 上 $0.2/$0.5 級別的便宜 worker（DeepSeek V3 / Qwen Flash / GLM Air）之後，每月可省多少配額或現金。 3. 檢查我現在的 provider 組合有沒有「single point of failure」—— 今天某家 API 突然斷供 24 小時，工作流哪個環節會卡住？ 4. 設計驗收層：哪兩個獨立 model 適合做 cross-review？一個照 coding rules 跑、一個直接看 git diff，各自的盲區互補。 5. 漸進過渡步驟：先架 LiteLLM（一份 config.yaml）→ 接一家 provider 試 → 寫一段 cc-llm 之類的 wrapper → 再決定要不要上 claude-code-router。 6. 維護代價：每天一輪爬蟲偵測「provider 換 model code 害我設定過時」、兩個 daemon 升級踩坑、多 model 心智負擔。提醒我衡量值不值。

參考資料

延伸閱讀

這套工作流實際參考過、影響過設計決策的資源。

資源	為什麼重要
claude-code-router	Anthropic ↔ OpenAI protocol transformer。沒它 Claude Code 進不了 LiteLLM，是整套路由的關鍵中介層。
LiteLLM	多 provider 統一閘道。本文整套架構的核心。
cc-switch	走過但放棄的方案。看一下 README 就知道為什麼它對「同時多 model 並行」做不到——設計前提是「整台機器一時一個 provider」。
koc.com.tw 各家 AI API 中間商比較	中間商方案的入門概覽，看完它我決定不走中間商。
How to Test AI-Generated Code the Right Way in 2026	「測試六鐵律」的最早種子。「100% coverage / 4% mutation score」這個對比講清楚之後，我對 AI 寫的測試就再也不敢盲信。
Salesforce VIBEPASS	benchmark 顯示前沿 LLM 找自己代碼裡隱性 bug 的成功率不到 50%。這是「驗收這層不交給小模型」最硬的證據。
tmux 從通用狀態列、分屏、遠端到多 agent 分工	本文「tmux 四欄並行不同 model」那張截圖背後的工具鏈怎麼長出來的。如果你還沒用 tmux 跑多 agent CLI，這篇講基礎佈局與狀態列。

本文提到的概念

三層分工 AI Agent 測試六鐵律 subagent CLI

知識圖譜

✦ 帶走這段

CCR + LiteLLM：讓 Claude Code 換腦不換介面

CCR + LiteLLM

讓 Claude Code 換腦不換介面

今早那條 Codex 命令

20x 為什麼還是不夠用

規劃層

worker 層

驗收層

三層分工：規劃 / Worker / 雙重驗收

測試六鐵律

mutation thinking

寫測分離

不變量優先

runtime → 回歸

mock 只限外部 I/O 邊界

草稿不是成品

來源與演進

為什麼是五家官網，不是 OpenRouter

Google Developer Program 抵免額

為什麼介面選 CCR：因為還是想用 Claude Code

為什麼不用 cc-switch

技術骨架：LiteLLM + CCR + 自製 zsh function

連 subagent 也設次等模型

知道每個 model 現在用了多少

比對 provider model list 偵測「設定過時」

誰適合、誰不適合

這個任務該丟哪一層

先算清楚哪一層在燒配額

延伸閱讀

推薦閱讀

Claude Code 的 mod 是什麼？怎麼用？推薦你四個

AI 做影片：畫面怎麼動、花多少

把手邊的工具和額度用好，一次多 agent 分工的嘗試

本文提到的概念

知識圖譜