结论

Computer History（内部标识 chronicle）的摘要调度器缺少并发上限、失败退避与额度熔断，在两台 Mac 上以设计速率约 4 倍持续运行，两天内产生 2,324 次模型调用，耗尽2个账号（2×Plus）的额度。用户侧无任何提示。

机制

常驻进程按以下流水线工作：```
codex_chronicle
→ 屏幕采集（默认 5s/帧，检测到用户输入时降至 1s）
→ 按 10 分钟分桶
→ 拉起 codex exec 会话读取该桶的帧，生成摘要
→ 写入本地 memory summary

```摘要会话使用的模型与交互式会话不同（可在 Analytics 的 By model 视图中区分）。输入为屏幕截图，故单次调用携带图像 token，成本显著高于纯文本请求。

按 10 分钟分桶计算，单机设计速率约 144 次/天。

观测数据

日期 |
设备 A |
设备 B |

09-09 |
52 |
— |

09-10 |
223 |
— |

09-11 |
127 |
— |

09-16 |
27 |
13 |

09-17 |
707 |
826 |

09-18 |
96 |
695 |

- 09-17 + 09-18 合计 2,324 次，对应设计值 576 次（144 × 2 台 × 2 天），约 4.0 倍

- 09-17 设备 A：707 次启动 / 93 次完成 / 833 次失败，成功率 13%

- 两日内 Your workspace is out of credits 出现 1,349 次

09-18 的统计截止到当日 15:49，实际倍数更高。

三个缺失的保护

1. 无并发上限

同一毫秒内可拉起多个 codex exec 进程。典型片段（09-17）：```
14:24:05.379139Z ERROR summary session failed session_id=422 (out of credits)
14:24:05.379291Z INFO starting summary session session_id=426 bucket=13-13-00Z
14:24:05.380157Z INFO starting codex exec summary session
14:24:05.539946Z ERROR summary session failed session_id=425 (out of credits)
14:24:05.540657Z INFO starting codex exec summary session
14:24:05.565634Z ERROR summary session failed session_id=421 (out of credits)
14:24:05.566237Z INFO starting codex exec summary session
14:24:05.625086Z ERROR summary session failed session_id=424 (out of credits)
14:24:05.625719Z INFO starting codex exec summary session
14:24:05.957105Z ERROR summary session failed session_id=423 (out of credits)
14:24:05.957667Z INFO starting codex exec summary session

```五个会话在 578 ms 内全部失败并全部重启。

2. 失败不退避

每次失败到下一次启动的间隔为 0.5–1.5 ms，且重试路径会铸造新的 session_id 而非重新调度原任务——这是 session_id 单日即累积到 400+ 的原因。失败计数（833）高于启动计数（707）亦源于此。

3. 额度耗尽不熔断

客户端已解析到 out-of-credits 响应，循环未终止，以相同频率继续发起请求。同一模式在 401 Unauthorized 路径上重现（失败后 1.4 ms 重启）。

队列积压

09-18 07:48Z 时刻，调度器正在处理 bucket=2026-09-18T03-16-00Z，滞后约 4.5 小时。

直接后果：每次额度窗口重置后，积压的重试队列立即将新配额消耗殆尽。用户观察到的现象是"额度刚恢复就没了"，且发生在无人操作的时段。

数据范围

摘要内容不限于 Codex 会话。实测一份 10 分钟摘要包含：浏览器中打开的云平台项目标识、控制台区域配置、Finder 下载目录的文件名。凡出现在屏幕上的内容均在采集范围内。

官方文档称历史记录"不包含截图"——这描述的是存储内容，与"截图是否作为模型输入"是两个问题。日志可确认帧文件被持续写入，且摘要进程以该目录为工作目录；是否作为 input image 提交需服务端请求记录佐证。

自查

日志路径 ~/Library/Logs/com.openai.codex/<YYYY>/<MM>/<DD>/。```

每日调用次数（正常量级为一百余次）

grep -rh "starting codex exec summary session" \
~/Library/Logs/com.openai.codex/2026/09/*/ | wc -l

空转重试次数

grep -rh "out of credits" ~/Library/Logs/com.openai.codex/2026/09/*/ | wc -l

队列滞后：对比日志时间戳与 bucket= 的时间

grep -rh "completed summary session" ~/Library/Logs/com.openai.codex/2026/09/*/ | tail -5

```服务端侧：Settings → Analytics → Usage history → By model。摘要会话使用的模型不同于交互式会话，若某日出现非自用模型的用量，即可归因。

多设备需逐台排查——同一账号或不同账号在多台机器上会独立触发。

关闭

Settings → Computer history 关闭，或菜单栏暂停。配置项位于 ~/.codex/config.toml 的 [features] 段：```
[features]
chronicle = false

```需完全退出 App 后重启；仅修改配置不会终止已运行的进程。