Codex 响应慢怎么办？

1. 先判断慢在哪里

• 首字慢：模型排队或线路问题，用试验 Key 发一条短请求对比，几十秒无首字再换时间窗。
• 生成慢：输出太长，max_tokens 按需给，别默认拉满。
• 工具执行慢：是命令本身耗时（构建、测试），不是 API 慢，看终端时间戳区分。
• 账单涨得快：上下文重复堆叠，历史对话每次全量重放，见第 3 节。

2. 匹配模型

• 简单重构、改文案、补测试：用轻量模型（GLM-5.3-Flash、Gemini 3.6 Flash），倍率低、首字快。
• 复杂架构和跨文件推理：Claude Opus 5、GPT-5.6 Sol。
• 先固定同一任务再换模型对比，否则比不出是模型慢还是上下文拖累。

3. 控制上下文

• 不要把整个仓库贴进会话，只给相关文件和明确的改动目标。
• 一个任务开一个会话，做完及时开新会话，避免历史无限累加。
• 长会话用 Codex 的 compact 能力压缩历史；会话之间不自动携带记忆。
• 开启流式输出，边生成边看，不用等完整响应，也能更早发现方向跑偏。
• 日志和大文件只贴关键片段，让模型需要时再去读文件。

4. 拆分任务

• 一次给一个明确目标，“先出计划再执行”比“一步到位”返工少。
• 跑测试、构建这类耗时命令交给脚本，不在 Codex 会话里等。
• 生图、视频任务移出 Codex，用图片接口和视频接口单独走。

5. 并发与重试

• 并行任务用不同会话分开跑，共享额度时给试验 Key 单独设上限。
• 收到 429 按指数退避重试，立刻重发只会加剧排队；连续 429 说明并发或额度到顶，先降速再重试。
• 重试设上限（比如 3 次），超过就换时间窗，避免无效消耗。

6. 推荐工作流

1. 试验 Key 验证连通（见安装指南与配置指南）。
2. 小步改代码：每轮只改一个模块，短请求验证。
3. 收工按控制台 Token 账单复盘，找出上下文大头。

体感不可靠，账单才是真相。每周固定看一次 Token 构成，上下文占比超过一半就该开新会话。同一账户的生图按张、视频按任务计费，不要和 Codex Token 混在一起平均。

7. 常见问题

换更强模型一定更快吗？

不一定。先固定任务再换模型，否则比不出是模型还是上下文。

裁上下文会丢信息吗？

把“相关文件路径 + 改动目标”写清楚，模型可以按需读文件，比全量粘贴更快也更准。

为什么账单比预期高？

九成是历史会话全量重放。检查长会话和重复粘贴的大文件，按账单里的 Token 构成定位。