Skip to content

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

Open
Open
Codex usage quota decreases slowly even when I am not actively using Codex#26600
Labels
appIssues related to the Codex desktop appbugSomething isn't workingrate-limitsIssues related to rate limits, quotas, and token usage reportingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@lin-qian123
lin-qian123
opened on Jun 5, 2026

Summary

My Codex usage quota appears to decrease slowly even when I am not actively using Codex.

What I observed

  • I was not actively using Codex during the period.
  • The remaining usage/quota still appeared to decrease gradually.
  • I am concerned that background sessions, stuck tasks, automations, or account/session state may be consuming quota unexpectedly.

Expected behavior

Codex usage quota should only decrease when there is active usage, or the UI should clearly explain what background activity is consuming quota.

Questions

  1. Are idle/background Codex sessions expected to consume quota?
  2. Can archived, not-loaded, or still-running threads continue consuming quota?
  3. Is there a way to view detailed quota usage by session/thread/time range?
  4. Is there a way to terminate all active Codex sessions from the account side?

Environment

  • Product: Codex desktop/app
  • Platform: macOS
  • Approximate date observed: 2026-06-05

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jun 5, 2026

  2. github-actions commented on Jun 5, 2026

    @github-actions
    github-actionsbot
    on Jun 5, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026

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

    Image

  4. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026 – with ChatGPT Codex Connector
    Author

    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.

  5. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026
    Author

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

    Image

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

  6. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026 via email

  7. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026 – with ChatGPT Codex Connector
    Author

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

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

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

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

  8. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026

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

    2.查最近日志

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

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

  9. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026
    Author

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

  10. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026
    Author

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

    2.查最近日志

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

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

    这个我并没有查到

  11. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026 via email

  12. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026

    我这边的问题已经解决了

  13. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026
    Author

    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.

  14. lin-qian123 commented on Jun 6, 2026

    @lin-qian123
    lin-qian123
    on Jun 6, 2026
    Author

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

  15. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026 via email

  16. stemlilk commented on Jun 6, 2026

    @stemlilk
    stemlilk
    on Jun 6, 2026

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

  17. Necmttn commented on Jun 22, 2026

    @Necmttn
    Necmttn
    on Jun 22, 2026

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingrate-limitsIssues related to rate limits, quotas, and token usage reportingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions