ModelPlane 对比 OpenRouter

ModelPlane 和 OpenRouter 都是把多个 LLM Provider 收敛到一个 API 背后的网关。两者的核心差异在于「路由」到底路由的是什么，以及你实际在管理的基础设施单元是什么。

路由模型

OpenRouter 的路由发生在单个模型内部：给定 anthropic/claude-sonnet-4，它决定由哪个上游 Provider 来服务这次调用——默认按价格加权做负载均衡，也可以用 sort（按价格 / 吞吐 / 延迟排序）、order（显式顺序列表）、allow_fallbacks、max_price，以及 preferred_max_latency 之类的性能过滤条件做显式控制。

ModelPlane 的 Model Group 路由的是你自己拥有的一个稳定名称，而不是某个具体的 model ID。一个 Group 的 fallback 树可以在同一个名称背后混合不同的模型和不同的 Provider，并且比 OpenRouter 的 Provider Selection 多出两个路由维度：

路由能力	OpenRouter	ModelPlane
按价格 / 吞吐 / 延迟排序 Provider	支持	—
显式 fallback 顺序	支持	支持
同一模型跨 Provider 的负载均衡	支持	支持，且可跨不同模型 / backend
按请求 metadata 做条件分支（客户层级、workload 类型、产品）	不支持	支持
按 backend 做基于并发的溢出路由	不支持	支持

如果你的路由诉求是「这个具体模型该由哪个 Provider 来服务，优先选最便宜或最快的」，OpenRouter 的 Provider Selection 已经能很好地覆盖。如果诉求是「这个业务 workload 该路由到哪个合适的 backend，并且限制单个 backend 能承担多少负载」，那是 Model Group 要解决的问题。

Coding Plan Backend

OpenRouter 的 Claude Code 集成让 Claude Code 直接对接 OpenRouter，费用从你的 OpenRouter credits 里扣——这本质上是通过 OpenRouter 自己的模型目录获取访问权限，而不是帮你管理一个你已经在付费的订阅。

ModelPlane 的 Coding Plans 走的是相反的路径：你把一个自己已经在付费的订阅制 Coding Plan 账号（比如 Claude Code Max 式的 plan、Copilot 式的 plan）注册为一个 backend。把它放在某个 Group 的第一层 fallback，后面接一个 metered backend，Usage 与 Billing 页面会把 plan 的 quota 和重置时间与消费一起展示——这样 coding agent 会优先消耗你已有的 plan 容量，只有在容量耗尽时才会溢出到按量计费的 API 消费。

Workspace、Organization 与计费

两个平台都把工作拆分到项目维度，计费则汇总在账号层级，而不是按项目单独计费。在 ModelPlane 里，这对应 Workspace 与 Organization：每个账号自带一个个人 Default Workspace，付费 Startup plan 解锁额外的个人 Workspace，Organization 让所有成员 Workspace 共享同一份 credit 余额，同时仍然按 Workspace、API key、Model Group、backend 归因用量。降级或扣款失败时，Workspace 会进入明确的 suspended（可读、配置写入被阻止）或 archived（key 被吊销）状态，而不是悄无声息地中断流量。

如果你已经在用 OpenRouter 的 Workspace 模型且用得顺手，单凭这一点切换网关的理由并不充分——真正值得看 ModelPlane 的原因是上面提到的路由能力和 Coding Plan backend 的处理方式。

各自适合的场景

OpenRouter 适合你每次只调用一个模型、希望这个具体模型由最便宜或最快的可用 Provider 来服务，费用统一从一份 OpenRouter credit 余额里扣除的场景。

ModelPlane 适合你的应用需要在整个生命周期里调用同一个稳定 model 名称、而背后的 backend 会不断变化的场景——把自有的 Coding Plan 容量和 metered fallback 混合使用，按客户层级或 workload 做分支，并按 backend 限制负载，而不只是在出错后被动反应。