AI 編程網關怎麼選：OmniRoute、9Router、OpenRouter 和本地 Ollama 對比

AI 編程用久以後，模型入口會變得很亂。 Codex 可能用官方入口。 Claude Code 可能走 Anthropic。 Cursor 有自己的模型配置。本地工具想接 Ollama。有些任務想用便宜模型。有些任務又必須用強模型。

這時你會遇到一個問題：要不要加 AI 編程網關？網關的價值不是「又多一個工具」。它真正解決的是模型入口、成本、回退、限流、審計和本地兼容。

OmniRoute 更像本地或自託管的多模型路由器。 9Router 更偏 Claude Code、Codex 等編程工具的 Provider 切換。 OpenRouter 更像雲端模型聚合平台。 Ollama 則是本地模型入口，不是傳統意義上的雲網關。

網關選型結論

如果你想統一多個雲模型供應商，優先看 OpenRouter 或 OmniRoute。如果你主要圍繞 Claude Code、Codex 做本地配置切換，優先看 9Router。如果你要低成本、本地隱私和離線實驗，優先看 Ollama。如果你要自託管、多 Provider、自動回退和更強控制，優先看 OmniRoute。

如果你還沒有穩定的 AI 編程工作流，不要急著上網關。先把 Codex 或 Claude Code 的單模型流程跑順。再用網關解決成本和切換問題。

四種方案一句話對比

方案	定位	適合誰	不適合誰
OmniRoute	自託管 AI API 網關	多帳號、多模型、想要回退策略的人	不想維護服務的人
9Router	AI 編程工具路由配置	Codex、Claude Code、Provider 切換用戶	只需要普通聊天的人
OpenRouter	雲端模型聚合入口	想快速接很多模型的人	對隱私和合規要求很高的人
Ollama	本地模型運行入口	本地實驗、隱私、低成本任務	需要最強模型能力的人

你的任務越簡單，越應該少加一層。你的模型來源越多，網關才越有意義。

先判斷你為什麼需要網關

常見原因有六個：

模型價格太貴。
單一模型限流。
不同工具配置分散。
想在任務之間自動切模型。
需要本地模型兜底。
需要記錄請求和成本。

如果每天大量跑 Agent，網關才開始有價值。

不建議上網關的情況

你還不知道主要用哪個 Agent。
你沒有統計過 token 成本。
你沒有遇到限流。
你不需要多模型。
你沒有維護本地服務的時間。
你的任務涉及敏感資料但沒有審計方案。

模型回答錯了，你會分不清是模型問題、路由問題、Key 問題還是工具問題。

OmniRoute：適合多模型路由和自託管

OmniRoute 適合想把多個模型 Provider 收到一個入口的人。它通常用本地或遠程服務暴露 OpenAI 兼容接口。網關負責選擇上游模型、處理回退、管理 Key 和策略。

如果你已經看過安裝教程，可以參考 OmniRoute 教程。如果要部署到 VPS，可以看 OmniRoute 遠程 VPS 部署。

OmniRoute 適合的任務

給多個編程工具提供統一 API。
把免費額度、便宜模型和強模型組合起來。
給失敗請求設置回退。
在本地控制 Provider Key。
做團隊內部模型入口。
統計不同模型的實際使用。

OmniRoute 的代價

它是一層服務。服務就需要運行、升級、備份和監控。如果部署到遠程 VPS，還要處理 HTTPS、訪問控制、防火牆和日誌。如果團隊成員都通過它訪問模型，它會變成關鍵路徑。

所以 OmniRoute 更適合有持續需求的人。不適合只想臨時試一個模型的人。

9Router：適合 AI 編程工具配置切換

9Router 更像面向 AI 編程工具的路由和配置管理層。它的重點不是替代所有模型平台。它更適合解決「今天用 Claude，明天用 Codex，後天接本地 OpenAI 兼容接口」的切換問題。

如果你主要在 Claude Code、Codex、MCP、本地 OpenAI 兼容接口之間切換，9Router 的搜索意圖很清晰。站內已有兩篇相關教程：

9Router 適合的任務

管理 Claude Code 的 API Base URL。
切換 Codex 或兼容接口。
管理多 Provider 配置。
減少手動改配置文件。
排查模型路由不生效。
作為個人開發環境的配置層。

9Router 的邊界

它不是萬能成本優化器。它也不是模型質量保證器。它解決的是入口和配置。

如果上游模型本身慢、貴或不穩定，9Router 只能幫你切換，不能讓模型變強。如果你需要複雜自動回退、團隊共享入口或集中審計，可能要看 OmniRoute。

OpenRouter：適合快速接入雲端多模型

