OmniRoute Reasoning Routing 深度解析：基于推理强度（Effort/Budget）的智能模型与路由策略

OmniRoute Reasoning Routing 深度解析基于推理强度Effort/Budget的智能模型与路由策略【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRouteReasoning Routing推理路由是 OmniRoute 在模型路由与 Combo 路由之上扩展的一层策略引擎它可以在请求真正发往上游之前根据客户端携带的推理强度信号effort、thinking budget把请求改写、降级、重定向到不同的模型或 Combo并同步调整 thinking budget。读完本文你将理解它的管理入口与 REST API 全貌、规则字段与取值约束、恰好命中一条规则的决议算法、请求推理意图的提取方式、安全边界与持久化/同步机制并能结合 策略源码 与 校验 Schema 自行排障和验证。功能定位默认行为零破坏的扩展层推理路由规则Reasoning routing rules扩展了已有的模型路由model routing与 Combo 路由combo routing。官方文档明确承诺一条向后兼容原则当没有任何激活的规则匹配当前请求时现有的 thinking、suffix、connection-default 以及 provider 翻译provider-translation行为完全保持不变参见 路由文档。换言之这是一个纯增量的策略层不配置规则系统行为与之前完全一致。规则能做的事把某个模型/Combo 的请求重定向到另一个目标模型或目标 CombotargetKind为model或combo改写推理强度effortModetargetEffort或移除/设置 thinking budgetbudgetAction对特定 API 密钥、特定 Combo、特定模型模式、特定标签组合的请求施加差异化策略。管理入口与 REST API规则管理在Settings → Global Routing页面提供API 密钥编辑器API-key editor提供同一套管理界面只是过滤为当前选中的密钥所关联的规则。前端组件见 ReasoningRoutingRules.tsx。管理 API 由以下三条路由暴露均为管理面接口鉴权要求见下文安全边界方法路径说明实现文件GET/POST/api/settings/reasoning-routing-rules列出全部规则 / 创建规则route.tsGET/PATCH/DELETE/api/settings/reasoning-routing-rules/[id]查询 / 更新 / 删除单条规则route.tsPOST/api/settings/reasoning-routing-rules/simulate干跑模拟不产生上游调用route.ts三条路由统一使用requireManagementAuth鉴权。请求体由 reasoningRouting.ts 中的 Zod Schema 校验创建入口 走validatedJsonBody校验失败即直接返回 4xx模拟器simulate永远不会发起真实的 upstream 调用——它只做本地规则匹配、能力检查与权限预检。值得注意的实现细节[id]路由的PATCH采用合并后再整体校验策略——先把补丁字段合并到既有规则再按创建 Schema 完整重校验一次见 route.ts 中mergedsafeParse的逻辑从而保证任何局部更新都不会产生一条非法规则。规则模型完整字段与约束以下字段表完整继承自 校验 Schema并标注了默认值与取值上限可直接作为 API 调用的参数参考字段类型默认值约束与含义namestring必填1–200 字符descriptionstring最多 1000 字符scopeenum必填global/apiKey/combo/model/connectionapiKeyIdstring | null—scopeapiKey时必填comboIdstring | null—scopecombo时必填源 ComboconnectionIdstring | null—scopeconnection时必填modelPatternstring | null—1–500 字符支持*/?globscopemodel时必填sourceEffortenumanyany/missing/none/low/medium/high/xhigh/max/ultrarequestTagsstring[][]最多 20 个标签每个 1–100 字符tagMatchModeenumanyany任一命中或all全部命中effortModeenuminheritinherit/default/force非inherit时targetEffort必填targetEffortenum | null—none/low/medium/high/xhigh/max/ultratargetKindenumkeepkeep不改模型/model/combotargetModelstring | null—targetKindmodel时必填1–500 字符targetComboIdstring | null—targetKindcombo时必填budgetActionenumpreservepreserve/remove/setset时budgetTokens必填budgetTokensint | null—正整数最大 10,000,000priorityint0范围 -1,000,000 到 1,000,000enabledbooleantrue停用后不参与匹配Schema 层还有一系列跨字段业务约束superRefine实现数据库层在 迁移 SQL 中用CHECK约束二次兜底scopeconnection的规则强制targetKindkeep即连接级规则不能重定向模型只能改 effort 与 budget错误消息为 Connection rules cannot reroute modelseffortMode非inherit时必须提供targetEffortbudgetActionset必须提供budgetTokenstargetEffortnone与budgetActionset组合非法A none effort cannot set a thinking budgetSQL 侧对应CHECK (NOT (target_effort none AND budget_action set))。规则决议如何恰好选中一条引擎采用早期评估early evaluation一次请求至多命中一条早期规则。源码 policy.ts 中的SCOPE_RANK定义了作用域权重apiKey(4) combo(3) model(2) global(1) connection(0)。resolveReasoningRoutingRule先把所有启用且匹配的规则过滤出来再按compareRules排序取第一名。排序规则与文档一致作用域权重高者优先apiKeycombomodelglobal同作用域内priority数值大者胜再同分时模型精确匹配优先于 glob 模式匹配isExactModelMatch检查模式不含*?且大小写不敏感相等;最后按createdAt、id的稳定字典序决胜保证决议结果可复现。两个关键匹配细节sourceEffort是作用域匹配的一部分scopeMatches要求rule.sourceEffort any或严格等于请求提取出的sourceEffort。requestTags仅从请求的metadata.tags读取any/all两种匹配模式分别对应任一标签命中与全部标签命中标签会先经normalizeRoutingTags归一化见 tagRouter。connection规则走晚期评估只有当没有任何早期规则胜出、且上游已选出具体 provider 连接时才会评估此时引擎会以connectionOnly模式重新筛选只保留connection作用域规则。它最多改变 effort 与 budget不能换模型/Combo。glob 匹配由 policy.ts 中的globMatches实现先转义正则元字符再把*映射为.*、?映射为.,以大小写不敏感的完整匹配正则判定。请求推理意图提取missing与signal的语义规则匹配依赖引擎从原始请求体中提取的推理意图这是理解sourceEffort语义的前提。extractReasoningIntent的判定结果有三类提取到了离散 effort → 对应档位none…ultra没有任何离散 effort但存在其他推理信号thinking 开关、thinking level、任意预算字段→signalmissing请求既不含离散 effort也不含 thinking 开关也不含 thinking budget。因此只带 budget 不带 effort的请求其sourceEffort是signal只能被sourceEffortany的规则匹配——这正是文档强调的语义。离散 effort 的探测按优先级依次检查请求体中的多个字段firstDefinedEffortreasoning.effort、reasoning_effort、reasoningEffort、effort、output_config.effort、thinkingLevel/thinking_level含generationConfig.thinkingConfig内嵌形式、thinkingfalse或thinking.typedisabled判为none最后是模型名后缀中的 effort。模型名后缀解析支持两类Claude 系模型经splitClaudeEffortSuffix处理Codex 系模型经splitCodexEffortSuffix处理识别-low/-medium/-high/-xhigh/-max/-ultra/-none后缀且对max/ultra有模型白名单例如ultra仅匹配gpt-5.6-sol/terra基名max扩展到gpt-5.6-luna。thinking budget 的探测detectThinkingBudget则覆盖thinking.budget_tokens、reasoning.budget_tokens/max_tokens、顶层thinking_budget/thinkingBudget、generationConfig.thinkingConfig.thinking_budget等十余种字段位置任一为数值即认为带预算信号。Effort 三种模式与 Budget 三种动作effortMode的三种变体及其源码行为resolveTargetEffortapplyReasoningRuleDirectiveinherit保留客户端 effort同时允许改变模型/Combo。请求未携带离散 effortmissing或signal时最终targetEffort为null即不动。default仅在请求没有显式推理信号时把targetEffort设为规则值客户端已显式表达 effort 时保持继承。force用targetEffort覆盖离散 effort。applyReasoningRuleDirective会先clearDiscreteReasoning清掉reasoning_effort、effort、thinkingLevel、output_config.effort等旧字段再统一写入reasoning_effort、reasoning.effort、output_config.effort。特例forcetargetEffortnone会调用clearReasoning删除请求体中所有被识别的 effort 与 budget 字段含thinking、thinking_budget、output_config.effort等即彻底关思考。budgetAction独立于 effort 生效三种取值preserve保留客户端原有预算removeremoveBudgets清除thinking_budget、thinkingBudget、thinking.budget_tokens/budgetTokens、reasoning.budget_tokens/budgetTokens/max_tokens、generationConfig.thinkingConfig等位置set先清除再写入标准形式thinking { type: enabled, budget_tokens: budgetTokens }。注意一个引擎级覆盖当最终targetEffort为none时budgetAction会被强制改写为removeresolveReasoningRoutingRule中targetEffort none ? remove : rule.budgetAction保证无推理与保留预算不矛盾。兼容性校验Combo 过滤与 400 拒绝规则目标可能携带客户端并不支持的推理档位引擎在上游调用前就做能力校验capabilityFor基于 modelCapabilities 的supportsThinking单一模型目标已知不支持目标 effort 的模型 → 请求直接被拒不再发往上游。对max/ultra档位还有 Codex 基名白名单校验能力数据未知supportsThinking为 null时判为unknown只产生告警 Reasoning capability could not be verified规则保持激活。Combo 目标filterComboForReasoningDecision从 Combo 的models列表中剔除不兼容条目并返回removed名单部分剔除时告警 N incompatible combo target(s) will be skipped若剔除后一个模型都不剩请求返回400。安全边界与传输通道权限零扩张源模型/源 Combo 与目标模型/目标 Combo 都继续受既有 API-key 策略约束。一条推理路由规则永远不会扩大某个密钥对模型、Combo 或 quota 的既有权限模拟接口内部也会用validateApiKeyRoutingTarget对目标做权限预检并在errors中返回可读消息。传输通道策略引擎集成在 Chat Completions、Responses、Anthropic Messages 以及内部 Codex WebSocket 四条路径中Chat 路径的接入点见 chat.ts 中的applyReasoningRouting调用与 reasoningRouting.ts 处理器。Codex WebSocket 限制该通道只接受 Codex 目标模型isCodexTarget判定无/前缀或codex/、cx/前缀validateCodexWsDecision会拒绝携带非 Codex 模型的目标且Combo 目标无法在该通道执行报错 Codex WebSocket transport cannot execute combo targets。可观测性每条命中会在请求体上挂_omnirouteReasoningRouteTraceattachReasoningRuleDirective记录ruleId、ruleName、scope、源/目标模型、源/目标 effort、effortMode、budgetAction、能力判定与告警——不含任何密钥材料随既有 route trace 落盘便于事后审计为什么这个请求被改写了。持久化、清理与同步持久化由迁移 126_reasoning_routing_rules.sql 建立要点表reasoning_routing_rules的所有枚举字段均有CHECK约束与 Zod Schema 形成双层校验api_key_id、combo_id、connection_id、target_combo_id均为外键引用ON DELETE CASCADE且因 OmniRoute 不依赖进程级PRAGMA foreign_keys设置迁移额外建了AFTER DELETE触发器保证删除 API 密钥 / Combo / provider 连接时级联清理关联规则建了idx_reasoning_rules_enabled(enabled, scope, priority DESC)等索引匹配路径按启用 作用域 优先级快速收敛。数据访问层 reasoningRoutingRules.ts 为请求路径维护一个可失效的缓存invalidatable cache写操作会使缓存失效读热路径避免重复查库。在备份与多端同步方面规则表被纳入 SQLite 备份、数据库全量导出exportAll与 config-sync 数据包bundle。导入侧由reconcileReasoningRulesForSync兜底引用了不存在的密钥/Combo/连接的导入规则会被自动禁用并上报冲突而不是静默生效或破坏引用完整性。用 Simulate 接口做无副作用排障POST /api/settings/reasoning-routing-rules/simulate是排障利器其请求体由simulateReasoningRoutingSchema定义model必填、effortany/missing/各档位或特殊值signal默认missing、thinkingBudgetTokens、apiKeyId、requestTags、transporthttp或codex-ws。模拟流程见 simulate/route.ts先按传输方式解析源模型HTTP 走getModelInfoCodex WS 走resolveCodexWsModelInfo做别名归一然后执行与真实请求完全相同的resolveReasoningRoutingRule决议最后叠加能力检查、传输校验Codex WS 目标约束与 API-key 权限预检返回{ matched: true, decision: { ...rule、sourceModel、targetModel、targetEffort、capability、warnings... }, errors: [] }errors会聚合三类消息目标不支持该 effort、传输通道拒绝如 Codex WS 上出现 Combo 目标、密钥无权访问目标。由于模拟不发起任何上游调用你可以在 Settings → Global Routing 中安全地反复试错规则组合。小结Reasoning Routing 用作用域优先级 priority 精确匹配的确定性决议算法把按推理强度分流变成了一个可管理、可模拟、可审计的路由维度规则以数据库表持久化并随备份/同步流动能力校验保证不会把请求发给不支持的模型API-key 策略保证规则不越权_omnirouteReasoningRouteTrace保证每一次改写都有据可查。对于需要高端问题走高配思考模型、简单问答强制关思考省 token这类场景这套机制提供了模型路由之上的最后一块拼图。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考