OpenRouter 是什么？它在模型调用链里到底解决了什么问题

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

OpenRouter 官方对自己的定位是一个统一 API：把市面上主要的大模型收在同一个端点后面，把账单聚合到一个地方，并用自家分析页统一看用量。它按官方说法「透传底层供应商的定价、同时把它们的可用性汇集起来」，也就是价格与直接找供应商一致，但你多拿到一层统一接口和故障转移。它在调用链里的身份是代理——请求从你的代码进来，由它决定发给哪个供应商、供应商挂了换谁，回包按官方说法是经过统一规范化的——官方明确写了它把不同模型与供应商的 schema 归一化，所以你只需对接一套格式。所以判断要不要用它，看的不是「它有多少模型」，而是「统一接口 + 路由兜底 + 账单归一」这三件事对你值不值得多插一跳。

先把它在调用链里的位置钉死

官方 FAQ 里有一句话最能说明问题：OpenRouter 是一个代理，负责把你的请求发给模型供应商去完成。这句话决定了它能干什么、不能干什么——模型不是它训练的，推理也不是它跑的，它管的是「这一次请求交给谁」以及「钱怎么记」。

具体到接口层面，官方文档写明它按 OpenAI 的 API 规范实现了 /completions 和 /chat/completions，所以同一套请求/响应格式可以对着任意模型用；除此之外还有 /api/v1/models 这类附加端点。对话补全的完整端点是 https://openrouter.ai/api/v1/chat/completions，鉴权用 Authorization: Bearer <OPENROUTER_API_KEY>。

官方明确说它是 OpenAI 的 drop-in replacement，因此原本支持 OpenAI 的 SDK 默认也就支持它，把 baseURL 指到 https://openrouter.ai/api/v1 即可。除了直接发 HTTP 请求，官方还给了另外两条集成路径：Client SDK（@openrouter/sdk）适合要类型安全但不想引入太多东西的场景，Agent SDK（@openrouter/agent）面向带工具调用、循环和状态的 agent。三者的取舍在官方 Quickstart 里被概括为「你想要多少控制权」。

请求头里还有两个可选项：HTTP-Referer 和 X-OpenRouter-Title。官方特意说明这两个头是可选的，填了的作用是让你的应用出现在 OpenRouter 的榜单上，跟调用本身能不能成功无关。很多人照着示例抄过去以后以为它们是必填项，其实不是。

鉴权方式官方列了三种：网页界面与聊天室用的 cookie 鉴权、访问补全类接口用的 API key（以 Bearer token 传递）、以及用于通过接口批量管理 key 的 management API key。第三种容易被忽略，它的定位是「程序化地管 key」，跟你日常调用用的那把 key 不是一回事。

它解决的第一个问题：同一个模型该走哪个供应商

这是 OpenRouter 存在的核心理由。同一个开源模型往往有多家推理供应商在提供，谁便宜、谁在抖、谁支持你请求里用到的参数，都不一样。官方文档说它默认会在排名靠前的若干供应商之间做负载均衡，目标是把可用性拉满。

默认策略官方写成了三步：先把最近出现过明显故障的供应商排除在优先级之外（具体的观察窗口以官方文档为准），再在剩下的稳定供应商里看成本较低的候选、按价格倒数的平方做加权来选一个，其余供应商留作兜底。这个加权方式挺反直觉的——它不是「一律走最便宜的」，而是让便宜的被抽中的概率显著更高，同时给次便宜的留出流量。

如果你不想要这套默认行为，可以在请求体里带 provider 对象接管。官方字段表里能用的包括 order、only、ignore、allow_fallbacks、require_parameters、data_collection、zdr、quantizations、sort、preferred_min_throughput、preferred_max_latency、max_price 等（以官方文档当前版本为准）。有两条容易踩的语义差别值得单独记：

• order 是排序不是筛选。官方说明它的作用是「按这个列表的顺序优先尝试供应商」，它不会把候选池筛空。真正会把候选筛没的是 only——它是「本次请求只允许这些供应商」。排查「没有可用供应商」的时候该查 only，查 order 是白费劲。
• preferred_min_throughput 和 preferred_max_latency 从名字看像硬门槛，实际按官方说明只是偏好，不满足的供应商被降权而不是被排除。

