背景
一次长链路 Codex 对话里，最让人难受的不是模型回答慢，而是上下文临近上限时突然进入自动压缩，页面长时间无响应，最后只能重开会话接着做。同一网络下 Claude Code 没有明显卡死，更容易让人把问题归因到网络。
这次排查把方向从“网络不稳”收窄到“压缩触发太晚、请求体太重、主线程上下文负担过大”。重点不是换工具，而是让 Codex 在进入危险区之前主动整理上下文。
这次解决了什么
最终把全局自动压缩阈值从接近窗口上限的位置提前到更保守的位置，让 Codex 更早触发 compaction，给输出、推理和压缩请求本身留下余量。
这次也区分了两个容易混在一起的配置：model_auto_compact_token_limit 直接决定何时触发压缩；model_reasoning_effort 主要影响每轮隐藏推理预算、延迟和窗口余量。前者是压缩稳定性的主开关，后者是接近上限时的风险放大器。
关键过程
先看历史会话索引，确认这不是偶发体感：曾经已经出现过“上下文压缩卡死”和“自动压缩崩溃”类会话。再看问题会话的结构，发现旧会话里有多次 compact 记录，且单条记录和工具输出都很大。
随后对比当前配置，发现全局 model_auto_compact_token_limit 设在较高位置。对一个长任务来说，这意味着 Codex 快到上下文边缘才开始压缩；如果这时还夹着截图、长日志、完整 diff、技能说明和仓库规则，压缩请求会很重。
最后结合官方 compaction 机制确认：压缩本身也需要处理完整窗口，窗口越大，延迟和断流风险越高。于是把策略从“等快满了再救”改成“提前留余量”。
踩坑
第一个坑是把“同一网络下 Claude Code 正常”理解成“Codex 也一定不是链路问题”。实际上两者走的客户端、会话管理、压缩接口和恢复机制都不同，同网只能排除一部分网络问题，不能排除 Codex 自己的 compact 链路压力。
第二个坑是让主会话吞太多原始材料。截图的 base64、长日志、构建输出、diff、完整规则文件都会增加压缩负担。即使压缩成功，这些内容也会拖慢之后每一轮。
第三个坑是把 reasoning effort 当成只影响“聪明程度”。更高的推理档位会吃更多隐藏推理预算，在大上下文时会减少安全余量，让长任务更容易卡在慢请求和压缩边缘。
最后方案
全局先把 model_auto_compact_token_limit 调到 120000，不要等到 200k 以上才自动压缩。这个值的思路是让压缩发生在上下文仍然相对健康的时候，而不是等请求已经很笨重才启动补救。
日常建议把 model_reasoning_effort 保持在 high，复杂架构、疑难调试、深度评审时再临时切到 xhigh。这样不会明显牺牲日常编码质量，却能减少长会话里的尾部延迟和压缩风险。
长任务还要配合工作方式：大日志先过滤，大 diff 分批看，截图尽量走文件或工具视图，阶段性结论写成本地 handoff 文件。主线程保留决策上下文，重输出交给子任务或命令摘要。
以后怎么做
以后遇到 Codex 自动压缩卡住，先不要只怀疑网络。优先看三件事：自动压缩阈值是否太晚、当前会话是否塞了图片或长输出、全局推理档位是否长期设得过高。
如果已经卡死，重开会话后先把上一轮断点写成简短上下文锚点，再继续执行；不要把完整旧会话、完整日志和完整截图重新塞进新会话。真正稳定的长链路，不是永远不压缩，而是让压缩发生得早、轻、可恢复。