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本篇围绕 OmniRoute 的context-relaycombo 策略展开讲解它如何在同一提供商的多个账号轮换时通过后台生成结构化交接摘要并在切号后自动注入系统消息保持长会话的上下文连续性。读完你可以掌握配额三档阈值0.85 预警 / 0.95 硬停的工作流程、context_handoffs存储表与 Handoff Payload 的完整字段、摘要生成提示词与并发去重细节以及注入时机背后的架构分层设计并了解handoffThreshold、handoffModel、handoffProviders三个配置项的取值规则。Context Relay 解决什么问题context-relay是一个 combo 策略当活跃账号在会话结束前发生轮换quota 耗尽被切换到同提供商的另一个账号时它会保持会话连续性。当前运行时可以理解为“优先级路由 交接层”的组合在活跃账号彻底耗尽之前OmniRoute 后台生成一份紧凑的结构化摘要当认证层为同一会话选择了不同的账号后OmniRoute 把该摘要作为系统消息注入下一个请求一旦交接被成功消费对应记录即从存储中删除。从源码结构看这一策略分为“生成”与“注入”两层生成逻辑挂在 combo 主循环之后open-sse/services/combo.ts的成功回合路径注入逻辑则位于src/sse/handlers/chat.tschat.ts 中的注释明确写道 “Context-relay keeps generation in combo.ts, but handoff injection lives here”。这种拆分是有意为之——combo 循环本身并不知道本次请求最终是否换了账号只有认证解析出实际connectionId之后才能判断“是否发生了真实切号”。适用场景判断context-relay建议在以下三个条件同时成立时启用该 combo 预期会在同一提供商的多个账号之间轮换丢失短期对话连续性会损害任务质量典型如多步骤编码、长程研究任务提供商能暴露足够的配额信息使得系统可以预判账号即将触顶。因此它最适合“生命周期可能超过单个账号配额窗口”的长时编码或研究会话。反过来如果你的会话很短、或提供商无法提供配额百分比这个策略基本不会触发任何交接。配额三档阈值运行时流程交接生成的调度以“当前账号已用配额百分比”为轴分四段处理。核心常量定义在 contextHandoff.tsexport const HANDOFF_WARNING_THRESHOLD 0.85; export const HANDOFF_EXHAUSTION_THRESHOLD 0.95;0%–84%不做交接请求完全按普通优先级路由处理不产生任何额外摘要请求。85%–94%后台生成交接摘要当活跃提供商在handoffProviders白名单内且配额使用率进入该区间OmniRoute 会在账号彻底耗尽之前、以setImmediate异步方式触发一次结构化摘要生成。generateHandoff 入口的守卫链逐条实现了文档描述的约束默认预警阈值0.85低于handoffThreshold直接返回硬停阈值0.95percentUsed HANDOFF_EXHAUSTION_THRESHOLD时不再生成——此时系统已处于或临近耗尽运行时避免再调度一次摘要请求每个sessionId comboName只允许一个在途in-flight的交接生成用一个进程内SetstringinflightHandoffGenerations实现去重若该会话/combo 已存在未过期的活跃交接hasActiveHandoff查库也不会重复生成。95% 及以上停止生成不再生成新交接。账号轮换之后注入交接当同一会话的下一个请求解析到不同的已认证账号时OmniRoute 才把存储的交接内容前置为系统消息。注入发生在“真实账号切换已知”之后这一点在 chat.ts 的注入点可以直接验证只有handoff.fromAccount ! credentials.connectionId即当前连接不再是生成交接的那个账号时才调用injectHandoffIntoBody并打印注入日志。若会话始终停留在同一账号存储的交接不会被注入。Handoff Payload存储结构与生命周期持久化载荷存储在context_handoffs表中建表 SQL 见 019_context_handoffs.sql包含以下列字段说明session_id会话标识combo_namecombo 名称from_account生成交接时的来源账号summary密集会话摘要最多 2000 字符见下文常量key_decisions关键决策数组JSON 文本最多 8 条task_progress任务进展描述最多 1200 字符active_entities活跃实体数组文件、特性、提供商等最多 10 个message_count参与摘要的消息条数model会话主模型warning_threshold_pct生成时使用的预警阈值默认0.85generated_at/expires_at生成时间与过期时间created_at入库时间表上建了唯一索引idx_context_handoffs_session_combo (session_id, combo_name)保证同一会话/combo 只保留最新一条交接DAO 层的 upsertHandoff 通过ON CONFLICT(session_id, combo_name) DO UPDATE落实这一约束。交接的读取、删除与过期清理同样集中在 contextHandoffs.tsgetHandoff(sessionId, comboName)仅返回expires_at now且created_at最新的一条deleteHandoff(sessionId, comboName)交接成功消费后由 chat.ts 调用完成“消费即删除”cleanupExpiredHandoffs()按expires_at清理过期行且带 30 分钟节流CLEANUP_THROTTLE_MS避免每次请求都跑清理 SQL交接作用域严格限定为sessionId comboName并自动过期——这与文档“Limitations”一节的描述一致。从源码常量看默认 TTL 为 5 小时DEFAULT_TTL_MS 5 * 60 * 60 * 1000即交接摘要在生成后最多存活 5 小时之后即使账号切换也不再注入。摘要生成提示词、约束与并发保护摘要模型被要求返回固定结构的 JSON 对象HANDOFF_PROMPT_TEMPLATE 原文要求“只返回 JSON 对象不要 markdown、不要解释”{ summary: Dense summary of what matters for continuity, keyDecisions: [Decision 1, Decision 2], taskProgress: What is done, what is pending, and the next step, activeEntities: [fileA.ts, feature X, provider Y] }围绕这次后台摘要请求contextHandoff.ts 定义了一组防御性常量防止交接请求自身把上下文撑爆const MAX_HISTORY_TOKENS_FOR_SUMMARY 8000; // 送入摘要的近期历史 token 上限 const DEFAULT_MAX_MESSAGES_FOR_SUMMARY 30; // 默认取最近 30 条消息 const DEFAULT_SUMMARY_RESPONSE_TOKENS 800; // 摘要响应的 token 预算 const MAX_SUMMARY_LENGTH 2000; // summary 字段最大长度 const MAX_TASK_PROGRESS_LENGTH 1200; // taskProgress 字段最大长度 const MAX_DECISIONS 8; // keyDecisions 条数上限 const MAX_ENTITIES 10; // activeEntities 条数上限 const DEFAULT_TTL_MS 5 * 60 * 60 * 1000; // 交接存活 5 小时这也印证了文档中的一条限制摘要是刻意“紧凑且基于近期历史”的recent-history based不是完整转录回放机制。在途生成去重的实现细节值得注意调度入口先做四道同步守卫sessionId/connectionId非空 →handoffProviders非空 → 高于阈值 → 低于 0.95 → 无活跃交接 → 无在途生成全部通过后才把inflightKey加入inflightHandoffGenerations并在finally中移除。这意味着即便 85%–95% 区间内连续打了很多请求摘要模型也最多只会被调起一次同会话/combo 维度。注入格式context_handoff系统消息注入时OmniRoute 将存储的载荷转换为context_handoffXML 结构的系统消息。buildHandoffSystemMessage 的产物形如context_handoff transfer_reasonAccount quota transfer - continuing from previous session/transfer_reason session_summary.../session_summary task_progress.../task_progress key_decisions - decision1 /key_decisions active_contextfileA.ts, feature X, provider Y/active_context messages_processedN/messages_processed /context_handoff所有字段都经过 XML 转义escapeXml并以一句自然语言收尾指示模型“从上一个账号因配额限制转接而来请无缝继续”。.injectHandoffIntoBody 按请求形态选择注入位置Responses API 形态body 含input或instructions把交接内容拼到instructions字段最前面已有 instructions 时保留其后并顺手剔除空的messages字段Chat Completions 形态在messages数组头部插入一条role: system消息不改动其余消息。这种双形态适配让交接对新旧两套 API 协议都能透明生效。配置参数详解context-relay支持以下配置字段。全局默认值可在 Settings 页面配置combo 级数值可在 Combos 页面覆盖handoffThreshold摘要生成的预警阈值默认0.85handoffModel可选的模型覆盖仅用于摘要生成不影响主会话模型handoffProviders允许触发交接生成的提供商白名单。结合 resolveContextRelayConfig 的解析逻辑可以补充几点文档未展开的取值规则参数默认值解析/钳位规则handoffThreshold0.85必须是有限数且 0、 0.95否则回落到0.85——即配置值永远不会越过硬停线handoffProviders[codex]只有显式传入数组才生效未配置时默认白名单只含codex条目会被 trim 并转小写handoffModel沿用请求模型空字符串/空白表示不覆盖maxMessagesForSummary30有效区间[5, 100]越界回落到默认值此外comboSetup.ts 会进一步把 combo 配置combo.universal_handoff/combo.universalHandoff与全局 relay 配置合并解析resolveUniversalHandoffConfig 还提供了一组通用交接参数triggeralways/on-switch/on-error默认on-switch、providerAllowlist、ttlMinutes1–10080 分钟默认 300、preserveSystemPrompt默认true注入时保留原有 system prompt等。需要注意的是enabled字段受特性开关UNIVERSAL_CONTEXT_HANDOFF_ENABLED控制未开启时通用交接路径整体关闭。已知限制以仓库当前实现为准有效的运行时支持目前以codex配额轮换为中心默认handoffProviders白名单即[codex]且 codex 专属的配额拉取路径依赖真实 codex 会话连接没有进程内可测的测试接缝handoffProviders虽然已经是完整的配置面但真实交接生成仍依赖提供商侧的配额管道quota plumbing——没有配额百分比的提供商无法进入 85%–94% 触发区间摘要刻意紧凑、基于近期历史不是完整转录回放交接作用域为sessionId comboName带 TTL 自动过期若会话没有实际切换账号存储的交接不会被注入。推荐用法模式使用同一提供商的多个账号组成 combo在整个会话期间保持稳定的sessionId交接按会话维度存取与注入把handoffThreshold设置得足够早给后台摘要请求留出时间余量将该特性定位为“连续性辅助”而不是持久记忆persistent memory的替代品。行为验证方面仓库提供了集成测试 context-relay-handoff.test.ts覆盖通用交接路径的三类情形模型切换时触发额外摘要调度 DB 落库、控制组无模型切换时不触发、无 session ID 时不触发测试文件头部注释也明确指出 codex 专属分支需要真实 codex 连接VPS不在进程内覆盖范围内。参考路径速查关注点仓库路径交接调度、阈值常量、提示词模板、注入函数open-sse/services/contextHandoff.ts生成触发点combo 成功回合open-sse/services/combo.ts注入与消费删除认证后判切换src/sse/handlers/chat.ts存储 DAOupsert/get/delete/cleanup/去重查询src/lib/db/contextHandoffs.ts建表迁移唯一索引、默认阈值src/lib/db/migrations/019_context_handoffs.sql行为集成测试tests/integration/combo-matrix/context-relay-handoff.test.ts【免费下载链接】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），仅供参考 OmniRoute Context Relay 深度解析：跨账号轮换时的结构化会话交接机制
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本篇围绕 OmniRoute 的context-relaycombo 策略展开讲解它如何在同一提供商的多个账号轮换时通过后台生成结构化交接摘要并在切号后自动注入系统消息保持长会话的上下文连续性。读完你可以掌握配额三档阈值0.85 预警 / 0.95 硬停的工作流程、context_handoffs存储表与 Handoff Payload 的完整字段、摘要生成提示词与并发去重细节以及注入时机背后的架构分层设计并了解handoffThreshold、handoffModel、handoffProviders三个配置项的取值规则。Context Relay 解决什么问题context-relay是一个 combo 策略当活跃账号在会话结束前发生轮换quota 耗尽被切换到同提供商的另一个账号时它会保持会话连续性。当前运行时可以理解为“优先级路由 交接层”的组合在活跃账号彻底耗尽之前OmniRoute 后台生成一份紧凑的结构化摘要当认证层为同一会话选择了不同的账号后OmniRoute 把该摘要作为系统消息注入下一个请求一旦交接被成功消费对应记录即从存储中删除。从源码结构看这一策略分为“生成”与“注入”两层生成逻辑挂在 combo 主循环之后open-sse/services/combo.ts的成功回合路径注入逻辑则位于src/sse/handlers/chat.tschat.ts 中的注释明确写道 “Context-relay keeps generation in combo.ts, but handoff injection lives here”。这种拆分是有意为之——combo 循环本身并不知道本次请求最终是否换了账号只有认证解析出实际connectionId之后才能判断“是否发生了真实切号”。适用场景判断context-relay建议在以下三个条件同时成立时启用该 combo 预期会在同一提供商的多个账号之间轮换丢失短期对话连续性会损害任务质量典型如多步骤编码、长程研究任务提供商能暴露足够的配额信息使得系统可以预判账号即将触顶。因此它最适合“生命周期可能超过单个账号配额窗口”的长时编码或研究会话。反过来如果你的会话很短、或提供商无法提供配额百分比这个策略基本不会触发任何交接。配额三档阈值运行时流程交接生成的调度以“当前账号已用配额百分比”为轴分四段处理。核心常量定义在 contextHandoff.tsexport const HANDOFF_WARNING_THRESHOLD 0.85; export const HANDOFF_EXHAUSTION_THRESHOLD 0.95;0%–84%不做交接请求完全按普通优先级路由处理不产生任何额外摘要请求。85%–94%后台生成交接摘要当活跃提供商在handoffProviders白名单内且配额使用率进入该区间OmniRoute 会在账号彻底耗尽之前、以setImmediate异步方式触发一次结构化摘要生成。generateHandoff 入口的守卫链逐条实现了文档描述的约束默认预警阈值0.85低于handoffThreshold直接返回硬停阈值0.95percentUsed HANDOFF_EXHAUSTION_THRESHOLD时不再生成——此时系统已处于或临近耗尽运行时避免再调度一次摘要请求每个sessionId comboName只允许一个在途in-flight的交接生成用一个进程内SetstringinflightHandoffGenerations实现去重若该会话/combo 已存在未过期的活跃交接hasActiveHandoff查库也不会重复生成。95% 及以上停止生成不再生成新交接。账号轮换之后注入交接当同一会话的下一个请求解析到不同的已认证账号时OmniRoute 才把存储的交接内容前置为系统消息。注入发生在“真实账号切换已知”之后这一点在 chat.ts 的注入点可以直接验证只有handoff.fromAccount ! credentials.connectionId即当前连接不再是生成交接的那个账号时才调用injectHandoffIntoBody并打印注入日志。若会话始终停留在同一账号存储的交接不会被注入。Handoff Payload存储结构与生命周期持久化载荷存储在context_handoffs表中建表 SQL 见 019_context_handoffs.sql包含以下列字段说明session_id会话标识combo_namecombo 名称from_account生成交接时的来源账号summary密集会话摘要最多 2000 字符见下文常量key_decisions关键决策数组JSON 文本最多 8 条task_progress任务进展描述最多 1200 字符active_entities活跃实体数组文件、特性、提供商等最多 10 个message_count参与摘要的消息条数model会话主模型warning_threshold_pct生成时使用的预警阈值默认0.85generated_at/expires_at生成时间与过期时间created_at入库时间表上建了唯一索引idx_context_handoffs_session_combo (session_id, combo_name)保证同一会话/combo 只保留最新一条交接DAO 层的 upsertHandoff 通过ON CONFLICT(session_id, combo_name) DO UPDATE落实这一约束。交接的读取、删除与过期清理同样集中在 contextHandoffs.tsgetHandoff(sessionId, comboName)仅返回expires_at now且created_at最新的一条deleteHandoff(sessionId, comboName)交接成功消费后由 chat.ts 调用完成“消费即删除”cleanupExpiredHandoffs()按expires_at清理过期行且带 30 分钟节流CLEANUP_THROTTLE_MS避免每次请求都跑清理 SQL交接作用域严格限定为sessionId comboName并自动过期——这与文档“Limitations”一节的描述一致。从源码常量看默认 TTL 为 5 小时DEFAULT_TTL_MS 5 * 60 * 60 * 1000即交接摘要在生成后最多存活 5 小时之后即使账号切换也不再注入。摘要生成提示词、约束与并发保护摘要模型被要求返回固定结构的 JSON 对象HANDOFF_PROMPT_TEMPLATE 原文要求“只返回 JSON 对象不要 markdown、不要解释”{ summary: Dense summary of what matters for continuity, keyDecisions: [Decision 1, Decision 2], taskProgress: What is done, what is pending, and the next step, activeEntities: [fileA.ts, feature X, provider Y] }围绕这次后台摘要请求contextHandoff.ts 定义了一组防御性常量防止交接请求自身把上下文撑爆const MAX_HISTORY_TOKENS_FOR_SUMMARY 8000; // 送入摘要的近期历史 token 上限 const DEFAULT_MAX_MESSAGES_FOR_SUMMARY 30; // 默认取最近 30 条消息 const DEFAULT_SUMMARY_RESPONSE_TOKENS 800; // 摘要响应的 token 预算 const MAX_SUMMARY_LENGTH 2000; // summary 字段最大长度 const MAX_TASK_PROGRESS_LENGTH 1200; // taskProgress 字段最大长度 const MAX_DECISIONS 8; // keyDecisions 条数上限 const MAX_ENTITIES 10; // activeEntities 条数上限 const DEFAULT_TTL_MS 5 * 60 * 60 * 1000; // 交接存活 5 小时这也印证了文档中的一条限制摘要是刻意“紧凑且基于近期历史”的recent-history based不是完整转录回放机制。在途生成去重的实现细节值得注意调度入口先做四道同步守卫sessionId/connectionId非空 →handoffProviders非空 → 高于阈值 → 低于 0.95 → 无活跃交接 → 无在途生成全部通过后才把inflightKey加入inflightHandoffGenerations并在finally中移除。这意味着即便 85%–95% 区间内连续打了很多请求摘要模型也最多只会被调起一次同会话/combo 维度。注入格式context_handoff系统消息注入时OmniRoute 将存储的载荷转换为context_handoffXML 结构的系统消息。buildHandoffSystemMessage 的产物形如context_handoff transfer_reasonAccount quota transfer - continuing from previous session/transfer_reason session_summary.../session_summary task_progress.../task_progress key_decisions - decision1 /key_decisions active_contextfileA.ts, feature X, provider Y/active_context messages_processedN/messages_processed /context_handoff所有字段都经过 XML 转义escapeXml并以一句自然语言收尾指示模型“从上一个账号因配额限制转接而来请无缝继续”。.injectHandoffIntoBody 按请求形态选择注入位置Responses API 形态body 含input或instructions把交接内容拼到instructions字段最前面已有 instructions 时保留其后并顺手剔除空的messages字段Chat Completions 形态在messages数组头部插入一条role: system消息不改动其余消息。这种双形态适配让交接对新旧两套 API 协议都能透明生效。配置参数详解context-relay支持以下配置字段。全局默认值可在 Settings 页面配置combo 级数值可在 Combos 页面覆盖handoffThreshold摘要生成的预警阈值默认0.85handoffModel可选的模型覆盖仅用于摘要生成不影响主会话模型handoffProviders允许触发交接生成的提供商白名单。结合 resolveContextRelayConfig 的解析逻辑可以补充几点文档未展开的取值规则参数默认值解析/钳位规则handoffThreshold0.85必须是有限数且 0、 0.95否则回落到0.85——即配置值永远不会越过硬停线handoffProviders[codex]只有显式传入数组才生效未配置时默认白名单只含codex条目会被 trim 并转小写handoffModel沿用请求模型空字符串/空白表示不覆盖maxMessagesForSummary30有效区间[5, 100]越界回落到默认值此外comboSetup.ts 会进一步把 combo 配置combo.universal_handoff/combo.universalHandoff与全局 relay 配置合并解析resolveUniversalHandoffConfig 还提供了一组通用交接参数triggeralways/on-switch/on-error默认on-switch、providerAllowlist、ttlMinutes1–10080 分钟默认 300、preserveSystemPrompt默认true注入时保留原有 system prompt等。需要注意的是enabled字段受特性开关UNIVERSAL_CONTEXT_HANDOFF_ENABLED控制未开启时通用交接路径整体关闭。已知限制以仓库当前实现为准有效的运行时支持目前以codex配额轮换为中心默认handoffProviders白名单即[codex]且 codex 专属的配额拉取路径依赖真实 codex 会话连接没有进程内可测的测试接缝handoffProviders虽然已经是完整的配置面但真实交接生成仍依赖提供商侧的配额管道quota plumbing——没有配额百分比的提供商无法进入 85%–94% 触发区间摘要刻意紧凑、基于近期历史不是完整转录回放交接作用域为sessionId comboName带 TTL 自动过期若会话没有实际切换账号存储的交接不会被注入。推荐用法模式使用同一提供商的多个账号组成 combo在整个会话期间保持稳定的sessionId交接按会话维度存取与注入把handoffThreshold设置得足够早给后台摘要请求留出时间余量将该特性定位为“连续性辅助”而不是持久记忆persistent memory的替代品。行为验证方面仓库提供了集成测试 context-relay-handoff.test.ts覆盖通用交接路径的三类情形模型切换时触发额外摘要调度 DB 落库、控制组无模型切换时不触发、无 session ID 时不触发测试文件头部注释也明确指出 codex 专属分支需要真实 codex 连接VPS不在进程内覆盖范围内。参考路径速查关注点仓库路径交接调度、阈值常量、提示词模板、注入函数open-sse/services/contextHandoff.ts生成触发点combo 成功回合open-sse/services/combo.ts注入与消费删除认证后判切换src/sse/handlers/chat.ts存储 DAOupsert/get/delete/cleanup/去重查询src/lib/db/contextHandoffs.ts建表迁移唯一索引、默认阈值src/lib/db/migrations/019_context_handoffs.sql行为集成测试tests/integration/combo-matrix/context-relay-handoff.test.ts【免费下载链接】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），仅供参考