另外要注意一个联动：官方明确写了，一旦你设置了 sort 或 order，默认的负载均衡就会被关掉，改成按顺序尝试。也就是说你以为只是「加了个偏好」，其实顺手关掉了它原本给你做的分流。

sort 官方给的取值是 "price"、"throughput"、"latency" 三种，分别对应优先低价、优先高吞吐、优先低延迟。还有两个自动生效的路由细节：请求里带了 tools 或 tool_choice 时，官方说会尽力路由到已知支持工具调用的供应商；设置了 max_tokens 时，只会路由到支持该长度响应的供应商。

第二个问题：模型本身不行了怎么办

供应商级的兜底之上还有一层模型级兜底，用 models 参数。官方的说法是按优先级传一个模型 ID 数组，第一个模型报错就自动试下一个。

触发条件官方列得很明确，默认任何错误都可以触发，包括：上下文长度校验错误、被过滤模型的内容审核标记、限流、以及宕机。这四类里「内容审核标记」最值得注意——它意味着一次被拒答的请求也会消耗掉你排在后面的备选模型，而不是直接失败。

计费口径官方也说清楚了：按最终实际使用的那个模型计价，具体是哪个会在响应体的 model 字段里返回。所以做成本核算时不能拿你请求里写的第一个模型名去算，得读响应里的 model。

如果你的项目走的是 Anthropic Messages 接口（/api/v1/messages），官方支持 fallbacks 参数，形状与 Anthropic SDK 一致，但官方补了一句关键说明：这套 fallback 是 OpenRouter 自己实现的路由，不走 Anthropic 的服务端 fallback 功能，触发条件与上面那份列表相同，而不是只在拒答时触发。

第三个问题：账单和用量口径的归一

官方把额度叫 credits，定位是「你在 OpenRouter 上的存款」。用 API 或聊天界面时，从额度里扣掉这次请求的成本。计价维度官方说明得比较细：每个模型按每百万 token 展示单价，prompt 与 completion 通常不同价，另外还有按请求计费的、按图片计费的、按推理 token 计费的模型，这些都在模型页上标出来。具体多少钱看官方定价页，本文不列。

有一条容易被误解的是加价问题。官方说法是对推理定价不加价、透传供应商价格，但购买额度时会收取一笔费用。这两件事是分开的：贵不贵不体现在每次调用上，体现在你充值的那一刻。这条机制怎么构成、怎么自己估，可以看充值手续费是怎么产生的那篇。

查用量有两条路。控制台侧是 Activity 页，官方说可以按模型、供应商、API key 过滤历史用量。程序侧是 GET /api/v1/key，返回体里官方列出的字段包括 limit / limit_reset / limit_remaining（单 key 的消费上限及余量，官方对各字段的 null 语义描述不同，以官方注释为准）、usage 与 usage_daily / usage_weekly / usage_monthly（分别是全时段、当前 UTC 日、当前 UTC 周从周一起算、当前 UTC 月）、BYOK 用量的同名一组字段，以及 is_free_tier（是否从未付费）。注意周和月的口径都是 UTC，跟你本地账期对不齐是正常的，做接口成本监控时要先把时区口径换算过来。

额度限制官方分成两个来源：账户余额，以及单个 API key 上可选的消费上限。二者是独立的，某个 key 用不了不等于账户没钱了。

变体后缀：藏在模型名里的那一层路由

模型 slug 后面挂的冒号后缀，官方称为 variants，分静态和动态两类。静态变体只能用在特定模型上，哪些能用要查模型接口；动态变体所有模型都能用，改变的是请求被路由或被使用的方式。

官方当前列出的有：:free（该模型始终免费提供，限流较低）、:nitro（按吞吐排序供应商）、:floor（按价格排序，优先成本更低的选项）、:exacto（按面向工具调用可靠性调校的质量优先信号排序）。:online 已标注废弃，官方要求改用 openrouter:web_search 这个 server tool。

