Codex 一直跑测试却不结束时，先查看最近一次输出和代码变更，再把任务写成可验证的完成条件。 不要简单要求“再检查一遍直到完美”，也不要为尽快结束而跳过项目强制测试。
反复出现相同失败、没有新改动，与修复代码后出现新失败，是两种情况。本文给出任务管理方法，没有进行新的额度节省实验。
先分清它在做什么
| 现象 | 核查重点 | 下一步 |
|---|---|---|
| 同一测试反复失败，代码没变 | 最近报错与已有假设是否相同 | 暂停重复运行，定位失败原因 |
| 修复后出现新失败 | diff 是否引入回归 | 针对新问题继续修复 |
| 长时间没有输出 | 进程、网络和超时设置 | 判断是在等待还是已卡住 |
| 不断扩展检查范围 | 原任务与新增工作是否相关 | 把范围收回用户要求 |
| 已出现用量限制 | 当前账户和限制窗口 | 单独查看额度，不把它当测试故障 |
必要时中断当前运行，保留工作文件、测试输出和已知状态。中断只是停止继续执行，不代表已经验收，也不意味着应删除已有修改。
把任务改写成明确的验收要求
以下是任务说明示例，不是实测记录：
修复搜索查询为空时页面报错的问题。
范围：只修改与这一行为相关的代码。
验收：空查询不再报错；正常搜索仍显示结果；相关测试。
执行受影响的测试和仓库规定的强制检查。
只有新修改、新失败或尚未解决的具体疑点才需要重跑。
如果再次出现相同失败且没有新假设，停止重复执行，
报告已知原因、完成的修改和剩余阻碍。
验收完成后总结结果，不增加无关重构。
验收条件应描述可观察的行为，而非“彻底优化”“确保绝对没有问题”。涉及仓库规定的 CI、审查或安全检查时，必须实际完成；提示词不能把这些要求取消。
也要检查任务说明、AGENTS.md 和技能要求是否把小修复扩大成了全面审查，分清当前改动必做的检查与后续工作。不能绕过权限或关闭保护来制造完成状态。
阅读最近一次 diff 和测试结果
确认代码确实覆盖了原问题，检查失败是否与当前修改有关。失败来自缺失依赖、外部服务或权限时，应如实报告环境阻碍；不能靠修改测试让结果看起来。
如果需要继续一个长任务，留下简短检查点：改了哪些文件、哪些验证已完成、剩余问题是什么。连接中断的情况可参考 Codex 流式连接中断排查。
把任务循环与账户额度分开处理
更清晰的范围可能减少无效工作，但没有固定的节省比例。API token 费用也不是 ChatGPT 订阅额度的换算公式。官方 Codex 价格说明应结合账户当前显示理解。
官方缓存文档截图，拍摄于 2026 年 9 月 16 日，保留英文界面。它说明 API 的缓存分类，不是 Codex 订阅额度表。
额度耗尽时查看周限额恢复时间；比较模型时，按同一任务的完成成本评估。先解决任务范围或环境故障，再判断换模型是否有帮助。
比较完成成本时，从相同仓库状态出发，使用相同任务和权限，记录耗时、验收结果、人工修复与收费重试。
参考来源
- ofox 文档：模型目录 — https://docs.ofox.io/zh/develop/models
