OpenRouter 免费模型限制有哪些：速率、上下文与可用性机制

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

先把结论摆出来：OpenRouter 对免费模型的约束不是一条限制，而是四层叠在一起。第一层是额度限制，管你能花多少，来源是账户余额和单个 API key 上可选的消费上限；第二层是速率限制，管你能发多少请求，免费变体有每分钟和每日两档请求上限，另外还有 Cloudflare 的 DDoS 防护兜底；第三层是上下文，由模型自身的 context_length 决定，输入和输出共用同一个窗口；第四层是可用性，免费模型的供应会变、模型会被安排下线，而你自己的隐私设置还会主动砍掉一部分可路由的供应商。这四层对应的排查入口完全不同，把它们混成一句「免费的就是限制多」，排起故障来只会原地打转。还有一件事值得先说：官方描述 :free 变体时的原话只提了两件事——速率限制和可用性可能与付费版不同，这句话里没有提到上下文。所以别按「免费所以窗口缩水」去猜，上下文要按具体模型的字段去查。

先分清两类限制：一类管你能花多少，一类管你能发多少

官方限额文档开篇就把限制分成了两类，并且给了各自的排查入口，这张分工表是后面所有排查动作的地基：

• Credit limits（额度限制）：管的是消费能力，来自账户余额与按 key 配置的消费上限，触发时报的是额度不足类错误，查询入口是 GET /api/v1/key 响应里的 limit_remaining。
• Rate limits（速率限制）：管的是请求次数，具体包括免费模型的请求上限和 DDoS 防护，触发时报的是限流类错误，查询入口是错误响应上的 X-RateLimit-* 响应头。

注意第二行那个入口写得很具体：是错误响应上的头。官方还专门加了一条说明——成功的推理响应不会带 X-RateLimit-* 头。这意味着你没法靠正常调用的响应头来做实时水位监控，官方给出的场景是：OpenRouter 因平台限制返回错误时，错误响应会带上这些头。想在撞墙之前知道自己还剩多少，官方给的办法是主动去调 GET /api/v1/key。

这个 key 信息接口的返回结构值得逐字段看一眼，它是免费用户重要的自查窗口之一：limit、limit_reset、limit_remaining 三个字段描述的是这把 key 上的消费上限及其剩余与重置方式（为 null 表示不限）；usage、usage_daily、usage_weekly、usage_monthly 是累计消费与按日、按周、按月的消费，官方注明日、周、月都按 UTC 口径，且周从周一开始；byok_usage 系列是自带 key 用量的同款统计；还有一个很多人没注意的布尔字段 is_free_tier，官方对它的解释是「该用户此前是否付过费」。如果你想在代码里判断当前账户是不是还处在免费层，这个字段比任何自己维护的标记都可靠。响应里另有一个 rate_limit 对象，官方明确标为已废弃、可以安全忽略——别再照着老教程去读它了。

顺带说一句，这两类限制的边界经常被读者搞混：额度耗尽和请求超频是两码事，前者充值才能解，后者充值只能提高上限但当下那一秒依然要等。关于通用的限流口径与退避写法，可以对照 API 限流的 RPM 与 TPM 机制 一起看。

速率限制：换个账号、多开几把 key 都没用

官方在限额页最靠前的位置放了一条提示，几乎是直接冲着「多开账号绕限流」这种做法来的：新建更多账号或更多 API key 不会改变你的速率限制，因为容量是在全局层面统一治理的。这句话把最常见的一条土办法直接堵死了。

但同一条提示的后半句给了一条官方认可的替代路径：不同模型的速率限制是不同的，所以如果确实撞上了限制，可以把负载分摊到不同模型上。这是个很实在的建议——它的前提是你的任务本身能容忍模型切换，比如批量摘要、分类这类对具体模型不敏感的活儿。

免费变体本身的限制结构是这样的：只要模型 ID 带免费后缀，就适用每分钟请求数和每日请求数两档上限；这两档上限按累计购买过的额度分档，购买量跨过官方门槛之后，每日请求上限会提高。具体的门槛与各档上限数值请以官方限额文档为准，本文不做转录——这类数字是会调整的。

除此之外还有一层跟账户状态无关的兜底：Cloudflare 的 DDoS 防护会拦截显著超出合理用量的请求。它不看你是不是付费用户，只看请求形态。

官方给出的提额路径只有两条，写得很直白：在免费变体上购买额度到官方门槛以上，把每日上限抬高；或者干脆切到该模型的付费变体——付费变体没有平台层面的请求次数上限。这句话解释了一个很多人纠结的问题：从免费转付费买到的不只是更多次数，而是「平台不再对次数设限」这个性质上的差别。至于哪些免费模型值得先用起来，可以参考 OpenRouter 免费模型怎么用。

429 到底是谁给的：平台限流和上游限流要分开处理

被限流时返回的错误体是标准形态，error.code 是 429，message 是限流提示，metadata.error_type 是 rate_limit_exceeded。但光看这个体分不出责任方，官方明确说 429 可能来自两个地方：