:nitro 的实现官方拆成两件事：一是把所有符合条件的端点按吞吐排序，效果等同于把 provider.sort 设成 "throughput"；二是把优先服务层（priority service tier）的端点也放进候选池，但官方强调它们不享受特殊待遇，只有在实际吞吐最快时才会被选中。代价是这类端点按优先层的费率结算，所以如果你只想要吞吐排序、不想引入优先层计费，官方建议直接用 provider.sort 而不是 :nitro。

模型名这一层还有两个东西：~openai/gpt-latest 这类 latest 别名，官方说它总是解析到该系列最新的对应模型，好处是不用重新部署就能跟上版本；以及 openrouter/free 这个免费模型路由器，官方描述是从当前可用的免费模型里随机挑一个，并且会按你请求需要的能力（图像理解、工具调用、结构化输出）先做过滤。想按任务自己挑而不是交给随机，可以看免费模型怎么选。

它明确不解决的几件事

多插一层代理不是没有代价，下面这些是官方文档里写清楚、但很容易被想当然搞错的：

多开账号或多建 key 不能绕开限流。 官方原话的意思是容量按全局治理，所以额外的账号和 key 不会改变你的速率限制。官方给的替代思路是：不同模型的限流不同，可以靠分散到不同模型来分担负载。

余额为负会波及免费模型。 官方说明账户余额为负时你可能会看到报错，包括调用免费模型时；把余额补到零以上就能重新使用这些模型。注意官方用的是「可能」，不是「一定」。

隐私设置和路由偏好会互相打架。 官方写明：如果你在请求里指定了供应商路由，但没有任何一个供应商满足你账户设置里指定的隐私级别，你会拿到一个错误，请求不会完成。这类失败看起来像「模型不可用」，实际根因在账户设置里。

HTTP 状态码和 error.code 一致是有条件的。 官方的表述是：只有在「原始请求本身非法」或「API key / 账户额度不足」这两种情况下，HTTP 状态码才与 error.code 相同；其他情况下——尤其是模型已经开始产出之后才出错——HTTP 响应状态是正常的，错误信息走响应体或 SSE 数据事件返回。按状态码写重试逻辑的人在这里最容易漏掉一整类错误。限流这一类的通用处理思路可以参考接口 429 的通用处理。

日志策略是默认不记，但供应商侧有条件。 官方说会记录基本请求元数据（时间戳、用了哪个模型、token 数），prompt 和 completion 默认不记录，即使出错也不记录，除非你主动开启（开启后官方按其说明给予一定用量优惠，具体以官方设置页为准）。供应商侧的规则是：会记录日志的、以及官方无法确认其策略的供应商，默认不会被路由到，除非你在隐私设置里打开模型训练开关。

该拿它当什么用

把这四层机制串起来看，OpenRouter 真正的产品形态其实是「一个 OpenAI 兼容端点 + 一套可配置的路由策略 + 一个统一账本」。它对两类场景收益最大：一是要在多个模型之间反复比较、切换、灰度的项目，改一个字符串就换供应商；二是生产环境需要故障转移的项目，供应商级和模型级两层兜底是它默认就给的。

反过来，如果你长期只用一家的一个模型、并且已经有该家的直连账号，那这一跳带来的主要是充值时的那笔费用和一层排查复杂度——出问题时你得先分清是你的请求错了、是路由把你送到了不该去的地方、还是上游供应商在抖。

下一步建议按这个顺序动手：先用官方 Quickstart 里的 curl 打通一次 /api/v1/chat/completions，确认鉴权没问题；再调一次 GET /api/v1/key 把你这把 key 的 limit_remaining 和用量字段看一遍，把监控口径定下来；最后才去调 provider 对象。顺序反过来的话，你会分不清失败是配置写错了还是压根没接通。真要从其他厂商整体迁过来，可以先过一遍更换模型厂商的迁移清单，把参数差异和计费口径的坑一次性列清楚。