OmniRoute Context Relay 上下文中继账户轮换下的会话连续性保障策略【免费下载链接】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导读context-relay是 OmniRoute 提供的一种 Combo组合路由策略用于解决长会话期间活跃账户因配额耗尽而轮换时的上下文断裂问题。它会在账户即将耗尽前于后台生成一份紧凑的结构化交接摘要当后续请求被路由到同一会话的另一个账户时将该摘要以系统消息的形式注入让新账户无缝延续既有任务。读完本文你将理解其运行时流程、交接载荷结构、配置字段与默认值以及它在 OmniRoute 中“生成侧combo 层与注入侧chat 层分离”的架构设计并能据此为自己的多账户 Combo 配置这一连续性保障能力。什么是 Context Relay优先级路由之上的交接层在 OmniRoute 的 Combo 体系中context-relay被定位为一种在模型选择上表现为优先级路由、并额外叠加一层“交接handoff”能力的策略。核心工作方式分为三步在活跃账户配额耗尽之前OmniRoute 在后台生成一份紧凑的结构化摘要handoff summary当身份认证为同一会话选择了不同的账户后OmniRoute 把该摘要作为一条系统消息注入下一次请求交接被成功消费后从存储中移除避免重复注入。与其它策略不同context-relay关注的核心指标不是“选哪个模型”而是“同一会话是否换了账户”。正如 ARCHITECTURE.md 第 296 行所记录的上下文交接是专门为账户轮换场景设计的会话连续性机制FEATURES.md 将其列为 v3.5.5 引入的策略目前主要支持 Codex 账户轮换。适用场景什么时候该启用 context-relay官方文档明确给出启用context-relay的三个前提条件需要同时满足Combo 预期会在同一服务商的多个账户之间轮换——如果没有轮换交接就没有意义丢失短期会话连续性会损害任务质量——即新账户失去前文上下文会导致产出明显变差服务商暴露了足够的配额信息以便系统能预测即将到来的账户限制。从源码实现看第三个条件在 Codex 路径上是硬性依赖executeTargetAttempt.ts 只有在strategy context-relay、handoffProviders包含provider且provider codex时才会调用fetchCodexQuota(connectionId)拉取配额信息并用quotaInfo.percentUsed参与阈值判断。因此这类场景最适合可能超出单个账户窗口的长时间编程或研究会话。运行时流程分阶段的关键行为context-relay的行为依据配额用量百分比被有意划分为几个阶段文档与实现完全对应。配额用量 0%84%正常优先级路由未达到警告阈值时不生成任何交接请求行为与普通优先级路由完全一致。对应代码中maybeGenerateHandoff的早退分支if (options.percentUsed relayConfig.handoffThreshold) return;。配额用量 85%94%后台生成交接摘要当活跃服务商在handoffProviders白名单中启用时OmniRoute 会在账户完全耗尽前在后台生成结构化的交接摘要。关键细节如下默认警告阈值0.85源码中的HANDOFF_WARNING_THRESHOLD 0.85contextHandoff.ts生成的硬停止线0.95即HANDOFF_EXHAUSTION_THRESHOLD 0.95一旦配额用量达到或超过该值不再调度新的摘要请求同上第 13 行每个sessionId comboName只允许一个进行中的交接生成实现上通过内存中的inflightHandoffGenerations集合Setstring以sessionId::comboName作为去重键防止并发重复发起摘要请求contextHandoff.ts已有活跃交接则不重复生成生成前会先调用hasActiveHandoff(sessionId, comboName)检查数据库中是否已存在未过期的交接记录。生成过程通过setImmediate异步调度不阻塞主请求链路contextHandoff.ts。摘要生成时的请求体包含_omnirouteSkipContextRelay: true与_omnirouteInternalRequest: context-handoff标记用于防止内部摘要请求再次触发交接逻辑。配额用量 95% 及以上不再生成新交接此时系统已处于或接近耗尽状态运行时会避免再调度一次额外的摘要请求——因为此时再生成摘要已来不及在耗尽前完成属于纯浪费。账户轮换后注入交接当同一会话的下一次请求被解析到不同的已认证账户时OmniRoute 将存储的交接作为系统消息前置注入到请求体最前面。注入只在实际账户切换被确认后发生在 chat.ts 中注入条件为comboStrategy context-relay、会话 ID 与 combo 名存在、请求未携带_omnirouteSkipContextRelay且getHandoff(...)返回的fromAccount与当前解析出的credentials.connectionId不一致时才注入。注入成功后injectedHandoff非空在响应返回路径中会调用deleteHandoff(runtimeOptions.sessionId, comboName)删除该交接chat.ts实现“消费即移除”。交接载荷context_handoffs 表与 JSON 结构持久化的交接载荷存储在 SQLite 的context_handoffs表中其HandoffPayload类型contextHandoffs.ts包含字段说明sessionId会话标识交接的作用域之一comboNameCombo 名称交接的作用域之二fromAccount生成摘要的源账户connectionIdsummary紧凑摘要正文keyDecisions关键决策列表JSON 数组taskProgress已完成项、待完成项与下一步activeEntities活跃实体列表如文件、功能、服务商messageCount参与摘要的原始消息条数model生成摘要所用的模型warningThresholdPct触发生成时的警告阈值默认 0.85generatedAt生成时间ISO 字符串expiresAt过期时间ISO 字符串upsertHandoff使用INSERT ... ON CONFLICT(session_id, combo_name) DO UPDATE的 SQL 语义保证同一sessionId comboName始终只有一条记录contextHandoffs.tsgetHandoff查询时会带expires_at now条件过期记录自动失效另有按CLEANUP_THROTTLE_MS30 分钟节流的cleanupExpiredHandoffs清理任务。摘要模型返回的 JSON 结构摘要模型被要求返回如下结构的 JSON 对象{ summary: 对连续性重要内容的紧凑摘要, keyDecisions: [决策 1, 决策 2], taskProgress: 已完成项、待完成项以及下一步, activeEntities: [fileA.ts, 功能 X, 服务商 Y] }生成侧使用固定的HANDOFF_PROMPT_TEMPLATE提示词contextHandoff.ts要求模型“仅返回 JSON 对象不带 markdown、不带解释”。解析时parseHandoffJSON会先剥离代码围栏与omniModel标签再尝试整体 JSON.parse失败时回退为截取首尾花括号之间的内容同时对字段做上限约束——summary最长 2000 字符、taskProgress最长 1200 字符、keyDecisions最多 8 项、activeEntities最多 10 项、每项最长 240 字符contextHandoff.ts从源头控制交接体积。注入为context_handoff系统消息注入时buildHandoffSystemMessage将载荷转换为结构化的 XML 风格系统消息contextHandoff.tscontext_handoff transfer_reasonAccount quota transfer - continuing from previous session/transfer_reason session_summary.../session_summary task_progress.../task_progress key_decisions - 决策 1 - 决策 2 /key_decisions active_contextfileA.ts, 功能 X, 服务商 Y/active_context messages_processed30/messages_processed /context_handoff所有文本字段在嵌入前都会经过 XML 转义 。注入行为因请求协议而异对 Responses 风格请求请求体含input或instructions字段追加到instructions对 Chat Completions 风格请求则在messages数组最前面插入一条role: system的消息contextHandoff.ts。这样下一个账户就能在正确的本地上下文文件、决策、任务进度中继续工作。配置三个核心字段与两层覆盖context-relay支持三个核心配置字段对应源码中的ContextRelayConfig接口contextHandoff.ts配置字段含义默认值handoffThreshold触发摘要生成的警告阈值配额用量百分比0.85handoffModel可选的模型覆盖仅用于摘要生成空沿用请求模型handoffProviders允许触发交接生成的服务商白名单[codex]resolveContextRelayConfig对字段做了约束校验contextHandoff.tshandoffThreshold必须是大于 0 且小于0.95硬停止线的有限数值否则回退到0.85handoffProviders数组项会被trim().toLowerCase()规范化若未显式配置数组则默认[codex]即目前仅有 Codex 一条真实生效路径。此外ContextRelayConfig还包含两个扩展字段maxMessagesForSummary参与摘要的最近消息条数上限默认 30合法范围 5100超出后钳制与relayModeschema-locked | standard默认standard。其中schema-locked模式在选取摘要素材时会排除 system/developer 消息、仅用最近的非系统消息contextHandoff.ts。全局默认值可在设置Settings中配置Combo 级专属值可在 Combos 页面中覆盖——这一“全局默认 Combo 覆盖”的合并逻辑体现在resolveUniversalHandoffConfig中优先取 combo 配置其次取全局配置最后落到默认值contextHandoff.ts。摘要历史素材的选取与 Token 预算文档提到摘要是“紧凑且基于近期历史”的。实现上selectMessagesForSummary结合两条预算线控制素材规模contextHandoff.tsMAX_HISTORY_TOKENS_FOR_SUMMARY 8000格式化后的历史文本 token 估计上限超出则逐条从旧消息开始裁剪DEFAULT_MAX_MESSAGES_FOR_SUMMARY 30参与摘要的最大消息条数DEFAULT_SUMMARY_RESPONSE_TOKENS 800摘要请求的max_tokenstemperature固定为0.1保证输出低随机性、高确定性。架构说明生成与注入的两层分离官方文档明确指出当前实现不采用独立的handleContextRelayCombo处理器而是将职责拆到两层生成侧Combo 执行器文档所述open-sse/services/combo.ts实际实现位于 executeTargetAttempt.ts决定一次成功的回合是否应生成交接——它负责在成功响应后检查配额、触发maybeGenerateHandoff注入侧chat.ts 仅在身份认证解析出请求实际使用的账户后才决定是否注入交接。这种分离在当前代码库中是刻意设计Combo 循环本身无法确定请求是停留在同一账户上还是实际切换了账户因为账户选择发生在认证auth流程内部。只有经过认证解析出真实connectionId之后才能可靠地判断fromAccount ! credentials.connectionId从而避免把交接注入到同一账户的请求中造成冗余。这一设计也在 ARCHITECTURE.md 第 1153 行有明确记载且被 context-relay-codex.test.ts 与 context-relay-handoff.test.ts 两组集成测试覆盖验证。局限性当前版本的边界在使用时需要清楚以下边界有效运行时支持目前集中于codex配额轮换从executeTargetAttempt.ts的provider codex硬性条件与handoffProviders的默认值[codex]可以确认真实可用的轮换路径目前只有 CodexhandoffProviders已建模为配置界面但实际交接生成仍依赖服务商特定的配额管道即白名单字段已开放但配额获取如fetchCodexQuota尚未对所有服务商通用摘要刻意保持紧凑并基于近期历史最多 30 条消息 / 8000 token它是会话的浓缩而非完整的对话回放机制不适合需要逐字恢复全部历史的场景交接作用域限定于sessionId comboName并有expiresAt自动过期机制默认 TTL 为 5 小时即DEFAULT_TTL_MS 5 * 60 * 60 * 1000如果会话未切换账户存储的交接不会被注入——这既是设计意图避免冗余也意味着单账户场景下交接会一直闲置到过期。推荐使用模式让交接真正生效综合文档与源码建议按以下方式使用context-relay使用同一服务商的多个账户——交接的价值完全建立在真实账户切换之上多账户是前提在整个会话中保持稳定的sessionId——交接以sessionId comboName为键存储与检索sessionId 漂移会导致交接无法命中将handoffThreshold设置得足够早如默认 0.85为后台摘要请求预留生成与落库时间——若阈值过接近 0.95 的硬停止线摘要可能来不及在账户耗尽前完成将其视为连续性辅助工具而非持久记忆的替代品——交接是紧凑的近期摘要长期记忆仍应依赖会话之外的外部存储。配置层面在 Combos 页面为长任务 Combo 单独设置handoffThreshold、handoffModel可指定更廉价的摘要模型以节省配额与maxMessagesForSummary通常比全局默认值更符合具体任务需求。总结context-relay是 OmniRoute 面向多账户配额轮换场景的专门策略在阈值窗口内后台生成紧凑的结构化摘要在认证确认账户真实切换后注入context_handoff系统消息消费后即从context_handoffs表删除。它的核心价值在于在不了解认证内部细节的情况下仅通过“生成侧决策 注入侧判断”的两层协作就实现了跨账户的无缝会话延续。理解它的阈值阶段、载荷结构、配置覆盖规则与当前 Codex 局限你就能为长时间编程与研究会话配置出可靠的连续性保障。【免费下载链接】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），仅供参考