OpenRouter 的禁转售条款：二次分发的边界在哪

真正逼着人去读条款的通常不是技术问题，是法务的一句提问。产品里内嵌了模型能力，上游走的是 OpenRouter，法务在评审时问：我们自己的用户协议里，要不要为这件事写点什么？

回去翻 openrouter.ai/terms，会发现跟这个问题直接相关的有两处，而且这两处的性质完全不同：一处是禁令，禁止你拿它做某类事；另一处是义务，要求你去约束你的下游。大多数讨论只注意到前一处，后一处才是法务那句提问的答案所在。

这篇只做一件事：把这两段原文原样摆出来，逐句说清它们各自约束的是哪些现实做法。判断不在这里——条款怎么解释、你的业务本质怎么定性，要你带着原文去问律师。至于接入、计费这些操作层面的事，在 OpenRouter 使用与计费详解 里，这篇不重复。

一、先把两段原文摆出来

第一段，服务条款第 7 节禁止行为清单里的第 4 项，英文原文：

access the Site or Service for purposes of reselling API access to Models or otherwise developing a competing service

第二段，第 5.2 节，英文原文：

You will require that all of your Authorized Users and customers access and use the Service and Models only in accordance with this Agreement, any documentation provided by OpenRouter on the Site and Service, and the applicable Model Terms.

下面的中文都是对这两段的解读，原文以上面这两段为准。凡是我的解读与原文对不上的地方，以原文为准，不以我的转述为准——这也是为什么这两段要原样抄在最前面，而不是只给译文。

二、第 7 节第 4 项：两件事被并列写在同一项里

这一项的写法值得逐个词看。它禁止的行为是 access the Site or Service，后面跟的是目的状语 for purposes of，再往后是两个被 or otherwise 连起来的东西：reselling API access to Models 与 developing a competing service。

这个结构有两层含义。

一层是，被约束的动作是「访问」，而不是「转售」本身。也就是说落在这一项里的判断起点是你以什么目的访问它的服务，不是你有没有真的卖出去过。

另一层更关键：转售 API 访问与开发竞品被写在同一项里，中间是 or otherwise。常见的一种自辩是「我没有在卖 key，我是把模型能力包进了自己的产品」——这句自辩能不能让你从这一项里出来，取决于这一项在合同解释上的边界怎么划，尤其是 otherwise developing a competing service 这半句覆盖到哪里。OpenRouter 自己就是一个聚合网关，所以「竞品」在这里不是一个空泛的词，它有明确的现实指向。这句话在你的业务上怎么落地，是典型的需要拿原文去问的问题。

我能给的只有一个动作建议：把上面那段英文原样复制下来，连同你产品的真实形态描述（你卖给谁、卖的是什么、模型能力在你的产品里占多大比重）一起交给律师，而不是自己按字面直觉判一遍就过。

三、第 5.2 节是义务，不是禁令

第 5.2 节经常被归到「禁转售」这个话题里一起提，但它的语法结构是 You will require that...——主语是你，动词是「要求」。它不是在禁止你做什么，是在给你派一项任务：你必须去要求你的 Authorized Users 和 customers 按规定使用服务与模型。

被要求遵守的东西，原文列了三样，不是一样：

• this Agreement——OpenRouter 自己的这份协议；
• any documentation provided by OpenRouter on the Site and Service——它在站上和服务里提供的任何文档；
• the applicable Model Terms——适用的模型条款。

这三样里，第二样最容易被漏掉。很多人读完条款页就以为读完了，但原文把「站上和服务里的文档」也写进了约束范围。这意味着文档页上的说明不是纯参考资料，它在这份协议里被赋予了约束力。

对法务那句提问来说，第 5.2 节就是答案：既然协议要求你去约束下游，那么你自己的用户协议里就得有对应的条款，把这三层约束往下传。这不是可选项，是原文里写着的一项要求。具体怎么落成文字——写成引用链接、写成概括性条款、还是逐条复述——是起草层面的选择，这一步要律师来做。

四、customers 这个词的存在，说明条款不是笼统禁止你有下游

把两段原文并排看，会发现一个容易被忽略的事实：第 5.2 节里明明白白出现了 Authorized Users and customers 这两个词。协议本身预设了你可能有授权用户、可能有客户，并且为这种情形专门派了一项义务。

所以「有下游用户」这件事本身并没有被这两段原文笼统禁掉。第 7 节第 4 项禁的是带着特定目的去访问服务，第 5.2 节管的是你有了下游之后该做什么。这两条并存，说明边界不在「你有没有别人用」，而在「你访问服务的目的是什么」。

这个区分很实际。一个把模型能力当成功能之一的业务系统，和一个把 API 访问本身当成商品的服务，在这两段原文下的位置可能完全不同。但「可能不同」不等于「一定在界内」——这条线具体画在哪，同样是拿原文去问的问题，不是读完这篇就能定的。我在这里只负责指出条款里有这个区分，不负责替你把你自己放到线的哪一边。

五、Model Terms 随模型走，而同一个模型 id 背后不一定是同一家

第 5.2 节最后那半句 the applicable Model Terms 有个很容易低估的后果：你要核的条款数量，跟你实际调了哪些模型有关，而不是一份协议就封顶。

这件事在 OpenRouter 这种形态上还要再复杂一层。我们在 2026-09-15 用它官方的 /api/v1/models/{id}/endpoints 接口逐个查过：开源权重的模型在它上面往往同时有好几家托管方在供货，彼此并列；而闭源旗舰模型常常只有厂商自己一个入口。这是那一天的快照，供货方名单是会变的。

把这条机制和 applicable 这个词放在一起看，要确认的问题就具体了：你这次调用实际落到哪家供货方、适用的是哪一份 Model Terms、路由换了供货方之后适用的条款会不会跟着换。这几个问题的答案不该靠推测，要按站上和服务里的文档去核——而按第 5.2 节的写法，那些文档本身也在约束范围里。模型清单是怎么被堆出来的、多供货方这件事还会带来哪些影响，跟条款无关的那部分不在这篇展开。

六、自建网关和 BYOK 都不自动改变这两条的适用

有两个常见推理在这两段原文面前是断掉的，值得单独点出来。

一个是「我自己部署了网关，所以我不算转售」。自建网关（one-api、new-api 那一类）解决的是多上游统一管理、key 分发、用量统计这些问题，它不产生供给。你的上游 key 还是上游平台发的，第 7 节第 4 项约束的是你访问服务这个动作，跟请求中间经过了你自己的哪台机器没有关系。自建与托管这两条路各自解决什么问题，在 自建网关与托管服务怎么选 里另有梳理。

另一个是「我用的是 BYOK，key 是我自己跟厂商签的」。BYOK 把「谁跟上游签约」这件事挪回到了你自己头上，这确实改变了你和模型厂商之间的关系结构，但你仍然在 access the Site or Service——你用的是 OpenRouter 的路由、统一协议和账务这套服务。第 7 节第 4 项的判断起点是访问目的，它不因为上游 key 换了归属就自动不适用。

七、平台自己写明的一条方向相反的通道

只讲禁令会给人一种「这条路整个堵死」的错觉，所以要补上另一半：OpenRouter 的文档里，还写着一条方向完全相反的正式通道——不是你从它这里拿货再往下卖，而是你给它供货。

它对供货方给了成文的接入要求：必须实现 List Models 端点，返回带类型的输入输出模态、能力、约束、定价和容量；至少声明一种输入与一种输出模态；用 USD 字符串声明输入、输出、请求这三个维度的价格；声明吞吐容量；满足正常路由所需的可用率门槛；支持性能指标采集。其中有一条把资金流向写得很直白，原文是：

For OpenRouter to use the provider we must be able to pay for inference automatically.

也就是说在这条通道上，是 OpenRouter 付钱给供货方，不是用户付钱给供货方。这跟前面那两段原文合起来看，图景就清楚了：往下游二次分发它的 API 访问被写进了禁止行为清单，而往上游给它供货是一条有成文要求的流程。一个方向是禁令，另一个方向是申请表。

这条通道对绝大多数读者不适用——它要求你手里真的有推理能力可供。但它至少说明一件事：这家平台并不排斥「第三方对外提供模型 API 服务」这种形态本身，区别在于走没走它成文的那道流程。跟这条产业链上各方的位置有关的拆解，在 API 中转站的合规边界 里按上游条款、厂商条款、监管义务三层分开讲过，这篇不重复那部分。

八、拿着这两段原文，你该去确认的几件事

这一节给的全是问题，不是答案。

关于第 7 节第 4 项：我这个产品的形态，交给律师看过没有？描述给律师的时候，我有没有把「模型能力在产品里占多大比重」「客户实际买的是什么」说清楚？我有没有在任何对外的宣传语里，把「API 访问」本身当成卖点在卖？

关于第 5.2 节：我自己的用户协议里，有没有把这三层约束往下传的条款？我调的那几个模型，各自适用的 Model Terms 我核过没有？如果我的路由会在多家供货方之间切换，适用条款会不会跟着变，我确认过没有？站上和服务里的文档，我是当参考资料读的还是当约束条件读的？

关于变化：条款是会改的。我上一次通读这两节是什么时候，产品形态自那以后变过没有？

九、按同一套标准，力达云该被问什么

上面全是让你去查别人，那这个站自己也得摊开。这些是 /api-terms/ 里的原文口径：力达云网关是一个独立运营的第三方模型接入服务，接收你按 OpenAI 或 Anthropic 格式发出的请求，转发给上游模型服务商，再把结果返回给你；我们与 DeepSeek 及其他任何模型厂商没有官方合作、代理或授权关系，也不是它们的关联方。

限制一并说清：一期只接 DeepSeek，模型广度上没有什么可比的；身份上是独立第三方。所以第八节那几组问题，你原样拿来问我们是合理的，条款原文和我们自己披露的边界都在 /verify/，你自己去核，不用信这篇文章的自述。

十、这篇不能替代法律意见

最后这句必须说明白：这篇文章不构成法律意见，也替代不了法律意见。

上面每一句英文都是 openrouter.ai/terms 与官方文档上公开可查的原文，我的中文部分是解读。原文的作用是帮你把问题问对——知道该翻哪一节、该确认哪一句话；解读的作用到此为止，它不构成对你具体业务的判断。同一段条款落在不同的业务形态上，结论可能完全不同，而你的业务细节我看不到，也不该替你猜。

还有一种情况是这篇对你意义不大：你就是一个人拿自己的账号写代码自己用，不转给任何人，也不对外提供服务。那第 5.2 节那一整套下传义务基本跟你无关，你只需要留意条款是会变的这一点。

但如果你打算把模型能力做成对外收钱的产品，别省那一步。把这两段英文原文、你自己的用户协议草稿、以及你产品的真实形态描述一起拿给律师看一遍。这一步要花的时间，跟事后返工改协议、改产品形态比起来不是一个量级。