每個月給 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 反代。但自建就是這樣，鏈路上任何一環出么蛾子，半夜爬起來修的人都是你。

粗算一下平衡點

到底用多少，自建才比按量划算？粗算一筆（假設前提寫清楚，不當精確報價）：

• 自建固定盤：$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：

docker pull eceasy/cli-proxy-api:v8.0.27   # 292MB，发布页显示 2026-10-12 发布

最小設定只需要三行，空上游也能啟動：

# config.yaml
config-version: 8
server:
  port: 8317

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 上游的情況下，自建閘道器不是瓶頸。你感受到的”慢”，通常來自模型推理和上游網路，而不是多這一跳代理——但高併發或複雜網路環境下的表現，這次沒測到。

作為參照，我用手頭的一個商業中轉（OpenAI 相容）直連測了 10 次真實模型呼叫（gpt-6-luna，中轉商側的模型標識，未驗證模型指紋）：10/10 成功，首字延遲中位 1240ms，p95 1996ms，總時長中位 1745ms。首字延遲主要由模型推理決定——這也反過來印證了上面的結論：閘道器那 4ms 在端到端體感裡可以忽略不計。

部署本身不復雜，容器拉起來後，agent 透過相容 OpenAI 的地址存取服務。具體端點和認證方式以你用的版本檔案為準，下面是呼叫側常見的設定形態，示例地址記得換成自己的服務：

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），口徑一致；費率以官方定價頁為準，本文核驗於 2026-10-14。另外它有個 BYOK 模式：綁自己的官方 key，每月 25,000 美元 list-price 額度內免收平臺費，超出部分收 5%（同上，以官方頁為準）。

接入是三條路線裡最省事的：註冊、充值，把 OpenAI SDK 的 base_url 指向它，選模型就能跑。官方檔案確認了 OpenAI 相容端點和 drop-in 替換，現有程式碼幾乎不用改：

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），適合做初步比較；但定價頁變得頻繁，動手前務必以官方定價頁面和 Anthropic 定價頁面複核，別把可能變化的價格當成長期數字寫進自己的成本模型。

穩定性可以先從架構看，不用等實測數字：自建服務多一個 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 專案 · 一鍵部署儲存庫 · OpenRouter 快速開始 · OpenRouter 定價