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组合路由策略专门解决“会话进行中活跃账号被配额耗尽、被迫切换到同提供商另一个账号”时的短时上下文断裂问题。本文围绕该策略的运行时行为、交接载荷handoff payload结构、配置项与代码实现展开帮助读者理解 OmniRoute 如何在账号轮换前于后台生成结构化摘要并在确认真实切换账号后将其注入下一条请求从而让长时间运行的编码或研究会话跨越单个账号窗口继续推进。什么是 Context RelayContext Relay 是一种combo 策略在源码中被归入路由策略集合参见 routingStrategies.ts其核心目标是当活跃账号在对话尚未结束时发生轮换保持会话的连续性。它的运行方式类似“模型选择的优先级路由priority routing”但在此之上叠加了一层交接handoff机制在活跃账号耗尽之前OmniRoute 在后台生成一份紧凑的结构化摘要当认证流程为同一会话选择了不同的账号时OmniRoute 把这份摘要作为一条系统消息注入下一条请求交接摘要被成功消费后即从存储中删除。从本质上讲Context Relay 提供的是“连续性辅助continuity assistance”而不是持久记忆persistent memory的替代品——它记录的是近期历史精华而非完整对话回放。何时使用 Context Relay文档明确给出了三条同时成立的使用前提前提条件说明组合预期在多个同提供商账号之间轮换例如同一 provider 配置了多个 Codex 账号连接配额用尽时按优先级依次切换丢失短时对话连续性会损害任务质量比如多轮修改同一组文件的长任务中途换账号后新账号“失忆”会重复劳动提供商暴露足够的配额信息以预测账号额度将尽只有能提前感知percentUsed才能抢在耗尽前生成交接摘要这一特性对于可能超过单个账号窗口的长时编码或研究会话long-running coding or research sessions最为有用。仓库中的集成测试 chat-context-relay.test.ts 即以 Codex OAuth 多账号、配额百分比模拟的方式验证了这一完整链路。运行时流程当前行为被有意拆分为两个运行时层combo 层负责决定是否生成交接chat 处理层负责注入交接见下文“架构说明”。整个流程依据配额使用比例分阶段进行。配额使用 0% ~ 84%不生成任何交接。请求行为与普通优先级路由完全一致。配额使用 85% ~ 94%若当前活跃提供商被启用出现在handoffProviders白名单中OmniRoute 会在账号完全耗尽之前于后台生成结构化交接摘要。关键细节默认告警阈值为0.85源码常量HANDOFF_WARNING_THRESHOLD 0.85见 contextHandoff.ts生成交接的硬性上限为0.95HANDOFF_EXHAUSTION_THRESHOLD 0.95每个sessionId comboName组合同一时刻只允许一个在途in-flight交接生成任务源码使用inflightHandoffGenerations这个Set做互斥键为${sessionId}::${comboName}如果该 session/combo 已存在活跃交接则不重复生成摘要。判断逻辑集中在maybeGenerateHandoffcontextHandoff.ts先解析 relay 配置再依次检查白名单非空、percentUsed handoffThreshold、percentUsed 0.95、无活跃交接、无在途生成任务全部通过后通过setImmediate异步执行摘要生成。配额使用 95% 及以上不再生成新的交接。此时系统已处于或接近耗尽状态运行时避免再调度一次额外的摘要请求以免与真实请求争夺资源。账号轮换之后当同一会话的下一条请求最终解析到不同的已认证账号时OmniRoute 将已存储的交接作为系统消息前置到请求中。注入只发生在真实账号切换被确认之后——因为在组合循环内部无法可靠预知认证会选中哪个账号必须等 auth 层给出最终结果。注入侧的核心实现位于 chat.ts当策略为context-relay、请求体未携带_omnirouteSkipContextRelay标记时读取getHandoff(sessionId, comboName)若handoff.fromAccount ! 当前解析到的 connectionId则调用injectHandoffIntoBody注入请求成功后调用deleteHandoff删除该交接一次性消费。交接载荷Handoff Payload持久化的交接载荷存储在数据库表context_handoffs中表结构映射见 contextHandoffs.ts字段如下字段含义sessionId所属会话标识comboName所属组合名称fromAccount生成交接时对应的源账号连接 IDsummary连续性所需的高密度摘要文本keyDecisions关键决策列表taskProgress任务进展已完成、待办与下一步activeEntities活跃实体列表如fileA.ts、特性 X、提供商 YmessageCount生成摘要时参考的消息条数model用于生成摘要的模型warningThresholdPct触发告警的配额阈值generatedAt生成时间expiresAt过期时间自动过期摘要模型被要求返回如下结构的 JSON 对象{ 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] }在注入时OmniRoute 将该载荷转换为一条context_handoff系统消息使下一个账号能基于正确的本地上下文继续工作。源码中buildHandoffSystemMessagecontextHandoff.ts生成的消息形如context_handoff transfer_reasonAccount quota transfer - continuing from previous session/transfer_reason session_summary.../session_summary task_progress.../task_progress key_decisions - ... /key_decisions active_context.../active_context messages_processedN/messages_processed /context_handoff You are continuing a conversation that was transferred from another account due to quota limits.底层生成细节源码级摘要生成请求generateHandoffAsync有明确的工程约束值得关注历史消息采样selectMessagesForSummary默认最多取最近 30 条非系统消息DEFAULT_MAX_MESSAGES_FOR_SUMMARY 30并持续裁剪直到历史文本的预估 token 数不超过MAX_HISTORY_TOKENS_FOR_SUMMARY 8000长度上限summary截断到 2000 字符MAX_SUMMARY_LENGTH、taskProgress到 1200 字符MAX_TASK_PROGRESS_LENGTH、keyDecisions最多 8 条、activeEntities最多 10 条normalizeStringArray生成请求以temperature: 0.1、max_tokens: 800、stream: false调用摘要模型并附带内部标记_omnirouteSkipContextRelay: true与_omnirouteInternalRequest: context-handoff防止摘要请求自身递归触发 Context Relay结果解析parseHandoffJSON先剥离 markdown 代码围栏与omniModel标签再尝试 JSON.parse失败则截取首尾大括号之间的内容解析失败或上游调用失败会通过logUniversalHandoffOutcome输出告警日志combo 名 失败原因过期清理cleanupExpiredHandoffs删除已过期记录且清理有 30 分钟节流CLEANUP_THROTTLE_MSgetHandoff查询时也带expires_at now过滤默认 TTL未显式指定过期时间时交接默认 5 小时过期DEFAULT_TTL_MS 5 * 60 * 60 * 1000。配置项context-relay支持以下配置字段配置字段作用默认值handoffThreshold触发摘要生成的告警配额阈值0.85handoffModel仅用于摘要生成的模型覆盖可选使用当前请求模型handoffProviders允许触发交接生成的白名单提供商[codex]配置解析位于resolveContextRelayConfigcontextHandoff.tshandoffThreshold必须是(0, 0.95)区间内的有限数字否则回退到0.85——它被硬性限制在耗尽阈值之下确保摘要一定在账号耗尽前生成handoffModel仅在非空字符串时生效否则摘要使用与当前请求相同的模型handoffProviders若未显式传入数组默认为[codex]与当前实现聚焦 Codex 配额轮换的事实一致另有扩展字段maxMessagesForSummary5100默认 30与relayModestandard或schema-locked影响采样时是否保留系统消息。全局默认值可在Settings设置中配置Combo 级配置可在Combos组合页面覆盖全局值。界面侧对应设置项位于 Settings 的Resilience韧性分组——“Context Relay handoff threshold and summary model configuration”见 FEATURES.md。全局与组合级配置的级联读取同样服务于另一种“通用交接”机制resolveUniversalHandoffConfig它按on-switch / always / on-error触发模式为任意模型/提供商切换生成交接默认trigger: on-switch、TTL 300 分钟作为 context-relay 的扩展形态与代码基础共享同一套 prompt 模板与解析工具。架构说明当前实现没有独立的handleContextRelayCombo处理器职责被有意拆分为两层combo.ts 相关执行路径executeTargetAttempt决定一次成功轮次turn之后是否应生成交接在策略为context-relay、提供商命中handoffProviders白名单且为codex时通过getSessionConnection取得会话连接fetchCodexQuota拉取配额信息会话/周窗口的resetAt取最早者作为expiresAt再把percentUsed与消息历史传给maybeGenerateHandoffchat.ts 仅在认证解析出请求实际使用的账号后注入交接injectHandoffIntoBody并在请求成功后删除deleteHandoff。这种拆分是刻意的combo 循环本身不知道请求是停留在同一账号还是真正切换了账号账号选择发生在 auth 层内部因此“生成”与“注入”必须分别落在两个知道对应事实的运行时阶段。此外注入逻辑还兼容 OpenAI Responses 格式的请求instructions/input形态与 Chat Completions 形态messages前置 system 消息见injectHandoffIntoBody对isResponsesRequest的分支处理。限制与注意事项当前有效的运行时支持集中于 Codex 配额轮换handoffProviders虽已建模为通用配置面但真实交接生成仍依赖各提供商自身的配额管道摘要是刻意紧凑、基于近期历史的不是完整 transcript 回放机制交接按sessionId comboName作用域隔离且自动过期如果会话没有切换账号已存储的交接不会被注入交接是一次性消费注入成功且请求成功后即被删除。推荐使用模式使用同一提供商的多个账号并让组合在账号间轮换在整个会话期间保持稳定的sessionId值这是交接作用域与命中判断的前提尽早设置handoffThreshold为后台摘要请求留出足够的提前量阈值越高留给摘要生成与注入的窗口越窄把该特性视为连续性辅助而不是持久记忆的替代品——真正需要长期记忆的场景仍应配合项目的记忆/上下文体系使用。相关代码与测试索引策略定义与下拉选项routingStrategies.ts交接生成/解析/注入核心实现contextHandoff.ts交接持久化context_handoffs表、upsert/get/delete/cleanupcontextHandoffs.tscombo 侧触发条件executeTargetAttemptexecuteTargetAttempt.tschat 侧注入与消费chat.ts端到端链路测试chat-context-relay.test.ts、context-handoff.test.ts、db-context-handoffs.test.ts、service-context-handoff.test.ts、universal-handoff.test.ts功能入口文档FEATURES.md【免费下载链接】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导读context-relay是 OmniRoute 提供的一种 Combo组合路由策略专门解决“会话进行中活跃账号被配额耗尽、被迫切换到同提供商另一个账号”时的短时上下文断裂问题。本文围绕该策略的运行时行为、交接载荷handoff payload结构、配置项与代码实现展开帮助读者理解 OmniRoute 如何在账号轮换前于后台生成结构化摘要并在确认真实切换账号后将其注入下一条请求从而让长时间运行的编码或研究会话跨越单个账号窗口继续推进。什么是 Context RelayContext Relay 是一种combo 策略在源码中被归入路由策略集合参见 routingStrategies.ts其核心目标是当活跃账号在对话尚未结束时发生轮换保持会话的连续性。它的运行方式类似“模型选择的优先级路由priority routing”但在此之上叠加了一层交接handoff机制在活跃账号耗尽之前OmniRoute 在后台生成一份紧凑的结构化摘要当认证流程为同一会话选择了不同的账号时OmniRoute 把这份摘要作为一条系统消息注入下一条请求交接摘要被成功消费后即从存储中删除。从本质上讲Context Relay 提供的是“连续性辅助continuity assistance”而不是持久记忆persistent memory的替代品——它记录的是近期历史精华而非完整对话回放。何时使用 Context Relay文档明确给出了三条同时成立的使用前提前提条件说明组合预期在多个同提供商账号之间轮换例如同一 provider 配置了多个 Codex 账号连接配额用尽时按优先级依次切换丢失短时对话连续性会损害任务质量比如多轮修改同一组文件的长任务中途换账号后新账号“失忆”会重复劳动提供商暴露足够的配额信息以预测账号额度将尽只有能提前感知percentUsed才能抢在耗尽前生成交接摘要这一特性对于可能超过单个账号窗口的长时编码或研究会话long-running coding or research sessions最为有用。仓库中的集成测试 chat-context-relay.test.ts 即以 Codex OAuth 多账号、配额百分比模拟的方式验证了这一完整链路。运行时流程当前行为被有意拆分为两个运行时层combo 层负责决定是否生成交接chat 处理层负责注入交接见下文“架构说明”。整个流程依据配额使用比例分阶段进行。配额使用 0% ~ 84%不生成任何交接。请求行为与普通优先级路由完全一致。配额使用 85% ~ 94%若当前活跃提供商被启用出现在handoffProviders白名单中OmniRoute 会在账号完全耗尽之前于后台生成结构化交接摘要。关键细节默认告警阈值为0.85源码常量HANDOFF_WARNING_THRESHOLD 0.85见 contextHandoff.ts生成交接的硬性上限为0.95HANDOFF_EXHAUSTION_THRESHOLD 0.95每个sessionId comboName组合同一时刻只允许一个在途in-flight交接生成任务源码使用inflightHandoffGenerations这个Set做互斥键为${sessionId}::${comboName}如果该 session/combo 已存在活跃交接则不重复生成摘要。判断逻辑集中在maybeGenerateHandoffcontextHandoff.ts先解析 relay 配置再依次检查白名单非空、percentUsed handoffThreshold、percentUsed 0.95、无活跃交接、无在途生成任务全部通过后通过setImmediate异步执行摘要生成。配额使用 95% 及以上不再生成新的交接。此时系统已处于或接近耗尽状态运行时避免再调度一次额外的摘要请求以免与真实请求争夺资源。账号轮换之后当同一会话的下一条请求最终解析到不同的已认证账号时OmniRoute 将已存储的交接作为系统消息前置到请求中。注入只发生在真实账号切换被确认之后——因为在组合循环内部无法可靠预知认证会选中哪个账号必须等 auth 层给出最终结果。注入侧的核心实现位于 chat.ts当策略为context-relay、请求体未携带_omnirouteSkipContextRelay标记时读取getHandoff(sessionId, comboName)若handoff.fromAccount ! 当前解析到的 connectionId则调用injectHandoffIntoBody注入请求成功后调用deleteHandoff删除该交接一次性消费。交接载荷Handoff Payload持久化的交接载荷存储在数据库表context_handoffs中表结构映射见 contextHandoffs.ts字段如下字段含义sessionId所属会话标识comboName所属组合名称fromAccount生成交接时对应的源账号连接 IDsummary连续性所需的高密度摘要文本keyDecisions关键决策列表taskProgress任务进展已完成、待办与下一步activeEntities活跃实体列表如fileA.ts、特性 X、提供商 YmessageCount生成摘要时参考的消息条数model用于生成摘要的模型warningThresholdPct触发告警的配额阈值generatedAt生成时间expiresAt过期时间自动过期摘要模型被要求返回如下结构的 JSON 对象{ 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] }在注入时OmniRoute 将该载荷转换为一条context_handoff系统消息使下一个账号能基于正确的本地上下文继续工作。源码中buildHandoffSystemMessagecontextHandoff.ts生成的消息形如context_handoff transfer_reasonAccount quota transfer - continuing from previous session/transfer_reason session_summary.../session_summary task_progress.../task_progress key_decisions - ... /key_decisions active_context.../active_context messages_processedN/messages_processed /context_handoff You are continuing a conversation that was transferred from another account due to quota limits.底层生成细节源码级摘要生成请求generateHandoffAsync有明确的工程约束值得关注历史消息采样selectMessagesForSummary默认最多取最近 30 条非系统消息DEFAULT_MAX_MESSAGES_FOR_SUMMARY 30并持续裁剪直到历史文本的预估 token 数不超过MAX_HISTORY_TOKENS_FOR_SUMMARY 8000长度上限summary截断到 2000 字符MAX_SUMMARY_LENGTH、taskProgress到 1200 字符MAX_TASK_PROGRESS_LENGTH、keyDecisions最多 8 条、activeEntities最多 10 条normalizeStringArray生成请求以temperature: 0.1、max_tokens: 800、stream: false调用摘要模型并附带内部标记_omnirouteSkipContextRelay: true与_omnirouteInternalRequest: context-handoff防止摘要请求自身递归触发 Context Relay结果解析parseHandoffJSON先剥离 markdown 代码围栏与omniModel标签再尝试 JSON.parse失败则截取首尾大括号之间的内容解析失败或上游调用失败会通过logUniversalHandoffOutcome输出告警日志combo 名 失败原因过期清理cleanupExpiredHandoffs删除已过期记录且清理有 30 分钟节流CLEANUP_THROTTLE_MSgetHandoff查询时也带expires_at now过滤默认 TTL未显式指定过期时间时交接默认 5 小时过期DEFAULT_TTL_MS 5 * 60 * 60 * 1000。配置项context-relay支持以下配置字段配置字段作用默认值handoffThreshold触发摘要生成的告警配额阈值0.85handoffModel仅用于摘要生成的模型覆盖可选使用当前请求模型handoffProviders允许触发交接生成的白名单提供商[codex]配置解析位于resolveContextRelayConfigcontextHandoff.tshandoffThreshold必须是(0, 0.95)区间内的有限数字否则回退到0.85——它被硬性限制在耗尽阈值之下确保摘要一定在账号耗尽前生成handoffModel仅在非空字符串时生效否则摘要使用与当前请求相同的模型handoffProviders若未显式传入数组默认为[codex]与当前实现聚焦 Codex 配额轮换的事实一致另有扩展字段maxMessagesForSummary5100默认 30与relayModestandard或schema-locked影响采样时是否保留系统消息。全局默认值可在Settings设置中配置Combo 级配置可在Combos组合页面覆盖全局值。界面侧对应设置项位于 Settings 的Resilience韧性分组——“Context Relay handoff threshold and summary model configuration”见 FEATURES.md。全局与组合级配置的级联读取同样服务于另一种“通用交接”机制resolveUniversalHandoffConfig它按on-switch / always / on-error触发模式为任意模型/提供商切换生成交接默认trigger: on-switch、TTL 300 分钟作为 context-relay 的扩展形态与代码基础共享同一套 prompt 模板与解析工具。架构说明当前实现没有独立的handleContextRelayCombo处理器职责被有意拆分为两层combo.ts 相关执行路径executeTargetAttempt决定一次成功轮次turn之后是否应生成交接在策略为context-relay、提供商命中handoffProviders白名单且为codex时通过getSessionConnection取得会话连接fetchCodexQuota拉取配额信息会话/周窗口的resetAt取最早者作为expiresAt再把percentUsed与消息历史传给maybeGenerateHandoffchat.ts 仅在认证解析出请求实际使用的账号后注入交接injectHandoffIntoBody并在请求成功后删除deleteHandoff。这种拆分是刻意的combo 循环本身不知道请求是停留在同一账号还是真正切换了账号账号选择发生在 auth 层内部因此“生成”与“注入”必须分别落在两个知道对应事实的运行时阶段。此外注入逻辑还兼容 OpenAI Responses 格式的请求instructions/input形态与 Chat Completions 形态messages前置 system 消息见injectHandoffIntoBody对isResponsesRequest的分支处理。限制与注意事项当前有效的运行时支持集中于 Codex 配额轮换handoffProviders虽已建模为通用配置面但真实交接生成仍依赖各提供商自身的配额管道摘要是刻意紧凑、基于近期历史的不是完整 transcript 回放机制交接按sessionId comboName作用域隔离且自动过期如果会话没有切换账号已存储的交接不会被注入交接是一次性消费注入成功且请求成功后即被删除。推荐使用模式使用同一提供商的多个账号并让组合在账号间轮换在整个会话期间保持稳定的sessionId值这是交接作用域与命中判断的前提尽早设置handoffThreshold为后台摘要请求留出足够的提前量阈值越高留给摘要生成与注入的窗口越窄把该特性视为连续性辅助而不是持久记忆的替代品——真正需要长期记忆的场景仍应配合项目的记忆/上下文体系使用。相关代码与测试索引策略定义与下拉选项routingStrategies.ts交接生成/解析/注入核心实现contextHandoff.ts交接持久化context_handoffs表、upsert/get/delete/cleanupcontextHandoffs.tscombo 侧触发条件executeTargetAttemptexecuteTargetAttempt.tschat 侧注入与消费chat.ts端到端链路测试chat-context-relay.test.ts、context-handoff.test.ts、db-context-handoffs.test.ts、service-context-handoff.test.ts、universal-handoff.test.ts功能入口文档FEATURES.md【免费下载链接】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），仅供参考