Codex usage quota decreases slowly even when I am not actively using Codex

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #26512
• #25420
• #25510
• #25483
• #25302

Powered by Codex Action

如果你用的是desktop，打开设置在常规下滑检查你的，建议提示是否打开，关闭就好了

<img width="690" height="86" alt="Image" src="https://github.com/user-attachments/assets/8ad6946b-c21f-45bb-a41f-e6a681b0fa8a" />

Additional observation:

I saw the usage quota decrease unexpectedly again. From the local Codex session logs, some jumps appear around normal thread activity, but the size/timing of the quota change is hard to reconcile with the immediately visible user action.

What I observed:

• The quota percentage can remain flat for several small turns, then jump noticeably later.
• In one recent case, a small action such as checking git status --short happened near a larger usage percentage jump.
• The local token_count event for that immediate turn was not large enough by itself to intuitively explain the visible jump.
• This makes it look like usage may be batch-settled or delayed, but the UI does not explain that.
• From the user side, this feels like quota is decreasing even when there is no obvious active work happening.

Request:

Could Codex expose a clearer usage breakdown by time/thread/model, including whether the displayed quota is updated in real time or batch-settled later? It would also help to show whether cached input, retries, background/session activity, or delayed accounting contributed to a particular quota change.

This is especially important for Pro users because the current percentage jumps make it difficult to tell whether usage is expected, delayed, or anomalous.

如果你用的是desktop，打开设置在常规下滑检查你的，建议提示是否打开，关闭就好了 <img alt="Image" width="690" height="86" src="https://private-user-images.githubusercontent.com/191325448/603780156-8ad6946b-c21f-45bb-a41f-e6a681b0fa8a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODA3NTYxMzMsIm5iZiI6MTc4MDc1NTgzMywicGF0aCI6Ii8xOTEzMjU0NDgvNjAzNzgwMTU2LThhZDY5NDZiLWMyMWYtNDViYi1hNDFmLWU2YTY4MWIwZmE4YS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNjA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDYwNlQxNDIzNTNaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yZDVkYmI2NzY1NTRmODc3NjlmM2QyYzUwYWM3MjFlMjY4NmRiYjk4N2I4MmIwZDY3NDNjMTRlNmRmYjJhYjgxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.VF26DlE0sxKiy5NaZxdGiFchGcLM7iujrlmBgFd6Nys">

我好像并没有这个选项，是更新以后不见了吗

可能是的，我今天还没有更新codex，那么你更新到最新的codex现在的token消耗还有异常状态吗

补充一个更明确的现象：我这次不是感觉之前未计入后再统一扣掉，而是明显看到多个时间段中余量到约30%/20%区间后，额度出现一次性大幅下降（例如很快从三四成到个位数），且期间没有持续高强度输入。

这更像计费事件在“低额度阶段”出现聚合回填/展示回放问题：

• used_percent 的下降在 UI 上表现为阶跃式下沉，而非平滑递增；
• 在接近末段尤其明显，像是窗口口径与回写时机不一致；
• 非常担心是 primary/secondary 可视口径本身存在 bug（或后端计量事件与回显窗口异步），而不是用户被系统性降配。

请求：能否确认是否存在与短窗口回算有关的已知问题？是否能提供官方级的对账方法（按事件时间序列映射到 used_percent），并说明缓存输入、reasoning 输入/输出在“最后余量窗口”是否会触发异常放大？

排查方案1.查日志找活跃会话
打开 logs_2.sqlite，查最近的 API 调用记录：

2.查最近日志

关键发现： 有一个 thread 019e9a9c 在持续执行 session_task.turn，用 model=gpt-5.4。

3.追踪会话是谁触发的
查这个 thread 的起始点

我的额度从每5小时的重置以后我没有用过，但是我看到它一直在往下掉。

排查方案1.查日志找活跃会话 打开 logs_2.sqlite，查最近的 API 调用记录： 2.查最近日志 关键发现： 有一个 thread 019e9a9c 在持续执行 session_task.turn，用 model=gpt-5.4。 3.追踪会话是谁触发的 查这个 thread 的起始点

