廉价优先的模型路由将常规支持问题发送给一个小型、低成本的模型，并将选定的困难或不确定请求升级到更强的模型。只要更便宜的路径满足你的支持需求，它就能降低对每条消息都使用强能力模型的成本。三种应用侧模式是静态规则、基于分类器的分诊，以及带置信度阈值的答案检查。
本指南比较了这三种模式，展示了流程中哪些部分由 OpenRouter 处理，通过一个可复制的请求走查一个支持流程，并列出了在添加升级之前需要衡量的内容。
Tl;dr
- 对于范围狭窄、可识别的 FAQ，使用静态规则；对于以多变措辞表达的稳定类别，使用基于分类器的分诊；当廉价模型应首先尝试作答时，使用答案检查。
- 将支持策略的验收检查保留在你的应用中。我们的模型回退处理请求错误。一个成功但不正确的答案需要在你的代码中单独做出升级决策。
- 在答案验收率、包含被丢弃尝试的总成本、升级率以及完整轮次延迟上，将廉价优先与仅廉价和仅更强进行对比。
- 只在你的评估显示升级能修复失败的地方添加升级。一次替换掉本已可接受的廉价答案的升级，会增加成本和延迟，却不会改善响应。
当更便宜的模型适合常规 FAQ 时
一个强能力模型能让初始集成保持简单。如果常规 FAQ 在更便宜的模型上满足你的质量要求，那么这部分流量就成为降低模型支出的候选。用同一份已批准的文档测试两个模型，使用来自我们模型目录和当前定价的候选。
分类器调用和第二次尝试也会消耗时间和预算。根据你在生成前能识别什么以及生成后能检查什么来选择模式。
三种路由模式
Anthropic 的关于构建有效智能体的指南将路由描述为对输入进行分类并将其导向专门的后续任务，简单问题发送给较小的模型，困难问题发送给能力更强的模型。下面的构建和维护估算是我们对一个小型支持应用的规划判断。
| 方法 | 决策点 | 构建工作量 | 维护负担 | 有用的起始工作负载 |
|---|---|---|---|---|
| 静态规则 | 在生成前匹配意图或短语 | 低 | 随着措辞和策略变化更新规则 | 狭窄、可识别的 FAQ 类别 |
| 基于分类器的分诊 | 轻量级分类器选择一个模型或工作流 | 中 | 维护标注示例并检查错误路由 | 用多样语言表达的稳定类别 |
| 带置信度阈值的答案检查 | 接受廉价答案或请求另一次尝试 | 中到高 | 维护策略检查并根据正确性验证置信度分数 | 具有明确、可测试要求的答案 |
这些模式可以共存。规则或分类决定请求从哪里开始。答案检查决定其输出是否可接受。模型自我报告的置信度在你根据自己的问题对照正确性进行检查之前，并不是正确性的概率，因此在获得这些数据之前，请将其视为一种排序信号。
你的应用拥有什么，OpenRouter 处理什么
拥有基于质量的路由意味着维护规则或分类器、验收检查、升级决策和监控。这些可以存在于你的支持应用内，而无需单独的路由服务。
如果你希望我们选择初始模型，我们的Auto Router，通过"model": "openrouter/auto"选择，会按任务类型对每个提示进行分类，并从 OpenRouter 用户在该任务类型上花费的模型中选择一个。一个有序的模型回退列表，作为models数组发送，在出现错误（如速率限制、提供商宕机或内容审核拒绝）后，会在下一个模型上重试请求。支持策略验收检查仍由你负责。
如果你希望我们选择初始模型，请选择 Auto Router。如果你知道自己偏好的模型并需要错误恢复，请选择有序回退列表。对于廉价优先的质量升级，你的应用检查候选答案，并在检查失败时请求另一个答案。
以下流程展示了这种责任划分。
OpenRouter 上的一个完整支持流程示例
第 1 步：在选择模型之前定义结果
HarborDesk 是一个虚构的 SaaS 产品，带有固定的 FAQ。它的机器人可以解释政策并推荐支持渠道，但无法查看账户或进行更改。可接受的回复应回答问题、请求澄清，或推荐人工支持。
对于你能可靠识别且答案固定的意图，使用已批准的模板。单独测试意图选择，确保正确的措辞对应到正确的问题。需要解读的请求进入下方的生成答案路径。
第 2 步：在升级前检查生成的答案
对于需要生成的请求，廉价模型提供第一个候选答案和分诊信号。你的应用负责做出接受决定。
设想一位客户询问如何取消订阅并申请退款。在 HarborDesk 的政策中，所有者需在 Settings > Billing 下取消，账单人员审核退款请求。
- 接受一个解释了两个步骤但没有承诺退款的廉价答案。
- 拒绝一个把所有事情都转给账单部门、却遗漏了所有者取消操作的答案。如果有已批准的模板能覆盖该请求，就使用它；或者如果你的评估显示更强的模型能修复这一遗漏，就请求更强模型再试一次。
- 如果客户要求机器人批准退款，推荐账单支持。更强的模型也无法提供这种权限。
检查政策内容和预期操作。仅凭有效的 JSON 并不能确立正确性。保留对话上下文，对更强的答案运行相同的检查，并在一次升级后停止。
第 3 步：配置错误回退并记录请求成本
这段代码发送一个带有有序回退列表的请求。安装requests并设置OPENROUTER_API_KEY后再运行它。简短的虚构 FAQ 为示例提供了上下文。
importos
importrequests
messages=[
{
"role":"system"，
"content"：(
"仅根据这个虚构的 HarborDesk FAQ 回答。"
"所有者可以在 Settings > Billing 下取消。"
"账单支持审核退款请求。"
"你无法查看账户、取消套餐或批准退款。"
"必要时请求澄清。"
),
},
{"role":"user"，"content"："我如何取消订阅并申请退款？"},
]
response=requests.post(
"https://openrouter.ai/api/v1/chat/completions"，
headers={"Authorization"："Bearer "+os.environ["OPENROUTER_API_KEY"]}
json={
"models"：["openai/gpt-4.1-mini"，"openai/gpt-4.1"]，
"messages"：messages，
"max_tokens"：512，
"stream"：False，
}，
timeout=60，
)
response.raise_for_status()
data=response.json()
if"error"indata:
raiseRuntimeError(f"Completion failed:{data['error']}")
choices=data.get("choices"，[])
ifnotchoices:
raiseRuntimeError("Completion returned no choices")
choice=choices[0]
ifchoice.get("error")isnotNoneorchoice.get("finish_reason")=="error"：
raiseRuntimeError(f"Completion failed:{choice.get('error'，'unknown error')}")
print({
"id"：data["id"]，
"model"：data["model"]，
"answer"：choice["message"]["content"]，
"cost"：data.get("usage"，{}).get("cost"),
})该数组会在出现符合条件的错误（例如速率限制或提供商宕机）后尝试下一个模型。成功但错误的答案不会触发它。质量升级需要应用层检查并单独发起一次更强模型的请求。models存在这两处错误检查，是因为当模型已开始处理请求并在生成输出时失败，我们仍可能返回 HTTP 200。该
对象出现在响应体的顶层，或者当存在部分内容时，出现在error内部，choices[0]其finish_reason被设置为error。错误与调试参考文档描述了这两种形态。应将两者都视为失败，而不是把部分输出当作答案打印出来。
该代码片段会打印一个未经校验的候选结果以供检查。usage.cost字段是我们就该请求收取的额度（credits）金额，而model是生成响应的模型，这在触发回退时很重要。每次请求都要记录这两者。当你的应用进行升级时，要把两次调用都计入，包括被丢弃的廉价草稿。如果响应到达时没有cost值，就把成本记为未知，而不是记为零，直到你对照你的活动页面进行核对。用量核算cookbook 描述了该usage对象。
衡量升级率和每个已解决工单的成本
对于总是先尝试廉价模型的流水线，用这个公式计算每次请求的预期模型成本。
expected_cost = cost_cheap + cost_check_1
+ escalation_fraction * (cost_strong + cost_check_2)在检查项中计入任何评估器或分类器调用的成本，并对升级请求使用更强模型的成本。在相同的质量目标和延迟限制下，将结果与仅用廉价模型和仅用更强模型（包括它们的检查项）进行比较。
为每个路由策略跟踪这些指标。
- 升级率。尝试了更强模型处理的请求占比。
- 被接受的错误答案。通过了你的检查但未通过人工审核的廉价答案。
- 被升级的正确回答。已经满足你的标准但仍被升级的廉价答案。每一个都会增加一次更强模型的费用和第二次调用的延迟，却没有改善响应。
- 转人工的适当性。当请求需要机器人不具备的权限时，机器人是否建议了人工支持。
- 完整轮次延迟。从客户消息到返回答案的时间，包括升级请求中的两个模型阶段。
高升级率值得检查被路由的问题。它本身并不能证明阈值有误。
对于每个已解决工单的成本，将某个工单队列的所有模型支出（包括未解决的工单）除以在规定的重开工单窗口内满足既定解决定义的工单数量。测试集上的答案接受度衡量的是响应质量，而非客户解决情况，因此请将这两个指标分开。
在生产环境启用升级之前，在留出的支持问题上运行此比较。包括简单的 FAQ、模糊的请求、故障排查以及需要人工转接的请求，并根据预定义的内容标准和预期操作对每个答案进行评分。只有当升级能以你接受的成本和延迟将失败的答案转化为通过的答案时，它才值得采用。
结论
从已批准的模板和针对狭窄 FAQ 的廉价模型基线开始。根据你的工作负载选择规则、分类或答案检查，然后仅在相同的质量目标和延迟限制下与更强模型进行比较。仅当升级能修复足够多的失败以证明成本和延迟合理时才添加升级。当支持政策变化时，重新审视你的检查项。
常见问题
我可以避免构建自定义路由服务吗？
你可以把路由保留在支持应用内部。如果你希望由我们选择初始模型，可以使用 Auto Router，并使用modelsfallback 数组，这样在请求出错后我们会重试另一个模型。特定于支持的验收检查，例如回答是否符合你的取消政策，仍然属于你的应用。把模型 ID 放在配置中，并让你的提示词和评估数据保持可移植，以便日后更换模型。
廉价模型能否在生成过程中咨询更强的模型？
不能通过本指南中的流程实现。廉价模型先完成一个候选答案，然后由你的应用决定是否请求更强模型的答案。要在同一轮对话中咨询另一个模型，需要在你的代码中有一个显式的工具或编排步骤，调用更强的模型并将其输出返回到正在进行的工作流中。modelsfallback 数组不会创建这种机制。它只会在出错后于另一个模型上重试请求。
FAQ 分流模型应该选哪个？
从在留出的支持问题上（包括模糊请求和政策例外）能达到你质量目标的最便宜候选模型开始。衡量完整一轮的延迟，而不是单次调用的延迟，因为最快的模型调用如果经常需要第二次尝试，仍可能产生更慢的支持响应。先从一小组反复出现的问题开始，随着评估显示哪些路由有效再逐步扩展。