Self Checks / 自检
CC Switch Version / 版本号
3.20.2-1
Operating System / 操作系统
Windows
Related App / 涉及应用
Codex
Steps to Reproduce / 重现步骤
-
在 Windows 环境中使用最新版 Codex Desktop 和 ccswitchmulti。
-
在 ccswitchmulti 中使用「配置多路模型」功能完成 MultiRouter 配置，并使 GPT-5.6 Sol（gpt-5.6-sol）出现在可用模型列表中。
-
完成配置后，让 ccswitchmulti 自动生成：
C:\Users\Administrator\.codex\config.tomlC:\Users\Administrator\.codex\cc-switch-model-catalog.json
-
检查生成后的 config.toml。
GPT-5.6 Sol 如果需要按 1M 上下文运行，我目前需要手动确保顶层存在：
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000
但 ccswitchmulti 自动生成配置后，model_context_window 和 model_auto_compact_token_limit 没有被稳定保留，需要手动添加。
-
检查 config.toml 中 [model_providers.codex_model_router_v2].models 对应的 GPT-5.6 Sol 条目。
自动生成时通常为：
context_window = 272000
contextWindow = 272000
为了使用 1M 上下文，我需要手动修改为：
context_window = 1000000
contextWindow = 1000000
-
再检查 cc-switch-model-catalog.json 中 GPT-5.6 Sol 的模型信息。
自动生成时为：
"contextWindow": 272000,
"context_window": 272000,
"maxContextWindow": 272000,
"max_context_window": 272000
我需要手动修改为：
"contextWindow": 1000000,
"context_window": 1000000,
"maxContextWindow": 1050000,
"max_context_window": 1050000
-
完成上述手工修改后使用 Codex。
-
重启 ccswitchmulti，或者重新进入 MultiRouter 配置并执行保存、同步等会重新生成配置文件的操作。
-
再次检查 config.toml 和 cc-switch-model-catalog.json。
可以观察到之前手动设置的长上下文参数可能被重新生成的默认配置覆盖，需要再次手动修改。
-
如果此时重新打开 Codex 并继续之前已经积累了较长上下文的会话，Codex 会按照重新生成后的较小上下文配置运行。在我的使用中，这会导致原本按 1M 上下文使用的旧会话很快触发上下文压缩。
Expected Behavior / 期望行为
希望 ccswitchmulti 在 MultiRouter 模式下能够正确支持并持久化“逐模型上下文配置”。
以 GPT-5.6 Sol 为例，如果用户希望该模型按照 1M 上下文运行，希望能够在 ccswitchmulti 中有明确的设置方式，例如配置：
工作上下文窗口：1,000,000
模型最大上下文：1,050,000
自动压缩阈值：900,000
具体实现不一定要求必须使用顶层：
model_context_window = 1000000
model_auto_compact_token_limit = 900000
如果 MultiRouter 为了兼容不同上下文长度的模型，需要采用逐模型配置方式，也可以使用其它实现。
关键预期是：
- 用户能够在 ccswitchmulti 中明确查看和设置某个模型使用的上下文长度；
- 该设置能够持久化保存，而不是只存在于自动生成的 JSON / TOML 文件中；
- 重启 ccswitchmulti 后设置不会丢失；
- 重新保存 MultiRouter 配置后设置不会丢失；
- 重新执行「同步模型目录」后设置不会恢复为默认值；
config.toml、cc-switch-model-catalog.json 和 Router 的模型信息应该保持一致；- 用户不需要每次重新生成配置后，再手工修改多个文件；
- 切换不同模型时，应使用各模型自己的上下文配置，避免一个模型的 1M 设置错误影响其它上下文较小的模型；
- 如果用户设置的上下文长度超过当前模型实际支持的最大值，希望明确提示或自动限制，而不是静默写入其它值；
- 已有长会话重新打开时，不应因为 ccswitchmulti 重启或重新生成配置而意外从 1M 回退到 272K，并因此提前触发上下文压缩。
最终希望达到的效果是：
用户设置一次 GPT-5.6 Sol = 1M
↓
保存到 ccswitchmulti 自身配置
↓
重启 ccswitchmulti
↓
重新同步模型目录
↓
重新生成 config.toml / catalog
↓
仍然保持该模型的 1M 设置
也就是说，“自动生成配置文件”应该是用户持久化配置的输出结果，而不应该成为唯一保存这些参数的位置。
Actual Behavior / 实际行为
目前在 MultiRouter 模式下，我没有找到一个明确的位置，可以为 GPT-5.6 Sol 设置并持久化 1M 上下文窗口以及自动压缩阈值。
当前实际情况是：
-
ccswitchmulti 自动生成的 config.toml 没有稳定保留我需要的：
model_context_window = 1000000
model_auto_compact_token_limit = 900000
-
[model_providers.codex_model_router_v2].models 中 GPT-5.6 Sol 的上下文信息会自动生成成：
context_window = 272000
contextWindow = 272000
-
cc-switch-model-catalog.json 中 GPT-5.6 Sol 也会自动生成成：
"contextWindow": 272000,
"context_window": 272000,
"maxContextWindow": 272000,
"max_context_window": 272000
-
为了让 GPT-5.6 Sol 按照 1M 上下文使用，目前我需要手工修改三个位置：
config.toml 顶层的上下文和自动压缩配置；config.toml 中 Router 模型列表里的 GPT-5.6 Sol 上下文信息；cc-switch-model-catalog.json 中 GPT-5.6 Sol 的 context / max context 信息。
-
手工修改之后可以继续使用，但这些修改不是由 ccswitchmulti 自身持久化管理的。
-
重启 ccswitchmulti 或重新生成 MultiRouter 配置后，这些值可能再次恢复为自动生成的默认值，需要重新手工修改。
-
因为配置回退并不会明显提醒用户，所以很容易出现“忘记再次手工修改”的情况。
-
如果此时继续一个之前已经使用较大上下文的 Codex 会话，Codex 会按照当前较小的上下文配置处理已有会话。在我的使用中，旧会话会很快触发自动压缩，原本仍可以保留在 1M 窗口中的详细历史上下文会被提前压缩。
因此，目前的问题不仅是“设置比较麻烦”，而是用户设置的模型上下文参数缺少稳定的配置来源和持久化机制，重新生成配置后可能静默改变 Codex 会话的上下文行为。
Additional Context / 补充信息
这个问题可能同时涉及“配置入口、持久化、模型 metadata 和配置生成”几个环节。
1. 本 Issue 主要关注 MultiRouter 下的逐模型上下文配置
我不确定 ccswitchmulti 当前是否已经存在 MultiRouter 专用的上下文设置入口。
如果已经存在，希望能够确认正确的设置位置；如果目前没有，则建议增加明确的逐模型上下文配置能力。
本 Issue 并不要求 MultiRouter 一定使用全局：
model_context_window
model_auto_compact_token_limit
因为 MultiRouter 中不同模型可能具有不同的上下文能力，全局固定为 1M 确实可能不适合所有模型。
更希望解决的是“每个模型自己的上下文参数如何配置、保存并稳定生成”。
2. 建议区分几个不同概念
对于支持长上下文的模型，建议不要把下面几个值视为完全相同的字段：
模型最大上下文窗口
用户希望实际使用的上下文窗口
自动压缩阈值
以本例为例，我实际需要的是：
GPT-5.6 Sol
最大上下文：
1,050,000
实际工作窗口：
1,000,000
自动压缩阈值：
900,000
因此如果内部只保存一个 context_window，然后同时生成 context_window 和 max_context_window，可能无法完整表达这种配置。
3. 建议提供一个持久化的逐模型配置来源
比较理想的关系是：
Codex 官方模型 metadata
+
用户在 ccswitchmulti 中保存的逐模型设置
↓
ccswitchmulti 的统一模型配置
↓
├─ cc-switch-model-catalog.json
└─ [model_providers.codex_model_router_v2].models
例如：
官方 metadata
→ 模型支持的最大上下文、能力信息
用户设置
→ 希望实际使用的上下文长度
→ 自动压缩阈值
这样用户不需要直接修改自动生成文件。
4. 两份生成结果建议来自同一个事实来源
目前至少存在：
cc-switch-model-catalog.json
以及
[model_providers.codex_model_router_v2].models
两处模型 metadata。
建议它们由同一份模型配置生成，避免出现：
catalog = 1M
Router = 272K
或者：
catalog = 272K
Router = 1M
这类不一致。
5. 用户修改不应在重启后静默丢失
如果 ccswitchmulti 需要重新生成这些文件，希望优先从自身持久化设置重新生成，而不是直接恢复一个固定的默认上下文值。
至少希望以下操作不会改变已经保存的逐模型上下文：
重启 ccswitchmulti
重新打开旧配置
保存 MultiRouter
同步模型目录
刷新模型列表
重新生成 config.toml
如果因为官方模型 metadata 发生变化，必须调整用户配置，也建议明确提示变化原因。
6. 建议增加上下文配置的可见状态
如果方便，可以在 MultiRouter 的模型配置界面显示：
模型名称
当前工作上下文
模型最大上下文
自动压缩阈值
配置来源（官方 / 默认 / 用户覆盖）
并提供类似：
这样的选择。
这样用户能够知道当前到底使用 272K 还是 1M，而不用打开生成后的 TOML / JSON 文件检查。
7. 这个问题会影响已有长会话
这个问题对长期使用 Codex Session 的影响比较明显。
例如：
旧会话原本按照 1M 上下文运行
↓
重启 ccswitchmulti
↓
生成配置恢复为 272K
↓
用户没有注意到
↓
继续旧 Codex Session
↓
当前允许的上下文显著缩小
↓
较早触发 compaction
一旦发生压缩，原有详细历史会被整理成压缩后的上下文，因此这不是单纯的界面显示问题。
如果用户已经明确为某个模型保存了长上下文设置，希望 ccswitchmulti 的配置刷新或重启不要静默改变这一行为。
8. 希望优先确认这是 Bug、当前限制、还是已有功能入口
如果 MultiRouter 已经支持逐模型上下文配置，但我遗漏了正确的设置入口，希望可以告知具体位置。
如果当前 MultiRouter 暂时不支持，也希望后续能够增加这一能力，并确保设置能够持久化到 ccswitchmulti 自身，而不是要求用户长期维护自动生成的配置文件。
本 Issue 只关注“MultiRouter 下模型上下文配置与持久化”的问题，与其它模型目录同步问题分开讨论。
Self Checks / 自检
I have read the FAQ section in README.
我已阅读 README 中的常见问题。
I have searched for existing issues, including closed ones.
我已搜索过已有的 Issue，包括已关闭的。
CC Switch Version / 版本号
3.20.2-1
Operating System / 操作系统
Windows
Related App / 涉及应用
Codex
Steps to Reproduce / 重现步骤
在 Windows 环境中使用最新版 Codex Desktop 和 ccswitchmulti。
在 ccswitchmulti 中使用「配置多路模型」功能完成 MultiRouter 配置，并使 GPT-5.6 Sol（
gpt-5.6-sol）出现在可用模型列表中。完成配置后，让 ccswitchmulti 自动生成：
C:\Users\Administrator\.codex\config.tomlC:\Users\Administrator\.codex\cc-switch-model-catalog.json检查生成后的
config.toml。GPT-5.6 Sol 如果需要按 1M 上下文运行，我目前需要手动确保顶层存在：
但 ccswitchmulti 自动生成配置后，
model_context_window和model_auto_compact_token_limit没有被稳定保留，需要手动添加。检查
config.toml中[model_providers.codex_model_router_v2].models对应的 GPT-5.6 Sol 条目。自动生成时通常为：
为了使用 1M 上下文，我需要手动修改为：
再检查
cc-switch-model-catalog.json中 GPT-5.6 Sol 的模型信息。自动生成时为：
我需要手动修改为：
完成上述手工修改后使用 Codex。
重启 ccswitchmulti，或者重新进入 MultiRouter 配置并执行保存、同步等会重新生成配置文件的操作。
再次检查
config.toml和cc-switch-model-catalog.json。可以观察到之前手动设置的长上下文参数可能被重新生成的默认配置覆盖，需要再次手动修改。
如果此时重新打开 Codex 并继续之前已经积累了较长上下文的会话，Codex 会按照重新生成后的较小上下文配置运行。在我的使用中，这会导致原本按 1M 上下文使用的旧会话很快触发上下文压缩。
Expected Behavior / 期望行为
希望 ccswitchmulti 在 MultiRouter 模式下能够正确支持并持久化“逐模型上下文配置”。
以 GPT-5.6 Sol 为例，如果用户希望该模型按照 1M 上下文运行，希望能够在 ccswitchmulti 中有明确的设置方式，例如配置：
具体实现不一定要求必须使用顶层：
如果 MultiRouter 为了兼容不同上下文长度的模型，需要采用逐模型配置方式，也可以使用其它实现。
关键预期是：
config.toml、cc-switch-model-catalog.json和 Router 的模型信息应该保持一致；最终希望达到的效果是：
也就是说，“自动生成配置文件”应该是用户持久化配置的输出结果，而不应该成为唯一保存这些参数的位置。
Actual Behavior / 实际行为
目前在 MultiRouter 模式下，我没有找到一个明确的位置，可以为 GPT-5.6 Sol 设置并持久化 1M 上下文窗口以及自动压缩阈值。
当前实际情况是：
ccswitchmulti 自动生成的
config.toml没有稳定保留我需要的：[model_providers.codex_model_router_v2].models中 GPT-5.6 Sol 的上下文信息会自动生成成：cc-switch-model-catalog.json中 GPT-5.6 Sol 也会自动生成成：为了让 GPT-5.6 Sol 按照 1M 上下文使用，目前我需要手工修改三个位置：
config.toml顶层的上下文和自动压缩配置；config.toml中 Router 模型列表里的 GPT-5.6 Sol 上下文信息；cc-switch-model-catalog.json中 GPT-5.6 Sol 的 context / max context 信息。手工修改之后可以继续使用，但这些修改不是由 ccswitchmulti 自身持久化管理的。
重启 ccswitchmulti 或重新生成 MultiRouter 配置后，这些值可能再次恢复为自动生成的默认值，需要重新手工修改。
因为配置回退并不会明显提醒用户，所以很容易出现“忘记再次手工修改”的情况。
如果此时继续一个之前已经使用较大上下文的 Codex 会话，Codex 会按照当前较小的上下文配置处理已有会话。在我的使用中，旧会话会很快触发自动压缩，原本仍可以保留在 1M 窗口中的详细历史上下文会被提前压缩。
因此，目前的问题不仅是“设置比较麻烦”，而是用户设置的模型上下文参数缺少稳定的配置来源和持久化机制，重新生成配置后可能静默改变 Codex 会话的上下文行为。
Additional Context / 补充信息
这个问题可能同时涉及“配置入口、持久化、模型 metadata 和配置生成”几个环节。
1. 本 Issue 主要关注 MultiRouter 下的逐模型上下文配置
我不确定 ccswitchmulti 当前是否已经存在 MultiRouter 专用的上下文设置入口。
如果已经存在，希望能够确认正确的设置位置；如果目前没有，则建议增加明确的逐模型上下文配置能力。
本 Issue 并不要求 MultiRouter 一定使用全局：
因为 MultiRouter 中不同模型可能具有不同的上下文能力，全局固定为 1M 确实可能不适合所有模型。
更希望解决的是“每个模型自己的上下文参数如何配置、保存并稳定生成”。
2. 建议区分几个不同概念
对于支持长上下文的模型，建议不要把下面几个值视为完全相同的字段：
以本例为例，我实际需要的是：
因此如果内部只保存一个
context_window，然后同时生成context_window和max_context_window，可能无法完整表达这种配置。3. 建议提供一个持久化的逐模型配置来源
比较理想的关系是：
例如：
这样用户不需要直接修改自动生成文件。
4. 两份生成结果建议来自同一个事实来源
目前至少存在：
两处模型 metadata。
建议它们由同一份模型配置生成，避免出现：
或者：
这类不一致。
5. 用户修改不应在重启后静默丢失
如果 ccswitchmulti 需要重新生成这些文件，希望优先从自身持久化设置重新生成，而不是直接恢复一个固定的默认上下文值。
至少希望以下操作不会改变已经保存的逐模型上下文：
如果因为官方模型 metadata 发生变化，必须调整用户配置，也建议明确提示变化原因。
6. 建议增加上下文配置的可见状态
如果方便，可以在 MultiRouter 的模型配置界面显示：
并提供类似：
这样的选择。
这样用户能够知道当前到底使用 272K 还是 1M，而不用打开生成后的 TOML / JSON 文件检查。
7. 这个问题会影响已有长会话
这个问题对长期使用 Codex Session 的影响比较明显。
例如：
一旦发生压缩，原有详细历史会被整理成压缩后的上下文，因此这不是单纯的界面显示问题。
如果用户已经明确为某个模型保存了长上下文设置，希望 ccswitchmulti 的配置刷新或重启不要静默改变这一行为。
8. 希望优先确认这是 Bug、当前限制、还是已有功能入口
如果 MultiRouter 已经支持逐模型上下文配置，但我遗漏了正确的设置入口，希望可以告知具体位置。
如果当前 MultiRouter 暂时不支持，也希望后续能够增加这一能力，并确保设置能够持久化到 ccswitchmulti 自身，而不是要求用户长期维护自动生成的配置文件。
本 Issue 只关注“MultiRouter 下模型上下文配置与持久化”的问题，与其它模型目录同步问题分开讨论。