现象
- 3.11.2-25（runtime 0.16.5）：
/context 显示 glm-5.3-flash（BigModel Coding Plan 内置模型）上下文为 1M，正常。
- 9/23 升级 3.14.3-27（runtime 0.16.9） 后变为 200K；9/25 再升 3.14.3-28 依然 200K。
- 降回 3.11.2-25 后立即恢复 1M → 3.14.x 的回归。
排查过程
- 配置无误：
~/.zcode/cli/config.json 里 limit.context: 1000000；官方下发的 model-catalog.json 对该模型也是 contextWindow: 1000000。
- 读了
vendor/zcode.cjs：contextWindow 的兜底默认值是 Jge=2e5（200,000），/context 显示值与它精确吻合 → 0.16.9 runtime 没有读到 1M 声明，落到了兜底值。
- 按 schema 读取优先级（
s.contextWindow ?? s.limit?.context）在 config.json 给 zai / bigmodel 两个 provider 的 glm-5.3 与 glm-5.3-flash 补了顶层 "contextWindow": 1000000, "maxOutputTokens": 128000，升级到 3.14.3-28 后仍显示 200K，workaround 无效。
- 服务端实际没有 200K 限制：此前有会话单轮 20 次请求累计输入 250 万 token 正常完成（db.sqlite
turn_usage 表可证）。
实际影响
不只是显示问题：客户端按 200K 预算计算 auto-compact 触发点（200K − 输出预留 − 安全缓冲 ≈ 16.6 万 token），导致 1M 窗口的会话在约 17% 水位就被提前压缩，长上下文能力实际不可用。
环境
- macOS darwin-arm64，npm 全局安装
zcode-app-cli
- 触发版本：3.14.3-27、3.14.3-28（runtime 0.16.9）；正常版本：3.11.2-25（runtime 0.16.5）
- 接入方式：BigModel Coding Plan 编程套餐授权（内置模型，窗口不可自行编辑）
如需 config、日志或会话记录可以补充。
现象
/context显示 glm-5.3-flash（BigModel Coding Plan 内置模型）上下文为 1M，正常。排查过程
~/.zcode/cli/config.json里limit.context: 1000000；官方下发的model-catalog.json对该模型也是contextWindow: 1000000。vendor/zcode.cjs：contextWindow 的兜底默认值是Jge=2e5（200,000），/context显示值与它精确吻合 → 0.16.9 runtime 没有读到 1M 声明，落到了兜底值。s.contextWindow ?? s.limit?.context）在 config.json 给 zai / bigmodel 两个 provider 的 glm-5.3 与 glm-5.3-flash 补了顶层"contextWindow": 1000000, "maxOutputTokens": 128000，升级到 3.14.3-28 后仍显示 200K，workaround 无效。turn_usage表可证）。实际影响
不只是显示问题：客户端按 200K 预算计算 auto-compact 触发点（200K − 输出预留 − 安全缓冲 ≈ 16.6 万 token），导致 1M 窗口的会话在约 17% 水位就被提前压缩，长上下文能力实际不可用。
环境
zcode-app-cli如需 config、日志或会话记录可以补充。