1. OpenRouter 自己，也就是你撞上了上面那些平台限制——免费模型的每分钟或每日请求上限，或者 DDoS 防护。
2. 上游供应商，也就是实际承接这次请求的那家在限流或已满载。这种情况下 error.metadata.provider_code 会带上供应商自己的原始错误码（在能拿到的时候）；而且在错误传到你手上之前，回退路由已经自动为同一个模型重试过其他供应商了。

区分方式就藏在响应头里：当 OpenRouter 因为平台限制返回错误时，错误响应会带 X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset 三个头，描述被触发的是哪一条限制。另一个头 Retry-After 的出现条件更苛刻——官方原话是，当所有尝试过的供应商都给出了重试提示时，错误响应才会带上它。所以你的重试逻辑不能假设这个头一定存在，它只是「有就必须尊重」，没有就退回到自己的指数退避。

官方给的三条处置办法，按责任方分得很清楚：做带指数退避的重试，因为限流是暂时的，别立刻重发，有 Retry-After 就照它来；在免费变体上，走购买额度提额或切付费变体；如果判断是供应商侧的限制，就加上回退模型，或者放松供应商路由偏好，让更多供应商有资格接这个请求。

还有一种 429 特别容易在生产里被漏掉：流式开始之后才触发的限流。因为 HTTP 状态早就发出去了，这时错误不会以 HTTP 状态码的形式出现，而是作为 SSE 事件送达，chunk 里带 error 字段，choices[0].finish_reason 是 "error"。如果你的客户端只在 HTTP 层判错，这类失败会表现成「回答莫名其妙断了」，日志里干干净净什么都看不到。更细的排查顺序见 OpenRouter 429 报错怎么处理。

上下文：官方对免费变体的说明里，其实没提上下文

前面说过，官方对 :free 变体的完整说明是：免费变体让你免费用到模型，但速率限制或可用性可能与付费版不同。这句话里没有上下文窗口这一项。因此「免费版上下文更小」这个流传很广的说法，至少在这份文档里找不到出处，本文不做这个断言。

那上下文到底看什么？官方给的是模型数据本身：

• 模型对象上的 context_length 字段，含义是最大上下文窗口大小，单位是 token。
• top_provider 对象里另有一个 context_length，官方注释写的是「provider-specific context limit」。注意这个限定词：它描述的是那家供应商的上下文上限，而不是模型的通用属性，两个同名字段在文档里是分开定义的。
• top_provider.max_completion_tokens 是响应的最大 token 数。
• 还有一个 is_moderated 布尔字段，表示这家供应商是否施加内容审核。

紧接着官方补了一句关键说明，我建议逐字记住它的逻辑：输入和输出共享模型的上下文窗口，所以 max_completion_tokens 只是 max_tokens 的天花板，不是保证能拿到的输出长度；一次请求实际能产出的最大输出，取决于输入占掉之后还剩多少上下文。请求参数层面也是同一套约束——官方对 max_tokens 的取值范围标注是从 1 到 context_length（不含）。

窗口撑爆时对应的错误类型叫 context_length_exceeded，官方描述是「输入与输出 token 的合计超出了模型的上下文窗口」。注意它算的是合计，不是只算你发过去的那部分，这也解释了为什么有些请求提示词明明没超，仍然会在生成到一半时报错。另外在 OpenAI Responses API 的兼容层上，这个错误的表现形式还会变——官方说明它可能被转换成一个成功响应，finish_reason 是 "length"，而不是被当作错误抛出。跨接口迁移时这一条尤其容易造成误判。

装不下的时候，官方给的是压缩而不是截断

如果输入确实超了窗口，OpenRouter 提供一个按请求启用的上下文压缩插件（plugins: [{ id: "context-compression" }]，官方注明适用于任何模型）。它的做法是从提示词的中间删除或截断消息，直到能塞进窗口；官方给的理由是模型对序列中间部分的注意力更弱。启用之后还有一层路由影响：OpenRouter 会先找上下文长度至少达到你所需总 token（输入加输出）一半的模型，找不到才退回到可用上下文最大的那个。反过来，如果压缩是关着的而总 token 超了窗口，请求会直接失败，错误信息会建议你要么缩短内容、要么启用压缩。

还有两个细节值得记：一是有些模型限制的不是 token 而是消息条数（官方举的例子是 Claude 系列有条数上限，具体数值本文不写），触发时压缩插件会保留开头一半和结尾一半的消息；二是官方说明上下文较小的端点会默认启用压缩（具体阈值以官方文档当前版本为准），要关掉得显式传 plugins: [{"id": "context-compression", "enabled": false}]。只输出图片的图像生成模型会自动跳过压缩，否则参考图会被当成中间内容删掉。

最后一个跟上下文有关的历史包袱：:extended 变体已废弃，目前 OpenRouter 上没有任何模型提供它，请求带这个后缀的 slug 会因为无端点可路由而失败。官方给的替代做法是直接用基础模型 slug，然后挑一个标准上下文能装下你输入的模型；模型浏览页和模型 API 都会列出每个模型的 context_length，模型确实支持的静态变体也会作为独立条目出现在那里。

