OpenRouter 会先找到能提供所选模型、并满足当前请求的 Provider，再对合格 endpoint 排序。 普通请求默认会在头部 Provider 之间负载均衡以提高 uptime，并以价格作为主要权重；包含 tools 的请求则默认启用 Auto Exacto，根据工具调用可靠性和实时性能重新排列 Provider。
如果首选 Provider 无法提供服务，只要允许 fallback，OpenRouter 就可以为同一个模型尝试其他 Provider。这和 model fallback 不同，后者会把模型本身也换掉。
最简洁且准确的路由顺序是：
- 选择或解析模型。
- 排除不符合模型、参数、数据政策或用户限制的 Provider。
- 用默认规则、显式偏好，或针对 tools 的 Auto Exacto 排列合格 Provider。
- 尝试一个允许的 Provider。
- 失败时执行已配置的 Provider 或 model fallback。
这是一条模型服务链，不是完整 Agent 循环。想理解外围层级，可以先看模型、Provider 与 Agent harness 的区别。
最后核验：2026-08-27。 默认 Provider 排序、Auto Exacto 信号、路由字段和 Fallback 行为都可能变化。部署固定策略前，应重新核对 OpenRouter 当前路由文档。
Model 与 Provider 是两个不同选择
Model 是应用请求的能力和 API 身份；Provider 是实际承载该模型推理的 endpoint 运营方。OpenRouter 可以为同一个模型提供多个 Provider endpoint。
这个区别很重要，因为服务同一模型的 endpoint 仍可能在这些方面不同：
- 当前价格；
- Latency 与 Throughput；
- Uptime 与 Rate Limit；
- Quantization 或 Service Tier；
- 支持的请求参数；
- 数据收集与保留政策；
- 地理可用性。
因此，选择模型不一定同时固定 endpoint。它只定义模型层合同，Provider routing 决定这个合同在哪里被执行。
测量时也应把模型选择和 Provider 选择分开。如果任务突然变慢、变贵或不稳定，原因可能是模型变化、Provider 变化、工具变化，或者 Agent harness 本身变化。
OpenRouter 默认如何选择 Provider？
OpenRouter 的 Provider Selection 文档说明，默认会在头部 Provider 之间负载均衡，以提高 uptime。Auto Exacto 文档进一步说明，没有使用 Auto Exacto 的普通 routing 主要以价格加权，明显偏向低成本 Provider。
所以，“OpenRouter 永远选择最便宜 Provider”并不准确。默认 routing 会在合格 endpoint 中同时考虑可用性和价格。Provider 首先需要能够提供所选模型，并满足请求限制。
如果请求有这些要求，合格 Provider 范围就会改变：
- 并非所有 Provider 都支持的参数；
- 特定数据政策或 Zero Data Retention endpoint；
- Provider allowlist 或 blocklist；
- 最高价格；
- Quantization level；
- 特定地区或 Service Tier。
应用约束后，全目录中最低价的 endpoint 可能不再合格。这是预期行为，不一定是路由错误。
Provider fallback 与 model fallback
“Fallback”这个词对应两套不同机制。
Provider fallback 保持模型不变
OpenRouter provider 对象里的 allow_fallbacks 默认值为 true。首选 Provider 不可用时，可以为同一个模型尝试备选 Provider。
这会提高可用性，但替代 endpoint 的性能、数据政策或价格特征可能不同。如果固定 Provider 是工作负载合同的一部分，不受限制的 fallback 可能破坏这个要求。
Model fallback 会更换模型
OpenRouter 的 Model Fallbacks 文档介绍了 models 列表：主路线失败时，可以尝试另一个模型。文档列出的触发条件包括 Rate Limit、Downtime、Moderation Refusal 和 Context Length Validation Error。
更换模型带来的变化远不止 endpoint。Tokenizer、上下文、工具行为、输出风格、价格和任务质量都可能变化。因此，model fallback 应该被视为需要单独验收的应用级策略。
如果可复现性比可用性更重要，可以缩小 Provider 范围、关闭 fallback，或者失败时停止并要求审核。但这种取舍必须明确：越严格的 routing 越可能让请求更早失败。
为什么 Tool Calling 会改变 Provider 排序？
OpenRouter 表示，Auto Exacto 默认运行在每个包含 tools 的请求上。它会根据三类信号为所选模型重新排列 Provider：
- 实时 Throughput；
- Tool Calling Success Rate；
- OpenRouter Provider Benchmark Harness 的结果。
工具调用成功信号来自模型 Performance 页面里的 Tool Call Error Rate。OpenRouter 会根据调用方提供的 schema 校验返回的工具参数，并把观察到的错误作为 routing 输入之一。
Auto Exacto 会降低表现较差 endpoint 的优先级，把信号更好的 Provider 移到前面。但它不能保证每个工具调用都正确。一个 JSON 结构完全合法的调用，仍然可能选错工具、填入语义错误的值，或者执行错误计划。
这些 Benchmark 和流量信号也是 OpenRouter 自己的 routing 输入，不是对每个仓库都适用的通用模型或 Provider 排名。可以用它们理解平台排序，但完整任务仍需在自己的环境验收。
Tool Calling 不代表 Provider 会替你执行工具
Tool Calling 指南清楚定义了标准循环：模型提出 Tool Call，调用方执行工具，再把结果返回模型。
OpenRouter 负责统一模型接口和路由推理请求。真正的读文件、Shell 命令、数据库查询、API 请求、审批步骤和结果验证，仍由应用或 Agent harness 负责。
这个边界对排错很重要。无效参数可能指向模型或 Provider 行为；命令在错误目录执行属于 Harness 或工具环境问题；单元测试失败可能是代码修改错误，而不是 routing 故障。
Auto Exacto 可以改变工具请求优先尝试哪个 Provider，却不会把模型路由层变成完整 Coding Agent。
如何控制 OpenRouter Provider Selection？
provider 对象为不同运行目标提供控制项。不要默认把所有字段都加上，应先明确真正重要的要求。
强制支持请求参数
当 endpoint 必须支持请求里的全部参数时，可以设置 require_parameters: true。工作流依赖 Tools、Structured Output、推理控制或其他并非所有 Provider 都支持的参数时，这尤其有用。
如果没有强制要求，某个 endpoint 即使不支持所有可选参数，仍可能被视为合格。这对简单 Chat 可能可以接受，对严格 Agent 合同则风险更高。
指定、允许或排除 Provider
order按希望尝试的顺序提供 Provider slugs。only把请求限制在 allowlist 内。ignore排除指定 Provider。allow_fallbacks: false禁止使用备选 Provider。
这些控制能提高可预测性，却会缩小在 Downtime 或 Rate Limit 时的候选池。列表应该只严格到满足真实政策所需的程度。
按价格或性能排序
OpenRouter 支持按价格、Throughput 和 Latency 排序或设置偏好。性能偏好不一定保证达到阈值；文档明确区分了 preference 与 max_price 这种可能直接阻止请求执行的硬限制。
需要明确价格优先时，OpenRouter 还提供 :floor 快捷方式。官方说明，:floor 不只等于按价格排序，还会允许 Flex Service Tier endpoint，因此范围比简单 provider.sort: price 更广。
对于 Tool Calling 请求，显式按价格排序或使用 :floor 会退出 Auto Exacto，恢复价格加权顺序。这可能降低 endpoint 价格，但也会移除 Auto Exacto 针对 tools 的质量信号排序。
强制数据政策
Provider 对象可以限制数据收集，并要求 Zero Data Retention endpoint。这些是政策过滤条件，不是宣传标签。应该核对设置是否符合组织的实际数据要求，并预期合格 Provider 数量会减少。
一个用于说明的请求策略可能是：
这个例子不是所有工作负载的正确答案，只是在说明：能力、Fallback 和数据保留要求应进入 routing 配置，而不是停留在口头假设里。
Coding Agent 的路由验证清单
在生产工作负载中大范围修改 Provider policy 前，先使用一个可复现任务：
- 固定模型 ID 和 Agent harness 配置。
- 定义必要参数、Tool schema、数据政策与允许地区。
- 决定 Provider fallback 是否允许改变价格或政策特征。
- 单独决定是否允许 model fallback。
- 记录 Request ID、返回模型、可用时的 Provider 信息、usage、latency 与错误。
- 统计无效工具调用、重试、测试失败和合格结果。
- 只在相同任务条件下比较价格优先、性能优先和默认 routing。
- 保留满足工作负载要求的最宽松策略。
如果成本是第一约束，可以先比较 OpenRouter 编程模型的价格与工具能力。如果正在考虑自动选模，则先分清 Auto Router 与 Free Models Router。这些选择发生在 Provider routing 之前或与其同时发生，不能互相替代。
常见问题
OpenRouter 永远选择最便宜的 Provider 吗？
不会。普通默认 routing 主要按价格加权，但也会在头部合格 Provider 之间负载均衡以提高 uptime。限制条件可能排除低价 endpoint；Tools 请求默认还会使用 Auto Exacto，除非显式要求价格优先。
OpenRouter Provider 失败时会发生什么？
允许 Provider fallback 时，OpenRouter 可以为同一模型尝试其他合格 Provider。如果应用还提供 model fallback，符合条件的错误可能进一步触发换模型。
Tool Calling 会改变 OpenRouter routing 吗？
会。OpenRouter 表示，Auto Exacto 默认运行在包含 tools 的请求上，并使用 Throughput、工具调用可靠性和其 Benchmark Harness 信号重新排序 Provider。
Auto Exacto 会执行工具吗？
不会。在标准 Tool Calling 循环里，模型提出调用，调用方执行。Auto Exacto 只改变推理请求的 Provider 顺序。
可以强制 OpenRouter 使用某个 Provider 吗？
Provider 对象支持 order、only 与 ignore，也可以关闭 fallback。控制越严格，Provider 不可用时失败的概率越高。
结论
OpenRouter Provider routing 是一串资格筛选、排序和 Fallback 决策。普通请求在强调 uptime 的同时明显偏向价格；Tools 请求会加入 Auto Exacto 的可靠性与性能信号。当参数、数据政策、成本、速度或 Provider 身份更重要时，可以用显式 routing 字段收紧行为。
下一步不应该是一次性配置全部选项。先选一个 Coding 任务，写清硬约束，记录实际路线与工具错误，再用相同验收标准比较少量策略。把 Model、Provider 和 Agent harness 分开记录，结果才可解释。