OpenRouter 的優勢是快。你不用自己維護一堆 Provider。一個平台就能接入許多模型。對開發者來說，它經常作為 OpenAI 兼容接口使用。很多 Agent、聊天工具、腳本和原型專案都能較快接上。

OpenRouter 適合的任務

快速測試不同模型。
做原型驗證。
給小工具接入多個雲模型。
避免分別註冊多個平台。
用統一帳單管理一些模型調用。

OpenRouter 的限制

它是雲端中轉。請求內容會經過第三方平台。不同模型的可用性、限速、價格和上下文限制也會變化。

如果你的程式碼包含敏感業務邏輯、客戶資料或私有倉庫上下文，需要先看隱私和合規要求。對個人實驗，它很方便。對企業生產，要更謹慎。

Ollama：不是網關，但常常是本地兜底入口

Ollama 的角色不一樣。它主要負責本地運行模型。你可以把它暴露成兼容接口，再讓 Codex、Claude Code 或其他工具調用。但它不等於雲模型網關。它更像本地模型服務。

如果你想把本地模型接給 Codex，可以看本地大模型 API 給 Codex 使用教程。如果遇到 Codex 接 Ollama 報錯，可以看 Codex 本地大模型接入 Ollama 常見報錯。

Ollama 適合的任務

私有草稿處理。
低風險程式碼解釋。
簡單腳本生成。
本地知識庫實驗。
離線環境演示。
低成本批量任務。

Ollama 不適合的任務

高難度跨文件重構。
複雜安全審查。
對準確率要求很高的生產決策。
很長上下文的商業程式碼庫。
需要最新模型能力的任務。

本地模型的優點是成本和隱私。缺點是能力、顯存和維護。如果你用消費級顯卡，還要考慮量化版本、上下文長度和併發。

成本怎麼比

成本不能只看單價。 AI 編程任務的真實成本由五部分組成：

輸入 token。
輸出 token。
失敗重試。
上下文掃描。
人工排錯時間。

便宜模型如果反覆失敗，實際成本可能更高。強模型如果一次完成，反而更便宜。

所以網關的成本優化目標不是永遠選最低價。更合理的是按任務分層。

任務	推薦模型策略
改 `README`	便宜模型或本地模型
查配置錯誤	中等模型
跨文件 Bug	強模型
程式碼審查	強模型 + 圖譜
批量翻譯	便宜穩定模型
隱私草稿	本地 Ollama
長任務 Agent	強模型優先，失敗再回退

穩定性怎麼比

穩定性主要看四件事：

上游模型是否穩定。
網關是否穩定。
配置是否可追溯。
失敗時是否能回退。

OpenRouter 的好處是免維護。但你依賴平台可用性。 OmniRoute 的好處是可控。但你要維護服務。 9Router 的好處是貼近編程工具配置。但它更偏個人或小團隊配置層。 Ollama 的好處是本地可控。但模型能力和硬體是上限。

隱私和安全怎麼比

如果程式碼敏感，先問三個問題：

請求會經過哪裡？
日誌保存在哪裡？
誰能看到 Provider Key？

OpenRouter 方便，但請求經過雲端聚合平台。 OmniRoute 自託管可控，但如果部署不當也會暴露入口。 9Router 要重點保護本地配置文件。 Ollama 本地隱私最好，但也要防止把模型服務暴露到公網。

最低安全清單

不把 API Key 寫進倉庫。
不把網關端口暴露到公網。
遠程網關必須加認證和 HTTPS。
日誌不要記錄完整 Prompt。
團隊共享 Key 要設置額度。
本地服務只監聽 127.0.0.1。
生產程式碼上下文不要隨便發給未知模型。
重要任務保留人工審查。

Codex 和 Claude Code 怎麼接

大多數網關會提供 OpenAI 兼容接口。你需要關注兩個配置：

base_url。 model。

有些工具還需要 api_key。概念上是這樣：

1

client -> http://localhost:PORT/v1 -> gateway -> upstream model

或者：

1

client -> cloud router endpoint -> selected model

不要把 Provider Key、網關 Key、模型名混在一起。很多報錯都來自這裡。

接入前先做最小測試

先不用 Codex。先用一個簡單請求測試網關。

1

curl http://localhost:PORT/v1/models

確認網關能返回模型列表，再接 Agent。這樣排錯更清楚。

給不同工具的建議配置思路

Codex

Codex 更適合穩定工作區和明確權限。如果接網關，先保證 OpenAI 兼容接口可用。再確認模型名、base URL、API Key 和上下文限制。

不要一開始就把複雜回退鏈路接進去。先用一個模型跑通讀文件、改文件、運行命令、彙報 diff、解釋測試失敗。這些都穩定後，再用網關做成本優化。

Claude Code

