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。真正的关键不是哪个名字更热。关键是你的任务是否需要多模型、回退、审计和成本控制。如果答案是否定的，先别加网关。如果答案是肯定的，就从最小入口开始，不要一次把所有工具都接进来。