# Claude Code、Codex 接 API 怎麼選：3 種路線的成本與接入對比 > Canonical: https://vxi.me/zh-tw/posts/claude-code-codex-api-gateway-comparison/ > Locale: zh-tw > Published: 2026-10-14 > Updated: 2026-10-14 > Markdown: https://vxi.me/zh-tw/posts/claude-code-codex-api-gateway-comparison.md 每個月給 Claude Code 或 Codex 續訂閱的時候，你可能都算過這筆賬：Plus 會員 20 美元一個月，用得少覺得虧，用得多又不夠分；切官方 API 按量吧，賬單沒上限心裡沒底；想自建閘道器把訂閱聚起來，VPS 和 OAuth 設定擺在面前；找家中轉商，價格是便宜，但 key 交到別人手裡，返回的到底是不是你要的模型，只能賭人品。 我把實際可走的三條路線擺在一起比了一遍：用 CLIProxyAPI 把手裡的 CLI 訂閱轉成相容 API 自己跑；用 OpenRouter 這類商業中轉按量轉發；或者直接走模型廠商的官方 API。先說結論，沒有最好的閘道器，只有跟你的用量曲線匹配的成本模型：用量大、且穩定在訂閱額度以內，自建訂閱聚合通常最划算；用量小，按量付費最省心；中間地帶，看你願不願意維護一台 VPS。 範圍先界定清楚，這篇只談 Claude Code、Codex 這類 AI 程式設計 agent 的 API 供應路線，不做通用大模型閘道器橫評。CLIProxyAPI 聚合的是各家 CLI 工具的訂閱憑證——按專案檔案，支援的上游包括 Codex、Claude Code、Gemini CLI、Grok 等，輸出 OpenAI/Gemini/Claude/Codex 相容介面。拿它去對標通用閘道器沒有意義。 ## 先把成本口徑對齊 我一開始想從功能表入手，結果發現功能多少回答不了"錢花在哪"。於是把比較軸換成了成本結構、接入難度和資料流向，這三樣才是選型時真正會踩坑的地方。 版本資訊也會影響結論，CLIProxyAPI 發版很頻繁。我一開始以為看 GitHub releases 的版本號就夠了，結果發現還得對照 Docker Hub 的鏡像標籤——兩邊都指向 v8.0.27（2026-10-12 釋出）才算數，單看一邊可能看到的是舊頁面的快取。下面提到的版本號都是截至 2026-10-14 的，動手前對照 Docker Hub 標籤確認一眼，這是個好習慣。 ## 自建：訂閱加 VPS，成本相對固定 自建方案更適合按固定成本來估算，而不是稱作"免費 API"。以每月 20 美元起的訂閱加約 5–10 美元 VPS 為例，月支出相對固定，用量越高越容易攤薄——每天高強度用 agent 的人，這條路線通常是最便宜的。 代價是三樣東西要自己扛：OAuth 裝置碼的接入流程、一台 VPS 的長期維護，以及上游訂閱的風控風險。我 10 月初在 VPS 上部署時，OAuth 環節就遇到過 Cloudflare 403 和區域超時，最後確認是訂閱側/網路環境的問題，不是閘道器本身的缺陷。那次部署的完整過程我寫過一篇實錄，OAuth 之外的 Docker 與客戶端設定部分可以直接照抄：[Codex 怎麼透過 CLIProxyAPI 反代](/posts/cliproxyapi-codex-docker-proxy/)。但自建就是這樣，鏈路上任何一環出么蛾子，半夜爬起來修的人都是你。 ### 粗算一下平衡點 到底用多少，自建才比按量划算？粗算一筆（假設前提寫清楚，不當精確報價）： - **自建固定盤**：$20/月訂閱 + $5/月入門 VPS ≈ **$25/月封頂**，用多用少一個價。 - **官方按量盤**：以 Sonnet 5.5 級別（輸入 $2 / 輸出 $10 每百萬 token，第三方整理價）為例，每天 100 萬輸入 + 20 萬輸出 ≈ $4/天，一個月下來奔著 **$120** 去。 臨界點很直觀：每天百萬 token 量級的高頻使用者，自建是把"無底洞"鎖死成固定月費；反過來，一週只開幾次終端的輕度使用者，按量一個月可能就幾美元，自建反而多背了一台 VPS 的閒置月租。對號入座就行。 ### 安裝實測：v8.0.27，一次成功 這次我在隔離測試機上（Ubuntu 26.04，1 核 / 1.9G 記憶體）把安裝完整重跑了一遍，版本 pin 到 v8.0.27，不用 latest： ```bash docker pull eceasy/cli-proxy-api:v8.0.27 # 292MB，发布页显示 2026-10-12 发布 ``` 最小設定只需要三行，空上游也能啟動： ```yaml # config.yaml config-version: 8 server: port: 8317 ``` ```bash docker run -d --name cpa-test --restart unless-stopped \ -p 8317:8317 \ -v ./config.yaml:/CLIProxyAPI/config.yaml \ -v ./auths:/root/.cli-proxy-api \ eceasy/cli-proxy-api:v8.0.27 ``` 啟動日誌確認版本、Commit 與建置時間（v8.0.27 / bf93416 / 2026-10-12），和 GitHub main 對得上。`/` 返回 200 並列出三個相容端點；`/v1/models` 在沒配上游時返回空列表——這是正常狀態，不是報錯。 兩個實測中發現的細節，教程裡值得寫清楚： 1. **最小設定預設沒有鑑權**。不配 `access.api-keys`，任何人都能調你的閘道器。內網玩玩無所謂，埠一旦暴露到公網，第一件事就是加上 key。 2. **容器裡存取宿主機別寫 127.0.0.1**。我一開始把 mock 上游配成 `http://127.0.0.1:18888`，网关直接报 connection refused——容器裡的 localhost 是它自己。用宿主機的 docker 網橋地址（通常是 172.17.0.1）或者 `--network host`。閘道器的報錯倒是很老實，500 裡直接寫明 dial 失敗的原因，排錯不費勁。 另外 `/health` 這個端點在我的測試設定裡不存在（404），寫健康檢查腳本時別照抄通用模板。 ### 閘道器本身慢多少？實測：約 4ms "自建會不會很慢"是選型時最常見的疑問，我直接測了。方法：在同一台機器上起一個 mock OpenAI 上游（首 chunk 固定延遲 50ms），對比"直連 mock"和"經閘道器再到 mock"，各 20 次，streaming： | 路徑 | 成功率 | 首字延遲中位 | 首字延遲 p95 | 總時長中位 | |---|---|---|---|---| | 直連 mock 上游 | 20/20 | 52.4ms | 52.9ms | 104.2ms | | 經 CLIProxyAPI 閘道器 | 20/20 | 56.5ms | 57.3ms | 108.7ms | 閘道器本體只增加了約 4ms，而且 p95 和中位貼得很近，說明開銷穩定。結論限定在這次測試條件裡：**同機、低負載、mock 上游的情況下，自建閘道器不是瓶頸**。你感受到的"慢"，通常來自模型推理和上游網路，而不是多這一跳代理——但高併發或複雜網路環境下的表現，這次沒測到。 ![閘道器開銷對比：直連 mock 上游 vs 經 CLIProxyAPI 閘道器，首字延遲中位/TTFT p95/總時長中位（N=20，同機測試），閘道器本體開銷約 4ms](/images/posts/claude-code-codex-api-gateway-comparison/gateway-overhead-chart.png) 作為參照，我用手頭的一個商業中轉（OpenAI 相容）直連測了 10 次真實模型呼叫（gpt-6-luna，中轉商側的模型標識，未驗證模型指紋）：10/10 成功，首字延遲中位 1240ms，p95 1996ms，總時長中位 1745ms。首字延遲主要由模型推理決定——這也反過來印證了上面的結論：閘道器那 4ms 在端到端體感裡可以忽略不計。 部署本身不復雜，容器拉起來後，agent 透過相容 OpenAI 的地址存取服務。具體端點和認證方式以你用的版本檔案為準，下面是呼叫側常見的設定形態，示例地址記得換成自己的服務： ```python from openai import OpenAI client = OpenAI( base_url="https://your-api.example/v1", api_key="YOUR_API_KEY", ) ``` 如果你不想從零搭，我把當時驗證過的部署腳本整理成了一鍵部署儲存庫，`setup.sh` 一把梭，配好 key 就能起服務，適合想省時間的人直接拿去用： kuangyongjie/cliproxyapi-codex-deploy ## OpenRouter：少維運，按量付費 OpenRouter 的成本邏輯正好相反：模型 token 按供應商定價透傳，不加價，平臺的收費點在充值環節——信用卡充值收 5.5% 手續費（最低 0.80 美元），加密貨幣 5%。這個費率我交叉核對過三家 2026-10 的獨立來源（betterclaw.io、leanroute.dev、calculatorai.app），口徑一致；費率以[官方定價頁](https://openrouter.ai/pricing)為準，本文核驗於 2026-10-14。另外它有個 BYOK 模式：綁自己的官方 key，每月 25,000 美元 list-price 額度內免收平臺費，超出部分收 5%（同上，以官方頁為準）。 接入是三條路線裡最省事的：註冊、充值，把 OpenAI SDK 的 `base_url` 指向它，選模型就能跑。官方檔案確認了 OpenAI 相容端點和 drop-in 替換，現有程式碼幾乎不用改： ```python from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="YOUR_OPENROUTER_API_KEY", ) response = client.chat.completions.create( model="YOUR_MODEL", messages=[{"role": "user", "content": "Hello"}], ) ``` 省掉的維運是有代價的：請求先經過 OpenRouter 再到上游供應商。平臺預設不儲存 prompt 和 completion，只保留後設資料，日誌可以 opt-in 開啟——這是平臺自身的預設日誌策略；請求最終會到達上游供應商，適用供應商自己的資料政策。對資料敏感的團隊，重點不是糾結"存不存"，而是確認請求會經過哪幾方——這條在任何商業中轉上都適用。 商業中轉的風險要講具體，也要把證據和判斷分開。有一項研究指出轉售中轉存在模型指紋不符的情況，但我沒能獨立驗證原文，這裡就不點名任何一家中文中轉商。更穩妥的做法是：先小額試用，再核對實際返回的模型指紋和服務行為，對不上就換。凡是隻談價格、不談驗證方法的推薦，都值得警惕。 ## 官方 API：直連作為基準 官方 API 按量付費，直連模型廠商，資料路徑最短。它是另外兩條路線的參照系：所有"便宜 X%"的宣傳，分母都是這裡。 OpenAI 和 Anthropic 的具體價格我引用的是第三方整理（2026-10），適合做初步比較；但定價頁變得頻繁，動手前務必以[官方定價頁面](https://openai.com/api/pricing/)和 [Anthropic 定價頁面](https://www.anthropic.com/pricing/)複核，別把可能變化的價格當成長期數字寫進自己的成本模型。 穩定性可以先從架構看，不用等實測數字：自建服務多一個 VPS 單點，出問題自己修；商業平臺有路由和 fallback 兜底（是否生效取決於具體模型和故障型別）；官方 API 由廠商直接提供服務。落到選擇上就三句話：用量大、能維護 VPS、接受訂閱風控，看自建；用量小或不想維運，OpenRouter 更直接；對資料路徑和直連有硬要求，走官方 API。本文沒有比較三者的實際可用性，選型時別把架構分析當成 uptime 承諾。 ## 邊界 / 限制 這次實測了兩部分：閘道器本體開銷（同機 mock 上游，N=20，+4ms）和商業中轉直連的真實體感（手頭中轉，gpt-6-luna，N=10）。**沒測的部分**：OpenRouter 與官方 API 的線上延遲（沒有對應 key）、OAuth 訂閱上游的端到端表現（需要瀏覽器完成 device 登入）、以及 24 小時以上的長時穩定性。閘道器開銷的結論來自 mock 上游——它證明的是"閘道器本體不慢"，不是"你的上游不慢"。 CLIProxyAPI 的版本號、OpenRouter 的費率、官方定價都可能變化，上面給的是截至 2026-10-14 的核驗結果，動手前對照專案釋出頁、Docker Hub 標籤和官方定價頁再確認一次。 ## 最後：三句話，幫你定 - **選自建聚合**：每天高強度依賴 agent 寫程式碼、手裡已有 CLI 訂閱、有基礎 Linux 維運能力、想把成本鎖死。 - **選 OpenRouter**：用量中小或波動大、不想伺候伺服器、經常在多個模型間切換試效果。 - **選官方 API**：對資料路徑有合規要求、預算充足、不在乎用量彈性。 **相關連結：**[CLIProxyAPI 專案](https://github.com/router-for-me/CLIProxyAPI) · [一鍵部署儲存庫](https://github.com/kuangyongjie/cliproxyapi-codex-deploy) · [OpenRouter 快速開始](https://openrouter.ai/docs/quickstart) · [OpenRouter 定價](https://openrouter.ai/pricing) ## Verification context - Level: first-party - Verified: 2026-10-14T00:00:00.000Z - Environment: Ubuntu 26.04 - Environment: Docker 29.9.0 - Environment: CLIProxyAPI v8.0.27 - Evidence mode: mixed - Evidence receipt: https://vxi.me/evidence/claude-code-codex-api-gateway-comparison.json