可用性：免费模型池是会变的

这一层是免费用户最需要提前设计的。官方在免费模型路由器的文档里专门列了「Limitations」一节，其中两条直接关于可用性：免费模型的速率限制可能低于付费模型；免费模型的可用性会变化，有些可能临时不可用。同一页还挂了一个警示框，措辞是免费模型的可用性经常变动，当前有哪些请以模型页为准。

openrouter/free 这个免费模型路由器的工作方式，官方拆成了五步：分析请求需要哪些能力（比如图像理解、工具调用、结构化输出）→ 在可用免费模型里筛出支持这些能力的 → 从筛后的池子里随机选一个 → 转发请求 → 在响应里带上实际使用的模型。所以响应体的 model 字段是你唯一能确认「这次到底是谁答的」的地方，做日志的话务必把它落下来。官方也把这个路由器的边界说清楚了：你不能控制具体选中哪个模型，需要指定就得用某个模型的 :free 后缀。

模型被彻底下线也有官方信号可用。模型 API 的模型对象上有 expiration_date 字段，含义是该模型端点的废弃日期，未废弃时为 null——这是可以程序化监控的。另外账号设置里有一类通知叫「模型废弃提醒」，官方说它不需要设置任何触发条件，当你近期用过的模型被安排退役时，提醒会告诉你是哪个模型、什么时候下线、以及应该迁到什么。免费模型换代快，把这个开关打开比自己盯模型页省事得多。

运行期的不可用则落在两个错误类型上：provider_overloaded 表示上游供应商临时过载，稍后重试；provider_unavailable 表示上游返回了无效或空响应，并且如果你开了回退路由，OpenRouter 可能自动换一家供应商重试。注意这里官方用的是「可能」。更完整的区分方法见 OpenRouter 模型不可用怎么排查。

隐私设置会悄悄缩小你的可用池

这一条几乎没人主动去查，但它实实在在影响免费模型能不能路由出去。OpenRouter 把每家供应商的数据处理策略结构化地标在了各自的端点上，你可以在账号设置里决定是否允许路由到那些可能用你的数据做训练的供应商（按各家自己的政策）。官方特别注明：付费模型和免费模型是两套独立的设置。

后果写得很直接：如果你在账号设置里选择了不参与训练，OpenRouter 就不会把请求路由到会训练的供应商。这是路由层面的过滤，不是提示或标注——不合策略的供应商直接不参与这次路由。官方同时说明，只要条件允许，它会跟供应商争取「不用你的提示词做训练」，但存在例外；另外这个设置只管路由，跟 OpenRouter 自己怎么处理你的提示词是两回事。除了账号级开关，官方还提供了按数据策略限制单次请求的能力，用于给个别调用单独收紧。

至于关掉之后具体还剩下多少家供应商能接免费模型，官方文档里没有找到相关说明，这个数字只能靠你自己在模型页和路由结果里观察。另外，工具侧也把它当成一个正式维度：Guardrail 的配置项里就有 enable_free_model_training，官方对它的解释是「该 guardrail 是否允许会用请求数据做训练的免费端点」，付费侧还有一个对应的独立开关。也就是说，免费与付费的训练许可在账号设置和 guardrail 两个层面都是分开的。

如果你所在的组织对数据流向有硬性要求，这个设置该开就开，只是要意识到它和免费模型的可用性是此消彼长的关系——先想清楚哪一边是你的底线，再去调那个开关，而不是等报错了才反过来找原因。

还有一个反直觉的坑：余额为负会波及免费模型

很多人默认「免费模型跟余额没关系」，官方文档里的说法不是这样。原文写的是：如果账户额度余额为负，你可能会看到错误，包括在使用免费模型时；把余额充到零以上就能重新使用这些模型。

请注意官方用的是「可能」而不是「一定」，我不替它加强语气。但对排查来说，这条足够重要了：当你的免费调用突然全线失败、key 也没问题、模型也还在，值得先去看一眼账户余额是不是被某笔付费调用拖成了负数。这也是为什么 GET /api/v1/key 值得接进你的监控——它同时能看到额度侧和用量侧的状态。

至于免费模型的每日请求计数具体在哪个字段查、什么时刻重置，官方文档里没有找到相关说明；usage_daily 这些字段官方描述的是消费额而不是请求次数，别把两者当成一回事。

最后：把免费额度用在它擅长的地方

官方对免费层的定位说得比社区里的传闻诚实得多——免费模型「通常不适合生产使用」，路由器文档给出的适用场景是学习实验、原型验证、个人项目和教学演示，至于可靠性要求高的负载该怎么办，官方在这两处都没有给出建议。这不是劝退，而是在告诉你边界在哪。

真正容易栽的坑就三个：一是把额度限制和速率限制混为一谈，充值去解一个本该退避解决的问题；二是只在 HTTP 层判错，漏掉流式中途以 finish_reason: "error" 形式送达的失败；三是假设今天能用的免费模型明天还在，既不读响应里的 model 字段，也不给自己留回退模型。把这三件事在接入的时候就处理掉，免费层能撑住的场景比大多数人以为的要宽。