这个我并没有查到

logs_2.sqlite发我,亦或者你如果有hermes的话让他去找原因很快就找到了，## 排查问题时的规则

1. 先搜 GitHub Issues，用关键词找已有解决方案
2. 不确定时先查文档，不要猜
3. 修改配置前必须备份
4. 改完后验证结果

我这边的问题已经解决了

Update: I found a much more concrete local signal pointing to Codex Chronicle / memories as the likely source of the unexpected quota consumption.

My two recurring Codex automations are not hourly. Both are scheduled once per day at 09:00:

RRULE:FREQ=WEEKLY;BYHOUR=9;BYMINUTE=0;BYDAY=SU,MO,TU,WE,TH,FR,SA

After my quota reset around 2026-06-07 00:07 local time, I observed my quota dropping quickly without active user prompts. Local logs show a background/ephemeral memory request shortly after the reset:

time: 2026-06-07 00:26:15 local
thread_id: 019e9dbc-163e-73c3-bdb2-7c3e3f5baebe
model: gpt-5.4
cwd: ~/.codex/memories
total_usage_tokens: 143165
estimated_token_count: 138835

The output for that request explicitly said it completed an incremental memory consolidation and updated:

~/.codex/memories/MEMORY.md
~/.codex/memories/memory_summary.md

The file modification times match that event:

MEMORY.md          updated at 2026-06-07 00:25:09 +0800
memory_summary.md updated at 2026-06-07 00:25:41 +0800

I also observed Chronicle generating memory summary files under:

~/.codex/memories/extensions/chronicle/resources

and temporary screen/OCR files under:

$TMPDIR/chronicle/screen_recording

Additionally, while Chronicle was running, the local process list showed a background memory writer launched by codex_chronicle:

codex exec --ephemeral --ignore-user-config --model gpt-5.5 ... \
  --config model_provider="openai-memgen" ... \
  --config model_providers.openai-memgen.http_headers={ "X-OpenAI-Memgen-Request" = "true" } ... \
  --cd $TMPDIR/chronicle/screen_recording -

This seems consistent with the Chronicle docs saying that background agents generate memories from captured screen images and that these agents currently consume rate limits quickly:

https://developers.openai.com/codex/memories/chronicle

So the current evidence suggests this is not caused by my normal visible Codex threads, not my daily automations, and not the gpt-5.3-codex-spark counter. It appears to be Chronicle / memory writer / memory consolidation activity consuming my Codex quota in the background, including soon after reset when I was not actively sending prompts.

Questions:

1. Are Chronicle / memory writer / memory consolidation requests intended to count against the user's Codex quota?
2. If yes, can the app show this clearly in the usage breakdown? Right now it looks like quota disappears without an associated visible thread.
3. Can users configure the Chronicle memory writer model? On my machine it appears to be launched with --model gpt-5.5 --ignore-user-config, so changing my normal default model does not seem to affect it.
4. If these requests are intended to be exempt or separately accounted, this may be a quota accounting bug.

我确定问题了，是因为Chronicle后台运行太消耗额度了

你这个Chronicle问题在github上好像在之前就有了，我记得我刷到过，大概就是“Chronicle研究预览”通过截屏分析来增强记忆

然后还有一个自动整理记忆的东西1.Codex Memory，memory 打开codex自动调用gpt5.4进行整理记忆（他可能是持续的）
解决方式：在~/.codex/config.toml的底部加上
[features]
js_repl = false
memories = false
至于“Chronicle研究预览我并不知道该怎么改

A good debug artifact here would be a quota-delta ledger, not just another percent display.

For each observed change, record sampled_at, quota window id, previous/next remaining percent, charge_source (foreground_turn, background_task, memory_writer, chronicle, server_adjustment, unknown), thread id, cwd, model, token buckets, event time, and settlement time. That would separate real background work from delayed batch settlement and from UI replay bugs near the end of a window.

Generated with ax - https://github.com/Necmttn/ax