Claude Code 用戶更容易遇到配置切換問題。如果只是切換 Provider，9Router 會更貼近場景。如果要把 Claude Code 接到統一團隊入口，再看 OmniRoute 或 OpenRouter。如果要運行本地模型，要先接受能力差異。本地模型適合解釋、草稿和低風險任務。不適合直接承擔複雜重構。

Cursor

Cursor 的優勢在 IDE 內互動。如果你只在 Cursor 裡寫程式碼，未必需要單獨網關。如果你希望 Cursor、Codex、Claude Code 都使用同一套模型入口，網關才有價值。這時重點不是 Cursor 配置本身，而是統一模型名和日誌。

自建 Agent

自建 Agent 最適合接網關。因為你能控制請求格式、重試策略、日誌和模型選擇。可以把任務分成草稿生成、程式碼解釋、單文件修改、跨文件修改、審查總結、文檔整理、批量翻譯。不同任務走不同模型。這才是網關真正能節省成本的地方。

採購或長期使用前的十個問題

在把網關變成長期入口前，先回答這些問題：

誰負責維護配置？
誰能看到 API Key？
誰能修改模型路由？
請求日誌保留多久？
是否記錄完整 Prompt？
是否設置單人額度？
是否設置團隊額度？
是否有失敗回退？
是否能快速切回官方入口？
是否能導出成本資料？

如果這些問題沒有答案，先不要把網關放到團隊關鍵路徑。個人使用可以更輕。團隊使用必須更穩。

網關的觀測指標

只看「能不能回答」不夠。網關至少應該觀察調用、成本和質量。

調用指標包括請求次數、輸入 token、輸出 token、平均延遲、P95 延遲、失敗率、重試次數、429 次數、401 次數和上游模型分布。成本指標包括每日成本、每任務成本、每模型成本、失敗重試成本、長上下文成本、批量任務成本、本地模型電費和硬體折舊。質量指標包括一次完成率、人工返工次數、測試通過率、程式碼審查通過率、錯誤修復輪次、因模型能力不足失敗的次數。

個人用戶可以先用表格記錄一週。團隊用戶再考慮接入監控。

典型錯誤配置

把上游 Key 當成網關 Key

很多網關會同時涉及 Provider Key 和客戶端訪問 Key。二者不是一回事。 Provider Key 用來訪問模型供應商。客戶端 Key 用來訪問你的網關。混用以後常見結果是 401。

模型名寫錯

不同平台模型名可能不同。同一個模型在不同路由平台也可能有別名。先查 /v1/models。再配置 Agent。不要直接憑記憶填。

把本地端口暴露到公網

Ollama、OmniRoute 或本地兼容接口默認應該只給本機用。如果要遠程訪問，必須加認證、HTTPS 和防火牆。否則等於把模型入口交給別人。

把所有任務都走便宜模型

便宜模型適合簡單任務。複雜任務失敗重試會抵消節省。更好的策略是按任務分層，而不是按最低單價分層。

選型場景

個人開發者可以保留 Codex 官方入口、Claude Code 官方入口、Ollama 本地兜底，必要時加 9Router。高頻 Agent 用戶可以使用 OmniRoute 或 OpenRouter，再用 9Router 管理本地工具配置。小團隊應該設置統一入口、每人獨立權限、請求日誌脫敏、模型白名單、成本上限和人工 PR 審查。私有程式碼環境更適合本地 Ollama、私有部署 OmniRoute、嚴格出網策略，不要把敏感倉庫發給公共中轉。

什麼時候保留簡單方案

如果你每週只用幾次 Agent，保持官方入口。如果你只用一個模型，保持官方入口。如果你沒有遇到限流，保持官方入口。如果你沒有成本壓力，保持官方入口。如果你不想維護服務，保持官方入口或 OpenRouter。如果你只是想體驗本地模型，用 Ollama 即可。

工具越少，排錯越容易。

未來可以擴展的文章

後續可以繼續拆出更窄的搜索頁：

Codex 接 OpenRouter 怎麼配置。
Claude Code 接 9Router 常見錯誤。
OmniRoute 和 OpenRouter 成本對比。
Ollama 適合跑哪些 Codex 子任務。
AI 編程模型路由規則怎麼寫。
團隊共享 AI API Key 怎麼限額。
本地 AI 網關日誌如何脫敏。
模型自動回退會不會影響程式碼質量。

收束：先看任務再選入口

想快速試很多模型，選 OpenRouter。想管理 AI 編程工具配置，選 9Router。想自託管統一入口和回退，選 OmniRoute。想要本地隱私和低成本實驗，選 Ollama。

真正的關鍵不是哪個名字更熱。關鍵是你的任務是否需要多模型、回退、審計和成本控制。如果答案是否定的，先別加網關。如果答案是肯定的，就從最小入口開始，不要一次把所有工具都接進來。