MixLivo先保工作，再处理额度。出现上限提示时，确认当前回合到底还在运行还是已经停止；随后保存文件、执行结果和第一项未完成工作。重开应用、重登录或新建聊天，都不是额度已经恢复的证明。
第一步：分清“还在执行”“已经停下”“状态未知”
观察任务状态、工具输出与文件：是仍在编译、测试或生成结果，还是已经报错结束？官方说明活跃回合达到用量上限时，代理可在公平使用限制内继续该回合；这不保证整项任务成功，也不允许后续无限新增请求。官方用量说明
如果运行的是迁移、发布、提交或其他外部写入，不凭聊天没有最终回复就再发同一操作。先查实际进程、产物或目标系统记录。状态不明时写“待核验”，不能写“未执行”或“已成功”。
假设额度提示出现时，终端已启动测试但还没有结束输出：保留该运行，先等测试结果；重新发“从头继续”可能再启一份测试。若是发布或数据库迁移，更不能把没收到聊天总结等同于没执行。先看目标系统或进程的实际状态；查不到就交接为未知，不用猜测填满进度。
第二步：以当前文件为准，保留可继续的现场
在正确项目目录执行只读检查：
git status --short
git diff --stat
再审阅相关文件diff。按项目规则保存选定修改的检查点；未跟踪文件要单独检查，普通diff不会自动包括它们。确认自己已有工作与代理改动的归属，避免为了备份把密钥、生成垃圾或无关文件一并提交。
重要报告、截图和生成文件保存到自己的受控目录；下载成功后实际打开。若只能在云端看到成果，按当前权限审阅并下载或应用到正确仓库，别把“云端任务完成”当成本机文件已经同步。
如果一半修改已经写入、一半还停在建议里，就把它们分开。能在 diff 看到的算实际改动；聊天中说“接下来改这里”只是计划。测试命令被建议过，也不代表已运行。这样下一轮才不会先覆盖已改文件，或把尚未执行的计划算作完成。
第三步：写一份不依赖模型再次回复的进度
即使暂时不能向模型发消息，也能根据已有输出手工填写：
目标：___
工作位置：项目目录、分支、会话ID或名称
已完成：文件与实际结果，不只写步骤名称
验证：真实执行过的命令、通过/失败、尚未运行
外部动作：已确认完成/未执行/状态待核验
下一步：第一项未完成任务及验收标准
不能改变：需求边界和保留事项
填真实状态，不为得到总结反复请求。不要把auth.json、API Key或完整网络日志写入交接文件。保全完成的标志是下一位操作者能够通过文件与记录确定从哪里继续，而不是只有一张上限截图。
例如，假设正在修复结账表单，已经修改src/checkout.ts，测试命令已运行但失败，截图还没检查。可以在项目约定的位置保存如下交接内容；文件名只是例子：
任务：修复手机号留空时仍能提交的问题。
已有工作：src/checkout.ts增加校验，尚未提交；请先审阅现有diff。
验证：已运行项目的表单测试，手机号用例通过，旧地址用例失败。
未知：失败是否由本次修改引入；未做浏览器检查。
第一步：比较地址用例失败原因，先不要重写整个表单。
外部状态：未发布、未提交订单。
实际项目没有运行测试，就写“未运行及原因”，不能照抄示例的通过结果。保存后重新打开确认位置正确；无 Git 时为相关文件保存可辨认副本和说明。
查清限制，再安排何时继续
打开官方Codex用量页，或CLI输入 /status，记录限制名称、模型、恢复时间及时区。当前本地与云端共享对应计划用量，周限制也可能适用；当前Pro没有五小时限制，不能把一个短周期套到所有账号。
部分其他代理功能也可能共享该用量，别仅凭本会话没发几条就断言计数错误。符合资格的credits可续用支持功能，但本页不展开选购；如已经存在余额，核对它是否适用当前账号与功能，而非wallet或API资金。credits范围
恢复会话后，先只读确认，再执行下一步
CLI先进入原项目，再选择：
codex resume
它打开已保存会话的选择入口。明确要当前目录最近会话时可用 codex resume --last；找其他目录的会话用 codex resume --all查找。当前目录与保存目录不同，客户端可能询问使用哪一个，认真核对，别在同名项目里继续改。官方resume规则
桌面或编辑器从历史打开原聊天，先确认项目与分支；换新会话或电脑时，提供进度与实际文件位置。恢复聊天不会自动使旧理解跟上中断期间的文件变化。
第一次只让它检查，先不继续改：“读取进度文件和当前diff，列出哪些已完成、哪些失败、第一项未完成工作；如果文件与记录不一致先指出。”检查结果应能对应到实际文件和执行输出。第二次才要求执行已确认的下一步；完成一项就保存结果，别再次发一个没有范围的“全部继续”。
如果恢复的是几天前会话，其他工具可能已改过同一文件。以当前仓库为准审阅差异，不能为了迁就旧聊天覆盖更新的代码。分支不同或原目录不存在时，先找到正确工作副本；会话恢复命令不会替你还原丢失的项目。
会话找不到，但文件还在
先确认是不是在另一个目录启动，使用上面的--all查找本地保存会话。仍没有时，不必为了找聊天阻塞整个任务：在新会话打开真实项目，提供进度文件、必要差异及第一项未完成工作，要求先复述状态。聊天里没落盘的推理、只在过期链接中的产物则不能假定可恢复，需根据可用资料重新确认。
云端任务与本地任务不同步
如果结果只在云端任务里，先按当前界面审阅改动并下载或应用；随后在本地查看对应文件与Git差异。只有本地文件真正变化，才可在本地续做。不要同时让两个入口对同一个不清楚的工作副本重复修改。
重新出现的错误，按现在的提示处理
先看是否另一项周或模型限制仍在；再用 codex login status核对实际身份，与看用量页的账号/工作区一致。API Key失败要查对应Platform项目，不用订阅重置时间解释。官方认证
若提示改为登录、连接或服务不可用，转查该错误，不继续称为额度不足。真正超过对应重置时间仍受限时，向官方支持提供客户端版本、时间及时区、原/新提示、用量状态和已做对照；不把整个私有仓库作为普通附件。
恢复后只应从第一项未完成工作推进。若仓库已被其他人更新，原进度需要根据当前差异修正；会话记住的旧路径或分支不能优先于现有文件。每完成一项就更新实际结果，再继续下一项，避免再次把全部状态只放在聊天里。
常见问题
上限后，之前改过的代码会回滚吗？
不能由提示推断。检查工作目录、diff和执行结果，再按项目规则保存或恢复。
原会话找不到，还能继续吗？
可以依据已保存的项目文件和进度在新会话接续；原聊天或未落盘内容不保证可恢复，因此先保文件与真实结果。